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:

Home	PR Database Search