NetBSD Problem Report #57259
From www@netbsd.org Sat Mar 4 20:58:16 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 0A0181A9239
for <gnats-bugs@gnats.NetBSD.org>; Sat, 4 Mar 2023 20:58:16 +0000 (UTC)
Message-Id: <20230304205814.D2BD91A923B@mollari.NetBSD.org>
Date: Sat, 4 Mar 2023 20:58:14 +0000 (UTC)
From: thorpej@me.com
Reply-To: thorpej@me.com
To: gnats-bugs@NetBSD.org
Subject: ucom serial ports cannot be re-opened "too quickly" with O_NONBLOCK
X-Send-Pr-Version: www-1.0
>Number: 57259
>Category: kern
>Synopsis: ucom serial ports cannot be re-opened "too quickly" with O_NONBLOCK
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Mar 04 21:00:00 +0000 2023
>Closed-Date: Wed Aug 02 13:48:08 +0000 2023
>Last-Modified: Wed Aug 02 13:48:08 +0000 2023
>Originator: Jason Thorpe
>Release: NetBSD-10.0_BETA
>Organization:
RISCy Business
>Environment:
NetBSD neo2-nas 10.0_BETA NetBSD 10.0_BETA (GENERIC64) #0: Sun Feb 12 12:39:37 UTC 2023 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm
>Description:
USB serial ports ("ucom" backed by uftdi in my case, but that may not matter) cannot be re-opened "too quickly" with O_NONBLOCK.
The symptom I observe is a process that has the serial port open exits, and immediately restarts and opens the device with O_NONBLOCK (because it's a portable program that does not want to deal with modem control nonsense, and opening with O_NONBLOCK is the portable way to do this). This program occasionally gets EAGAIN on the open() call. If there is a delay between exiting and restarting, the problem does not occur.
This is apparently not related to the HUPCL handling change made in several serial drivers in 2021 and 2022, as that code path does not consider O_NONBLOCK -- it waits for the 1 second hang-up window regardless of O_NONBLOCK (which seems perfectly fine -- the pause is not indefinite, and you wouldn't get EAGAIN if the driver had to block to acquire a mutex, for example).
My hypothesis is that it's related to the "closing" logic that is unique to the "ucom" driver among serial port drivers. It uses the d_cancel entry point to split close into two phases, which is something that no other serial port drivers do. Furthermore, this cancel/close logic specifically manipulates state that can cause EAGAIN to be returned to an open() call:
if (state == UCOM_OPENING || sc->sc_closing) {
if (flag & FNONBLOCK)
error = EWOULDBLOCK;
else
error = cv_wait_sig(&sc->sc_statecv, &sc->sc_lock);
mutex_exit(&sc->sc_lock);
return error ? error : ERESTART;
}
Looking at the "com" driver, for example, there appears to be nothing that would return EAGAIN (or the alternate spelling EWOULDBLOCK) in the open path.
>How-To-Repeat:
close, then re-open a "ucom" serial port with O_NONBLOCK very quickly.
>Fix:
Yes please.
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: thorpej@me.com
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57259: ucom serial ports cannot be re-opened "too quickly" with O_NONBLOCK
Date: Sat, 4 Mar 2023 22:15:31 +0000
The problem you're encountering is unrelated to the d_cancel logic.
By the time close(2) returns, sc_closing is set to false. The logic
you quoted is only applicable when open(2) and close(2) happen
concurrently. You could rip that logic back out if you want a crashy
kernel that makes you twitch at the thought of removing a USB device
or running two programs that touch a tty at the same time, but it
wouldn't help with the problem at hand.
The problem at hand is that a delay which used to happen in close(2)
(with no opportunity for a nonblocking variant),
/*
* Hang up if necessary. Wait a bit, so the other side has time to
* notice even if we immediately open the port again.
*/
if (ISSET(tp->t_cflag, HUPCL)) {
ucom_dtr(sc, 0);
/* XXX will only timeout */
(void) kpause(ttclos, false, hz, NULL);
}
is now implemented by sleeping only for the _remainder_ of the 1sec
delay in open(2):
/*
* If the previous use had set DTR on close, wait up to one
* second for the other side to notice we hung up. After
* sleeping, the tty may have been revoked, so restart the
* whole operation.
*
* XXX The wchan is not ttclose but maybe should be.
*/
if (timerisset(&sc->sc_hup_time)) {
struct timeval now, delta;
int ms, ticks;
microuptime(&now);
if (timercmp(&now, &sc->sc_hup_time, <)) {
timersub(&sc->sc_hup_time, &now, &delta);
ms =3D MIN(INT_MAX - 1000, delta.tv_sec*1000);
ms +=3D howmany(delta.tv_usec, 1000);
ticks =3D MAX(1, MIN(INT_MAX, mstohz(ms)));
error =3D cv_timedwait_sig(&sc->sc_statecv, &sc->sc_lock,
ticks);
mutex_exit(&sc->sc_lock);
return error ? error : ERESTART;
}
}
When cv_timedwait_sig times out, it returns EWOULDBLOCK. This is a
little confusing, both for cv_timedwait_sig(9) (which needs to be
replaced by a better API) and for open(2) on a tty (with or without
O_NONBLOCK). Perhaps it should map EWOULDBLOCK to ERESTART, or be
moved back to the close path -- I don't have strong feelings about it.
But this logic is not unique to ucom(4) -- it was first introduced in
com(4) and plcom(4) a year and a half ago:
Module Name: src
Committed By: jmcneill
Date: Mon Oct 11 18:39:06 UTC 2021
Modified Files:
src/sys/dev/ic: com.c
Log Message:
com: speed up close with HUPCL set
Instead of incurring a 1s penalty on close of a com device with HUPCL se=
t,
defer the sleep until the next open, and only sleep if necessary.
This has a side effect of making `ttyflags -a` with a default install not
pause for 1s for every non-console com device, which happens every boot
via /etc/rc.d/ttys.
https://mail-index.netbsd.org/source-changes/2021/10/11/msg132966.html
Module Name: src
Committed By: jmcneill
Date: Sun Oct 17 22:34:17 UTC 2021
Modified Files:
src/sys/arch/evbarm/dev: plcom.c plcomvar.h
Log Message:
plcom: speed up close with HUPCL set
Instead of incurring a 1s penalty on close of a plcom device with HUPCL =
set,
defer the sleep until the next open, and only sleep if necessary.
https://mail-index.netbsd.org/source-changes/2021/10/17/msg133107.html
I later later copied it in ucom(4) while doing other renovations to
make ucom(4) safe to yank concurrently with open/close and I/O:
Module Name: src
Committed By: riastradh
Date: Mon Mar 28 12:42:37 UTC 2022
Modified Files:
src/sys/dev/usb: ucom.c
Log Message:
ucom(4): Rework open/close/attach/detach logic.
- Defer sleep after hangup until open.
No need to make close hang; we just need to make sure some time has
passed before we next try to open.
This changes the wchan for the sleep. Oh well.
- Use .d_cfdriver/devtounit/cancel to resolve races between attach,
detach, open, close, and revoke.
- Use a separate .sc_closing flag instead of a UCOM_CLOSING state.
ucomcancel/ucomclose owns this flag, and it may be set in any state
(except UCOM_DEAD). UCOM_OPENING remains owned by ucomopen, which
might be interrupted by cancel/close.
- Rework error branches in ucomopen. Much simpler this way.
- Nix unnecessary reference counting.
https://mail-index.netbsd.org/source-changes/2022/03/28/msg137744.html
If you want to move the sleep back to close(2), I have no objection,
but it would be nice to find another way to avoid the unnecessary
boot-time delay that jmcneill had made the change to avoid.
If you want more information about the d_cancel/close split and why it
is so important for making things safe to yank and/or revoke
concurrently with open/close, I gave a talk last year at EuroBSDcon
about it:
https://www.NetBSD.org/gallery/presentations/riastradh/eurobsdcon2022/opend=
etach.pdf
(I acknowledge the medium is suboptimal for reference purposes, in
contrast to, say, fixing everything in the driver(9) man page, but my
round tuit supply for rototilling driver(9) has run short and there
have been other more pressing issues in netbsd-10 which have been
consuming my spoons.)
There is a large class of bugs in tty drivers, leading to potential
deadlocks and/or crashes if open and close happen concurrently, that
could likely be eliminated by just by setting .d_cancel =3D ttycancel in
the cdevsw. I haven't committed that change mostly because I don't
have hardware for anything other than com(4), plcom(4), and ucom(4),
and I got sidetracked by trying to make tty locking less of a
catastrophe -- which ideally would also allow us to remove the code
you quoted and leave ucom(4) with just .d_cancel =3D ttycancel.
From: Jason Thorpe <thorpej@me.com>
To: Taylor Campbell <riastradh@NetBSD.org>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Subject: Re: kern/57259: ucom serial ports cannot be re-opened "too quickly"
with O_NONBLOCK
Date: Sun, 5 Mar 2023 04:29:09 -0800
> On Mar 4, 2023, at 2:15 PM, Taylor R Campbell <riastradh@NetBSD.org> =
wrote:
>=20
> is now implemented by sleeping only for the _remainder_ of the 1sec
> delay in open(2):
Yes, as it turns out, there were a couple of bugs in that block of code. =
Most notably:
- In the case if a spurious wake, it would not wait for the full =
duration.
- Even suppressing EWOULDBLOCK (resulting in an ERESTART), it would =
simply fail with a spurious EINTR that I couldn=E2=80=99t determine =
where that was coming from (clearly from some higher-up layer).
I have a fix now that=E2=80=99s been tested for a few dozen rapid =
open-close-open cycles, and is not crashy in the face of pulling the =
device (which I did a couple of times).
-- thorpej
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Jason Thorpe <thorpej@me.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57259: ucom serial ports cannot be re-opened "too quickly"
with O_NONBLOCK
Date: Sun, 5 Mar 2023 12:39:40 +0000
> Date: Sun, 5 Mar 2023 04:29:09 -0800
> From: Jason Thorpe <thorpej@me.com>
>=20
> > On Mar 4, 2023, at 2:15 PM, Taylor R Campbell <riastradh@NetBSD.org> wr=
ote:
> >=20
> > is now implemented by sleeping only for the _remainder_ of the 1sec
> > delay in open(2):
>=20
> Yes, as it turns out, there were a couple of bugs in that block of
> code. Most notably:
>=20
> - In the case if a spurious wake, it would not wait for the full
> duration.
That's intentional. The job of .d_cancel is to make any concurrent
open or I/O wake and fail immediately, so that:
(a) close can finish promptly, and
(b) open will redo any permission checks after revoke.
Part (a) is arguable (is a delay of <1sec that bad? -- at least it
won't deadlock), but part (b) is mandatory -- if open sleeps and the
file is revoked because permissions have concurrently changed, open
MUST restart or fail.
> - Even suppressing EWOULDBLOCK (resulting in an ERESTART), it would
> simply fail with a spurious EINTR that I couldn't determine where
> that was coming from (clearly from some higher-up layer).
EINTR should only happen if a signal is delivered. If you're not sure
where that was coming from it bears further investigation. I don't
think tty(9) or condvar(9) will fabricate EINTR when there's no signal
pending.
> I have a fix now that's been tested for a few dozen rapid
> open-close-open cycles, and is not crashy in the face of pulling the
> device (which I did a couple of times).
Share the patch?
From: Jason Thorpe <thorpej@me.com>
To: Taylor Campbell <riastradh@NetBSD.org>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Subject: Re: kern/57259: ucom serial ports cannot be re-opened "too quickly"
with O_NONBLOCK
Date: Sun, 5 Mar 2023 04:46:26 -0800
> On Mar 5, 2023, at 4:39 AM, Taylor R Campbell <riastradh@NetBSD.org> =
wrote:
>=20
>> - Even suppressing EWOULDBLOCK (resulting in an ERESTART), it would
>> simply fail with a spurious EINTR that I couldn't determine where
>> that was coming from (clearly from some higher-up layer).
>=20
> EINTR should only happen if a signal is delivered. If you're not sure
> where that was coming from it bears further investigation. I don't
> think tty(9) or condvar(9) will fabricate EINTR when there's no signal
> pending.
Nope, you=E2=80=99re wrong. I found where it=E2=80=99s coming from:
error =3D vn_open(dvp, pb, TRYEMULROOT, flags, cmode,
&vp, &dupfd_move, &dupfd);
if (error !=3D 0) {
fd_abort(p, fp, indx);
if (error =3D=3D ERESTART)
error =3D EINTR;
return error;
}
That=E2=80=99s in do_open(). So the logic to return ERESTART here is =
just wrong, and it could have never worked as written.
-- thorpej
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Jason Thorpe <thorpej@me.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57259: ucom serial ports cannot be re-opened "too quickly"
with O_NONBLOCK
Date: Sun, 5 Mar 2023 12:56:44 +0000
> Date: Sun, 5 Mar 2023 04:46:26 -0800
> From: Jason Thorpe <thorpej@me.com>
>=20
> > On Mar 5, 2023, at 4:39 AM, Taylor R Campbell <riastradh@NetBSD.org> wr=
ote:
> >=20
> >> - Even suppressing EWOULDBLOCK (resulting in an ERESTART), it would
> >> simply fail with a spurious EINTR that I couldn't determine where
> >> that was coming from (clearly from some higher-up layer).
> >=20
> > EINTR should only happen if a signal is delivered. If you're not sure
> > where that was coming from it bears further investigation. I don't
> > think tty(9) or condvar(9) will fabricate EINTR when there's no signal
> > pending.
>=20
> Nope, you're wrong.
That was a hortative `should', not an informative `should'. It seems
my suspicion was right that tty(9) and condvar(9) aren't fabricating
this EINTR. Strikes me as a bug that open(2) would fabricate EINTR
when a signal has not been delivered.
> I found where it's coming from:
>=20
> error =3D vn_open(dvp, pb, TRYEMULROOT, flags, cmode,
> &vp, &dupfd_move, &dupfd);
> if (error !=3D 0) {
> fd_abort(p, fp, indx);
> if (error =3D=3D ERESTART)
> error =3D EINTR;
> return error;
> }
>=20
> That's in do_open(). So the logic to return ERESTART here is just
> wrong, and it could have never worked as written.
I tried chasing down where this ERESTART->EINTR map came from,
and...it's been buried by the AT&T lawsuit. It first appeared in
vfs_syscalls.c 1.31, but all revisions up through 1.30 were expunged
from history.
Sigh.
It's not obvious to me at all why open might not be restartable. The
man page only says:
[EINTR] The open() operation was interrupted by a signal.
It's obviously risky business to consider changing something like this
that has lurking been in the system for decades, but on the other
hand, Chesterton's fences are bad and should be abolished. So we
should try to figure out why this is happening.
From: "J. Hannken-Illjes" <hannken@mailbox.org>
To: NetBSD GNATS <gnats-bugs@netbsd.org>
Cc:
Subject: Re: kern/57259: ucom serial ports cannot be re-opened "too quickly"
with O_NONBLOCK
Date: Sun, 5 Mar 2023 14:08:29 +0100
--Apple-Mail=_B7EE0227-00F7-4374-936C-A68A2934D286
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
> On 5. Mar 2023, at 14:00, Taylor R Campbell <riastradh@NetBSD.org> wrote:
>
> I tried chasing down where this ERESTART->EINTR map came from,
> and...it's been buried by the AT&T lawsuit. It first appeared in
> vfs_syscalls.c 1.31, but all revisions up through 1.30 were expunged
> from history.
According to the CSRG repo this is:
--- vfs_syscalls.c (revision 40883)
+++ vfs_syscalls.c (revision 40884)
@@ -14,7 +14,7 @@
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*
- * @(#)vfs_syscalls.c 7.42 (Berkeley) 03/26/90
+ * @(#)vfs_syscalls.c 7.43 (Berkeley) 04/10/90
*/
#include "param.h"
@@ -530,8 +530,10 @@
if (error = vn_open(ndp, fmode, (cmode & 07777) &~ S_ISVTX)) {
crfree(fp->f_cred);
fp->f_count--;
- if (error == -1) /* XXX from fdopen */
- return (0); /* XXX from fdopen */
+ if (error == EJUSTRETURN) /* XXX from fdopen */
+ return (0); /* XXX from fdopen */
+ if (error == ERESTART)
+ error = EINTR;
scp->sc_ofile[indx] = NULL;
return (error);
}
with log message
r40884 | mckusick | 1990-04-10 22:36:33 +0200 (Tue, 10 Apr 1990) | 3 lines
eliminate longjmp from the kernel (for karels)
--
J. Hannken-Illjes - hannken@mailbox.org
--Apple-Mail=_B7EE0227-00F7-4374-936C-A68A2934D286
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEyLVMkhxs8fxixv+2IOocBq6p/bMFAmQElE0ACgkQIOocBq6p
/bPccg//SrrRwKlt8/I6ZBUum1Pqw79rHYRJZcTBVmQNmII+HlLw30fXJlJM+kKo
qyR+BIFZ+M3N1ZPKgQmkXS3ySFZk8kV92GjNlj705icS/UPo6NBdipAbOSOSeUrW
W1W+ZKMW+g3zFgqvrXHPkyFGQUy8dbaNyjeczQCTdOd4KQmu39dE0HNFYs9HbTUm
qKBNiPIrGyo2ZRCWCg31OxyxYBLIsW8RVCSiS60RLkhYb1Q+voOcbl450cPRCzZI
RhGKo2z8MZf29Bd2/xaSwtyHlNl7CmR/92NY+ShM2+LXvKWeHVkIxZZjJQEfjVAv
UWfM57zCjtJhnBojy+FvgFSf1CefL5/twmQ3XxpgW2sO7Pp+Qvp2bANLTAVLupxj
JcTMQ6Yg5sMu20VY6vUPFJlBuUbAvE8Dw9uiVp/AK99Qe8aqsK3gHfyyHSg2T9bI
agaflbf/d06F01CvtrgwF4cpucm0iOyoErkk/IjYAP+SRTTShFNw/HJ0sTSdqJke
b1i3v29uwPy60twZasnM6U3qOyVgN5CraLpzjhTKvIvu0Cc5tI3cshVz6LTCYMq7
8B91a42DBUIDcnVOqaLbZez4sxrOsjjESxwMGJE5/5AHs6ONQhQdX2ooNjgC3jmq
K0Nwltg3gZfuVGlu9+L7/RfFqCDGmroBcAlw2a8Mf2OA623A4hQ=
=gb48
-----END PGP SIGNATURE-----
--Apple-Mail=_B7EE0227-00F7-4374-936C-A68A2934D286--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Jason Thorpe <thorpej@me.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57259: ucom serial ports cannot be re-opened "too quickly"
with O_NONBLOCK
Date: Sun, 5 Mar 2023 13:15:32 +0000
I did some more digging and found what appears to be the CSRG BSD
commit that put this ERESTART->EINTR change into open:
https://github.com/robohack/ucb-csrg-bsd/commit/cce2869b7ae5d360921eb411005=
b328a29c4a3fe
commit cce2869b7ae5d360921eb411005b328a29c4a3fe
Author: Kirk McKusick <mckusick>
Date: Tue Apr 10 19:36:33 1990 -0800
eliminate longjmp from the kernel (for karels)
diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c
index 7bc7b39bbf..d572d3a32d 100644
--- a/sys/kern/vfs_syscalls.c
+++ b/sys/kern/vfs_syscalls.c
@@ -14,7 +14,7 @@
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*
- * @(#)vfs_syscalls.c 7.42 (Berkeley) 3/26/90
+ * @(#)vfs_syscalls.c 7.43 (Berkeley) 4/10/90
*/
=20
#include "param.h"
@@ -530,8 +530,10 @@ copen(scp, fmode, cmode, ndp, resultfd)
if (error =3D vn_open(ndp, fmode, (cmode & 07777) &~ S_ISVTX)) {
crfree(fp->f_cred);
fp->f_count--;
- if (error =3D=3D -1) /* XXX from fdopen */
- return (0); /* XXX from fdopen */
+ if (error =3D=3D EJUSTRETURN) /* XXX from fdopen */
+ return (0); /* XXX from fdopen */
+ if (error =3D=3D ERESTART)
+ error =3D EINTR;
scp->sc_ofile[indx] =3D NULL;
return (error);
}
This leaves me no more illuminated than before, but makes me suspect
it was a mistake in some unrelated change that is no longer relevant.
So now I'm wondering whether we should try to ask Kirk or just nix it
and see what happens...
State-Changed-From-To: open->needs-pullups
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sun, 05 Mar 2023 14:59:55 +0000
State-Changed-Why:
Fix committed to ucom.c, pullup requested to netbsd-10.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57259 CVS commit: src/sys/dev/usb
Date: Sun, 5 Mar 2023 23:28:54 +0000
Module Name: src
Committed By: riastradh
Date: Sun Mar 5 23:28:54 UTC 2023
Modified Files:
src/sys/dev/usb: ucom.c
Log Message:
ucom(4): Simplify logic fixing PR kern/57259.
cv_timedwait only ever returns 0 or EWOULDBLOCK, so this would always
return ERESTART anyway.
No functional change intended.
To generate a diff of this commit:
cvs rdiff -u -r1.137 -r1.138 src/sys/dev/usb/ucom.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57259 CVS commit: [netbsd-10] src/sys/dev/usb
Date: Tue, 7 Mar 2023 19:52:02 +0000
Module Name: src
Committed By: martin
Date: Tue Mar 7 19:52:02 UTC 2023
Modified Files:
src/sys/dev/usb [netbsd-10]: ucom.c
Log Message:
Pull up following revision(s) (requested by thorpej in ticket #113):
sys/dev/usb/ucom.c: revision 1.137
In the HUP-wait path in ucomopen():
- Use cv_timedwait() rather than cv_timedwait_sig(); the wait here is
bounded (and fairly short besides) and seems appropriate to treat like
other uninterruptible waits. The behavior is now consistent with com(4)
in this regard.
- Map EWOULDBLOCK return from cv_timedwait() to 0, as the successful passage
of time is not an error in this case.
- If the HUP-wait time has passed, clear the HUP-wait timestamp.
PR kern/57259 (although insufficient -- another change to vfs_syscalls.c
is required)
To generate a diff of this commit:
cvs rdiff -u -r1.134.2.1 -r1.134.2.2 src/sys/dev/usb/ucom.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: needs-pullups->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 02 Aug 2023 13:48:08 +0000
State-Changed-Why:
fixed in HEAD and pulled up to 10
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home