NetBSD Problem Report #56713
From paul@whooppee.com Mon Feb 14 15:58:33 2022
Return-Path: <paul@whooppee.com>
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 20C421A9239
for <gnats-bugs@gnats.NetBSD.org>; Mon, 14 Feb 2022 15:58:33 +0000 (UTC)
Message-Id: <20220214155827.886E630F2C4@speedy.whooppee.com>
Date: Mon, 14 Feb 2022 07:58:27 -0800 (PST)
From: paul@whooppee.com
Reply-To: paul@whooppee.com
To: gnats-bugs@NetBSD.org
Subject: Strange ``tail -f'' behaviour - likely kqueue-related
X-Send-Pr-Version: 3.95
>Number: 56713
>Category: kern
>Synopsis: Strange ``tail -f'' behaviour - likely kqueue-related
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: thorpej
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Feb 14 16:00:00 +0000 2022
>Closed-Date: Tue Jul 19 01:46:55 +0000 2022
>Last-Modified: Tue Jul 19 01:46:55 +0000 2022
>Originator: Paul Goyette
>Release: NetBSD 9.99.93
>Organization:
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
>Environment:
System: NetBSD speedy.whooppee.com 9.99.93 NetBSD 9.99.93 (SPEEDY 2022-01-08 03:00:28 UTC) #0: Sat Jan 8 13:04:35 UTC 2022 paul@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
I've been seeing some very odd behaviour lately, with ``tail -f'',
but I suspect it is a wider issue. (If someone confirms that this
really is a problem with tail(1) rather than with the kernel, please
feel free to recategorize the PR.)
I've got a bunch of packages being built (in a chroot sandbox), and
occassionally I do a ``tail -f'' on the current package's log file
just to make sure it is still making progress. So the file is open
by both the package-building shell and the tail process.
Occassionally the tail process fails to notice any further changes
to the file's size, and just sits there. The specific cases I've
looked at have all occurred immediately after the first 10-line
display (ie, the initial tail -10 output). Rather than following
additional changes to the log file, the tail process just hangs.
ps(1) shows the process is stuck in ``wchan=kqueue''. I've got
one such process that has been stuck for days - for this process,
the 'initial -10' output is more than 2.5kb of output being sent
to my xterm session before hanging!
I don't ever remember seeing this prior to my recent update from
9.99.92 to .93
>How-To-Repeat:
See above
>Fix:
please do
>Release-Note:
>Audit-Trail:
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56713 - tail -f doesn't follow (fwd)
Date: Sun, 6 Mar 2022 09:46:16 -0800 (PST)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-926920624-1646417808=:9907
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
Content-ID: <Pine.NEB.4.64.2203060945152.13724@speedy.whooppee.com>
Logging to PR ...
---------- Forwarded message ----------
Date: Fri, 4 Mar 2022 10:16:48 -0800 (PST)
From: Paul Goyette <paul@whooppee.com>
To: thorpej@netbsd.org
Cc: martin@netbsd.org
Subject: Re: kern/56713 - tail -f doesn't follow
Jason,
I tried to reproduce this in a simple test program (see attached,
especially see the coment at the top!). Unfortunately, it doesn't
seem to trigger. I used ktraace to ensure that the file-extend
happens between the creation of the eventlist and the wait-for-
event calls, so it should certainly trigger on the "pre-existing
event" guess from before. But no, it doesn't trigger.
I noticed that tail(1) does a whole lot more than just calling
kevent(). It appears to read from the file several times, and
also does an fstat and ioctl (which I did not decode). So maybe
the problem is really inside tail(1) itself and not inside the
kernel.
I saw on irc last night that mlelstv@ was able to easily repro
the problem using the null-mount, so perhaps that's important?
Thanks in advance for your help.
On Wed, 2 Mar 2022, Paul Goyette wrote:
> This is happening more and more frequently - today it is happening on
> every attempt to tail a log file that is still being written to.
>
> It "feels" like the kevent stuff isn't triggering on pre-existing
> events.
>
> I'm happy to help debug...
>
> Not sure but this feels like basic-functionality-regression which
> maybe ought to block the release.
>
>
> +--------------------+--------------------------+----------------------+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
> | & Network Engineer | | pgoyette99@gmail.com |
> +--------------------+--------------------------+----------------------+
>
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
--0-926920624-1646417808=:9907
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=TAIL.c
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.NEB.4.64.2203041016480.9907@speedy.whooppee.com>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME=TAIL.c
I2luY2x1ZGUgPGVyci5oPg0KI2luY2x1ZGUgPGZjbnRsLmg+DQojaW5jbHVk
ZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8dW5pc3RkLmg+DQoNCiNpbmNsdWRl
IDxzeXMvZXZlbnQuaD4NCiNpbmNsdWRlIDxzeXMvdGltZS5oPg0KDQovKg0K
ICogRXh0ZXJuYWwgc2V0LXVwIGNvZGUgaXMgZXhwZWN0ZWQgdG8gZG8gdGhl
IGVxdWl2YWxlbnQgb2YNCiAqCWNkICRUT1BESVINCiAqCW1rZGlyIHJlYWxk
aXINCiAqCW1rZGlyIG51bGxkaXINCiAqCW1vdW50IC10IG51bGwgJFRPUERJ
Ui9udWxsZGlyICRUT1BESVIvcmVhbGRpcg0KICoJcm0gLWYgJFRPUERJUi9y
ZWFsZGlyL3RoZWZpbGUNCiAqCXRvdWNoICRUT1BESVIvcmVhbGRpci90aGVm
aWxlDQogKiB0aGVuIGV4ZWN1dGUgdGhpcyB0ZXN0IHByb2dyYW06DQogKgku
L1RBSUwgJFRPUERJUi9yZWFsZGlyL3RoZWZpbGUgJFRPUERJUi9udWxsZGly
L3RoZWZpbGUNCiAqDQogKiBUaGUgZXhwZWN0ZWQgcmVzdWx0IGlzIHRoYXQg
dGhlIHdyaXRlKCkgdG8gdGhlIG51bGxmaWxlIHdpbGwNCiAqIHF1ZXVlIHVw
IGEgcHJlZXhpc3Rpbmcga2V2ZW50IHdoaWNoIHdpbGwgdGhlbiBiZSBkZXRl
Y3RlZCBieQ0KICogdGhlIChzZWNvbmQpIGNhbGwgdG8ga2V2ZW50KCk7IHRo
ZSBmYWlsdXJlIG1vZGUgaXMgdGhhdCB0aGUNCiAqIHdyaXRlKCkncyBleHRl
bnNpb24gdG8gdGhlIGZpbGUgaXMgbm90IHNlZW4sIGFuZCB0aGUga2V2ZW50
DQogKiBjYWxsIHRpbWVzIG91dCBhZnRlciA1IHNlY29uZHMuDQogKg0KICog
Q2xlYW4tdXAgY29kZSBzaG91bGQgdW5kbyB0aGUgbnVsbCBtb3VudCBhbmQg
ZGVsZXRlIGV2ZXJ5dGhpbmcNCiAqIGluIHRoZSB0ZXN0IGRpcmVjdG9yeS4N
CiAqLw0KDQppbnQgbWFpbihpbnQgYXJnYywgdm9pZCAqKmFyZ3YpDQp7DQoJ
aW50IHJlYWxmaWxlLCBudWxsZmlsZTsNCglpbnQga3EsIG5ldjsNCglzdHJ1
Y3QgdGltZXNwZWMgdGltZW91dDsNCglzdHJ1Y3Qga2V2ZW50IGV2ZW50bGlz
dDsNCgljb25zdCBjaGFyIGJ1ZltdID0gIm5ld1xuIjsNCg0KCWlmIChhcmdj
IDw9IDIpDQoJCWVycngoRVhJVF9GQUlMVVJFLCAiaW5zdWZmaWNpZW50IGFy
Z3MgJWQiLCBhcmdjKTsNCg0KCXJlYWxmaWxlID0gb3Blbihhcmd2WzFdLCBP
X1JET05MWSk7DQoJaWYgKHJlYWxmaWxlID09IC0xKQ0KCQllcnIoRVhJVF9G
QUlMVVJFLCAiZmFpbGVkIHRvIG9wZW4gcmVhbGZpbGUgJXMiLA0KCQkgICAg
YXJndlsxXSk7DQoNCgludWxsZmlsZSA9IG9wZW4oYXJndlsyXSwgT19XUk9O
TFksIE9fQVBQRU5EKTsNCglpZiAobnVsbGZpbGUgPT0gLTEpDQoJCWVycihF
WElUX0ZBSUxVUkUsICJmYWlsZWQgdG8gb3BlbiBudWxsZmlsZSAlcyIsDQoJ
CSAgICBhcmd2WzJdKTsNCg0KCWlmICgoa3EgPSBrcXVldWUoKSkgPT0gLTEp
DQoJCWVycihFWElUX0ZBSUxVUkUsICJDYW5ub3QgY3JlYXRlIGtxdWV1ZSIp
Ow0KDQoJdGltZW91dC50dl9zZWMgPSA1Ow0KCXRpbWVvdXQudHZfbnNlYyA9
IDA7DQoNCglFVl9TRVQoJmV2ZW50bGlzdCwgcmVhbGZpbGUsDQoJICAgIEVW
RklMVF9WTk9ERSwgRVZfQUREIHwgRVZfRU5BQkxFIHwgRVZfQ0xFQVIsDQoJ
ICAgIE5PVEVfV1JJVEUgfCBOT1RFX0VYVEVORCwgMCwgMCk7DQoJaWYgKGtl
dmVudChrcSwgJmV2ZW50bGlzdCwgMSwgTlVMTCwgMCwgTlVMTCkgPT0gLTEp
DQoJCWVycihFWElUX0ZBSUxVUkUsICJGYWlsZWQgdG8gc2V0IGV2ZW50bGlz
dCBmb3IgZmQgJWQiLA0KCQkgICAgcmVhbGZpbGUpOw0KDQoJd3JpdGUobnVs
bGZpbGUsICZidWYsIHNpemVvZihidWYpIC0gMSk7DQoNCgluZXYgPSBrZXZl
bnQoa3EsIE5VTEwsIDAsICZldmVudGxpc3QsIDEsICZ0aW1lb3V0KTsNCglp
ZiAobmV2ID09IC0xKQ0KCQllcnIoRVhJVF9GQUlMVVJFLCAiRmFpbGVkIHRv
IHJldHJpZXZlIGV2ZW50Iik7DQoNCgllcnJ4KEVYSVRfU1VDQ0VTUywgIlJl
dHJpZXZlZCAlZCBldmVudHMsIGZpcnN0IDB4JXgiLA0KCSAgICBuZXYsIGV2
ZW50bGlzdC5mbGFncyk7DQp9DQo=
--0-926920624-1646417808=:9907--
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56713 - tail -f doesn't follow (fwd)
Date: Sun, 6 Mar 2022 09:46:46 -0800 (PST)
Logging to PR
---------- Forwarded message ----------
Date: Sun, 6 Mar 2022 09:44:19 -0800 (PST)
From: Paul Goyette <paul@whooppee.com>
To: thorpej@netbsd.org
Cc: martin@netbsd.org
Subject: Re: kern/56713 - tail -f doesn't follow
I still cannot get my test program to fail, but I have looked a bit
closer into what's going on.
I modified tail's forward.c to do a few printf()s before calls to
kevent(). I'm using a pkg_build for gnucash to generate the target
log file, but anything can substitute.
xtail on log file provides the last 10 lines of the file. The following (11th)
line would start with "===> Skipping vulnerability checks."
...
=> Full dependency swig3>=3.0.12: found swig3-3.0.12nb4
=> Full dependency hicolor-icon-theme>=0.9nb1: found hicolor-icon-theme-0.17nb1
=> Full dependency gdk-pixbuf2>=2.42.6: found gdk-pixbuf2-2.42.6nb1
=> Full dependency guile22>=2.2.7nb3: found guile22-2.2.7nb4
=> Full dependency desktop-file-utils>=0.10nb1: found
desktop-file-utils-0.26nb1
=> Full dependency icu>=70.1: found icu-70.1
=> Full dependency libxml2>=2.9.12nb1: found libxml2-2.9.12nb2
=> Full dependency libxslt>=1.1.34nb6: found libxslt-1.1.34nb7
=> Full dependency webkit-gtk>=2.34.2: found webkit-gtk-2.34.6
=> Full dependency gtk3+>=3.24.30nb1: found gtk3+-3.24.31
At this point, xtail's ktrace shows one of my test printf's,
followed by the set-watchlist kevent call, followed by an attempt
to read any new data that might exist (there is none), followed
by the kevent() call to wait-for-event. The latter shows that
it never returns, until I press ^C
...
20519 20519 xtail 1646584937.737532152 CALL write(1,0x764d4e699000,0x23)
20519 20519 xtail 1646584937.737534380 GIO fd 1 wrote 35 bytes
"forward: ADD_EVENTS: kevent( n=1 )\n"
20519 20519 xtail 1646584937.737534576 RET write 35/0x23
20519 20519 xtail 1646584937.737535715 CALL
__kevent50(4,0x7f7fff1f5ab0,1,0,0,0)
20519 20519 xtail 1646584937.737537464 RET __kevent50 0
20519 20519 xtail 1646584937.737537905 CALL read(3,0x764d4e69a040,0x8000)
20519 20519 xtail 1646584937.737538452 GIO fd 3 read 0 bytes
""
20519 20519 xtail 1646584937.737538685 RET read 0
20519 20519 xtail 1646584937.737539221 CALL
__kevent50(4,0,0,0x7f7fff1f5ab0,1,0)
20519 20519 xtail 1646585057.253611154 RET __kevent50 -1 errno 4
Interrupted system call
Note that the call to kevent() to establish the event watch-list is at
timestamp 37.737535715, and the never-ending wait starts at timestamp
37.737539221
From the ktrace of the process writing to the log file we see the
point where it writes the next line:
29343 29343 sh 1646584941.086235727 CALL write(1,0x74bbbc55b000,0x24)
29343 29343 sh 1646584941.086240495 GIO fd 1 wrote 36 bytes
"===> Skipping vulnerability checks.\n"
29343 29343 sh 1646584941.086240792 RET write 36/0x24
The write to the log file for the "===> Skipping ..." text occurred
at 41.086240495 which is after the kevent() starts waiting, so it
should have triggered the kevent.
I tried to update my test program to add the read-new-data but it
still doesn't fail. :(
I'm quickly reaching my limit of understanding here...
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: Paul Goyette <paul@whooppee.com>
To: thorpej@netbsd.org
Cc: martin@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/56713 - I have a test program!
Date: Sun, 6 Mar 2022 10:49:20 -0800 (PST)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1557645311-1646592560=:880
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
My previous program was all good, except for the comment about
mounting the nulldir! I had the mount command backwards!
With the attached program, I get
# pwd
/home/paul/ZZZ
# mkdir realdir
# mkdir nulldir
# mount -t null nulldir realdir
mount_null: "realdir" is a relative path.
mount_null: using "/home/paul/ZZZ/realdir" instead.
# rm -f realdir/thefile
# touch realdir/thefile
# ./TAIL realdir/thefile nulldir/thefile
TAIL: Retrieved 0 events, first 0x25
#
Sure enough, the test program receives no events, and exits when
the kevent()'s timeout is reached!
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
--0-1557645311-1646592560=:880
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=TAIL.c
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.NEB.4.64.2203061049200.880@speedy.whooppee.com>
Content-Description:
Content-Disposition: attachment; filename=TAIL.c
I2luY2x1ZGUgPGVyci5oPg0KI2luY2x1ZGUgPGZjbnRsLmg+DQojaW5jbHVk
ZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8dW5pc3RkLmg+DQoNCiNpbmNsdWRl
IDxzeXMvZXZlbnQuaD4NCiNpbmNsdWRlIDxzeXMvdGltZS5oPg0KDQovKg0K
ICogRXh0ZXJuYWwgc2V0LXVwIGNvZGUgaXMgZXhwZWN0ZWQgdG8gZG8gdGhl
IGVxdWl2YWxlbnQgb2YNCiAqCWNkICRUT1BESVINCiAqCW1rZGlyIHJlYWxk
aXINCiAqCW1rZGlyIG51bGxkaXINCiAqCW1vdW50IC10IG51bGwgJFRPUERJ
Ui9yZWFsZGlyICRUT1BESVIvbnVsbGRpcg0KICoJcm0gLWYgJFRPUERJUi9y
ZWFsZGlyL3RoZWZpbGUNCiAqCXRvdWNoICRUT1BESVIvcmVhbGRpci90aGVm
aWxlDQogKiB0aGVuIGV4ZWN1dGUgdGhpcyB0ZXN0IHByb2dyYW06DQogKgku
L1RBSUwgJFRPUERJUi9yZWFsZGlyL3RoZWZpbGUgJFRPUERJUi9udWxsZGly
L3RoZWZpbGUNCiAqDQogKiBUaGUgZXhwZWN0ZWQgcmVzdWx0IGlzIHRoYXQg
dGhlIHdyaXRlKCkgdG8gdGhlIG51bGxmaWxlIHdpbGwNCiAqIHF1ZXVlIHVw
IGEgcHJlZXhpc3Rpbmcga2V2ZW50IHdoaWNoIHdpbGwgdGhlbiBiZSBkZXRl
Y3RlZCBieQ0KICogdGhlIChzZWNvbmQpIGNhbGwgdG8ga2V2ZW50KCk7IHRo
ZSBmYWlsdXJlIG1vZGUgaXMgdGhhdCB0aGUNCiAqIHdyaXRlKCkncyBleHRl
bnNpb24gdG8gdGhlIGZpbGUgaXMgbm90IHNlZW4sIGFuZCB0aGUga2V2ZW50
DQogKiBjYWxsIHRpbWVzIG91dCBhZnRlciA1IHNlY29uZHMuDQogKg0KICog
Q2xlYW4tdXAgY29kZSBzaG91bGQgdW5kbyB0aGUgbnVsbCBtb3VudCBhbmQg
ZGVsZXRlIGV2ZXJ5dGhpbmcNCiAqIGluIHRoZSB0ZXN0IGRpcmVjdG9yeS4N
CiAqLw0KDQppbnQgbWFpbihpbnQgYXJnYywgdm9pZCAqKmFyZ3YpDQp7DQoJ
aW50IHJlYWxmaWxlLCBudWxsZmlsZTsNCglpbnQga3EsIG5ldiwgcnNpemU7
DQoJc3RydWN0IHRpbWVzcGVjIHRpbWVvdXQ7DQoJc3RydWN0IGtldmVudCBl
dmVudGxpc3Q7DQoJY29uc3QgY2hhciBvdXRidWZbXSA9ICJuZXdcbiI7DQoJ
Y2hhciBpbmJ1ZlsyMF07DQoNCglpZiAoYXJnYyA8PSAyKQ0KCQllcnJ4KEVY
SVRfRkFJTFVSRSwgImluc3VmZmljaWVudCBhcmdzICVkIiwgYXJnYyk7DQoN
CglyZWFsZmlsZSA9IG9wZW4oYXJndlsxXSwgT19SRE9OTFkpOw0KCWlmIChy
ZWFsZmlsZSA9PSAtMSkNCgkJZXJyKEVYSVRfRkFJTFVSRSwgImZhaWxlZCB0
byBvcGVuIHJlYWxmaWxlICVzIiwNCgkJICAgIGFyZ3ZbMV0pOw0KDQoJbnVs
bGZpbGUgPSBvcGVuKGFyZ3ZbMl0sIE9fV1JPTkxZLCBPX0FQUEVORCk7DQoJ
aWYgKG51bGxmaWxlID09IC0xKQ0KCQllcnIoRVhJVF9GQUlMVVJFLCAiZmFp
bGVkIHRvIG9wZW4gbnVsbGZpbGUgJXMiLA0KCQkgICAgYXJndlsyXSk7DQoN
CglpZiAoKGtxID0ga3F1ZXVlKCkpID09IC0xKQ0KCQllcnIoRVhJVF9GQUlM
VVJFLCAiQ2Fubm90IGNyZWF0ZSBrcXVldWUiKTsNCg0KCXRpbWVvdXQudHZf
c2VjID0gNTsNCgl0aW1lb3V0LnR2X25zZWMgPSAwOw0KDQoJRVZfU0VUKCZl
dmVudGxpc3QsIHJlYWxmaWxlLA0KCSAgICBFVkZJTFRfVk5PREUsIEVWX0FE
RCB8IEVWX0VOQUJMRSB8IEVWX0NMRUFSLA0KCSAgICBOT1RFX1dSSVRFIHwg
Tk9URV9FWFRFTkQsIDAsIDApOw0KCWlmIChrZXZlbnQoa3EsICZldmVudGxp
c3QsIDEsIE5VTEwsIDAsIE5VTEwpID09IC0xKQ0KCQllcnIoRVhJVF9GQUlM
VVJFLCAiRmFpbGVkIHRvIHNldCBldmVudGxpc3QgZm9yIGZkICVkIiwNCgkJ
ICAgIHJlYWxmaWxlKTsNCg0KCXJzaXplID0gcmVhZChyZWFsZmlsZSwgJmlu
YnVmLCBzaXplb2YoaW5idWYpKTsNCglpZiAocnNpemUpDQoJCWVycngoRVhJ
VF9GQUlMVVJFLCAiT29vcHMgd2UgZ290ICVkIGJ5dGVzIG9mIGRhdGEhXG4i
LCByc2l6ZSk7DQoNCgl3cml0ZShudWxsZmlsZSwgJm91dGJ1Ziwgc2l6ZW9m
KG91dGJ1ZikgLSAxKTsNCg0KCW5ldiA9IGtldmVudChrcSwgTlVMTCwgMCwg
JmV2ZW50bGlzdCwgMSwgJnRpbWVvdXQpOw0KCWlmIChuZXYgPT0gLTEpDQoJ
CWVycihFWElUX0ZBSUxVUkUsICJGYWlsZWQgdG8gcmV0cmlldmUgZXZlbnQi
KTsNCg0KCWVycngoRVhJVF9TVUNDRVNTLCAiUmV0cmlldmVkICVkIGV2ZW50
cywgZmlyc3QgMHgleCIsDQoJICAgIG5ldiwgZXZlbnRsaXN0LmZsYWdzKTsN
Cn0NCg==
--0-1557645311-1646592560=:880--
Responsible-Changed-From-To: kern-bug-people->thorpej
Responsible-Changed-By: thorpej@NetBSD.org
Responsible-Changed-When: Mon, 07 Mar 2022 21:52:37 +0000
Responsible-Changed-Why:
Take.
From: "Paul Goyette" <pgoyette@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56713 CVS commit: src
Date: Fri, 29 Apr 2022 22:17:50 +0000
Module Name: src
Committed By: pgoyette
Date: Fri Apr 29 22:17:50 UTC 2022
Modified Files:
src/distrib/sets/lists/debug: mi
src/distrib/sets/lists/tests: mi
src/etc/mtree: NetBSD.dist.tests
src/tests/lib/libc: Makefile
Added Files:
src/tests/lib/libc/kevent_nullmnt: Makefile h_nullmnt.c t_nullmnt.sh
Log Message:
Add a new test for PR kern/56713 and set to expected_failure for now.
To generate a diff of this commit:
cvs rdiff -u -r1.376 -r1.377 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1200 -r1.1201 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.190 -r1.191 src/etc/mtree/NetBSD.dist.tests
cvs rdiff -u -r1.51 -r1.52 src/tests/lib/libc/Makefile
cvs rdiff -u -r0 -r1.1 src/tests/lib/libc/kevent_nullmnt/Makefile \
src/tests/lib/libc/kevent_nullmnt/h_nullmnt.c \
src/tests/lib/libc/kevent_nullmnt/t_nullmnt.sh
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56713: Strange ``tail -f'' behaviour - likely kqueue-related
Date: Sat, 30 Apr 2022 14:03:30 -0700 (PDT)
Using the atf test's helper program I have noticed that it does
not matter if you use the "real" file or the "null-mount" file
in the kevent() call. In either case, writing to the "real"
file generates a kevent correctly, while writing to the "null-
mount" file does not generate any kevent (and the test program
times out).
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+--------------------+--------------------------+----------------------+
From: "Paul Goyette" <pgoyette@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56713 CVS commit: src/tests/lib/libc/kevent_nullmnt
Date: Mon, 30 May 2022 03:33:07 +0000
Module Name: src
Committed By: pgoyette
Date: Mon May 30 03:33:07 UTC 2022
Modified Files:
src/tests/lib/libc/kevent_nullmnt: t_nullmnt.sh
Log Message:
Update test so all four combinations of update_{upper, lower} x
monitor_{upper, lower}} can be verified. Currently update_upper
is expected to fail regardless of which file is being monitored.
PR kern/56713
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libc/kevent_nullmnt/t_nullmnt.sh
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->analyzed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Mon, 11 Jul 2022 19:03:41 +0000
State-Changed-Why:
Root cause identified and fix being prepared.
State-Changed-From-To: analyzed->feedback
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Mon, 18 Jul 2022 04:33:53 +0000
State-Changed-Why:
Fix is checked in, please confirm it's working for you!
From: "Jason R Thorpe" <thorpej@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56713 CVS commit: src
Date: Mon, 18 Jul 2022 04:30:31 +0000
Module Name: src
Committed By: thorpej
Date: Mon Jul 18 04:30:31 UTC 2022
Modified Files:
src/sys/fs/union: union_subr.c
src/sys/kern: vfs_vnode.c vfs_vnops.c vnode_if.sh
src/sys/miscfs/genfs: layer_vfsops.c
src/sys/sys: param.h vnode.h vnode_impl.h
src/tests/lib/libc/kevent_nullmnt: t_nullmnt.sh
Log Message:
Make kqueue event status for vnodes shareable, and for stacked file systems
like nullfs, make the upper vnode share that status with the lower vnode.
And, lo, NetBSD 9.99.99.
Fixes PR kern/56713.
To generate a diff of this commit:
cvs rdiff -u -r1.81 -r1.82 src/sys/fs/union/union_subr.c
cvs rdiff -u -r1.143 -r1.144 src/sys/kern/vfs_vnode.c
cvs rdiff -u -r1.233 -r1.234 src/sys/kern/vfs_vnops.c
cvs rdiff -u -r1.75 -r1.76 src/sys/kern/vnode_if.sh
cvs rdiff -u -r1.54 -r1.55 src/sys/miscfs/genfs/layer_vfsops.c
cvs rdiff -u -r1.711 -r1.712 src/sys/sys/param.h
cvs rdiff -u -r1.301 -r1.302 src/sys/sys/vnode.h
cvs rdiff -u -r1.23 -r1.24 src/sys/sys/vnode_impl.h
cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/kevent_nullmnt/t_nullmnt.sh
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Jason R Thorpe" <thorpej@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56713 CVS commit: src/sys
Date: Mon, 18 Jul 2022 04:32:35 +0000
Module Name: src
Committed By: thorpej
Date: Mon Jul 18 04:32:35 UTC 2022
Modified Files:
src/sys/kern: vnode_if.c
src/sys/rump/include/rump: rumpvnode_if.h
src/sys/rump/librump/rumpvfs: rumpvnode_if.c
src/sys/sys: vnode_if.h
Log Message:
Regen for:
Make kqueue event status for vnodes shareable, and for stacked file systems
like nullfs, make the upper vnode share that status with the lower vnode.
And, lo, NetBSD 9.99.99.
Fixes PR kern/56713.
To generate a diff of this commit:
cvs rdiff -u -r1.117 -r1.118 src/sys/kern/vnode_if.c
cvs rdiff -u -r1.39 -r1.40 src/sys/rump/include/rump/rumpvnode_if.h
cvs rdiff -u -r1.39 -r1.40 src/sys/rump/librump/rumpvfs/rumpvnode_if.c
cvs rdiff -u -r1.110 -r1.111 src/sys/sys/vnode_if.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: feedback->closed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Tue, 19 Jul 2022 01:46:55 +0000
State-Changed-Why:
Confirmed closed by originator.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.