> On 1. Feb 2022, at 02:14, Taylor R Campbell <riastr...@netbsd.org> wrote: > >> Date: Mon, 31 Jan 2022 11:15:25 +0100 >> From: "J. Hannken-Illjes" <hann...@mailbox.org> >> >> Do you have a recipe so I could try it here? > > New draft, and script I've been using for testing. It just does cat > and revoke on a set of device nodes, repeatedly, in many processes in > parallel; at the same time, I yank the USB devices and reinsert them. > My test now survives with ucom(4), at least; other drivers will need > fixes -- but fixes which will generally be pullable-up to a branch!
As my main testbed is a virtual machine this doesn't work but it seems you already found a way to prevent these deadlocks. > I resolved the issue I was asking about by > > (a) having spec_node_lookup_by_dev optionally (when called by > vdevgone) wait with vcache_vget even for dying vnodes, so doing it > in a loop until none left waits until any revoke finishes; and > > (b) moving the hash table removal logic from spec_node_destroy to > spec_node_revoke, and making vcache_reclaim call spec_node_revoke > unconditionally for device vnodes. > > This way each specnode is only in the hash table while it's safe for > vcache_vget to be waiting for it, so vdevgone can safely wait for any > concurrent revoke to finish. Looks good so far. The new KASSERT(devvp->v_specnode->sn_opencnt) from spec_node_setmountedfs() fires for unmounts of udf fs as operation udf_vfsops.c::udf_unmount() closes the device BEFORE setmountedfs(). <snip> -- J. Hannken-Illjes - hann...@mailbox.org
signature.asc
Description: Message signed with OpenPGP