> On 16. Jan 2022, at 23:41, Taylor R Campbell <riastradh%netbsd.org@localhost> wrote: > >> Date: Sat, 15 Jan 2022 21:23:56 +0000 >> From: Taylor R Campbell <riastradh%NetBSD.org@localhost> >> >> The attached patch series enables us to resolve a large class of races >> between devsw open/close, autoconf attach/detach, and module unload. > > Also introduced some bugs! > > - The devsw table management was broken for dynamically attached devsw > entries for statically allocated device major numbers. This broke > one of the fast(er) paths for statically linked devsw entries, but > it can be repaired without needing any memory barriers for them. > > - Holding fstrans across VOP_READ/WRITE prevented suspending file > systems with device vnodes for ttys that processes were waiting to > read from. Instead, these vops should take the new kind of specnode > I/O reference, while the vnode is unlocked. > > Updated patch addresses these. > > Unclear whether it is appropriate for VOP_CLOSE to use fstrans. Maybe > it too should use new specnode I/O references -- or perhaps it needn't > drop the vnode lock at all across bdev/cdev_close; generally blocking > indefinitely in a close routine strikes me as a bad idea. > <opendetach-v2.patch><opendetach-v2.diff> This doesn't work. Running the attached program on a current kernel: # ./revoke pty /dev/tty00, pid 2107 revoke /dev/tty00 read /dev/tty00 -> 0 done With your patch: # ./revoke pty /dev/tty00, pid 975 revoke /dev/tty00 and hangs hard. The revoke() operation enters spec_node_revoke() and here it waits forever for sn_iocnt to become zero. As the read from the other thread set sn_iocnt to one by entering through spec_io_enter() the system will hang until this read returns. Am I missing something? -- J. Hannken-Illjes - hannken%mailbox.org@localhost
Attachment:
revoke.c
Description: Binary data
Attachment:
signature.asc
Description: Message signed with OpenPGP