Date: Wed, 13 Jul 2022 08:42:29 +0930 From: "Daniel O'Connor" <darius@dons.net.au> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: VFS mount rollback for virtio 9pfs Message-ID: <A6539252-5E60-4F88-B7CD-A1248598D722@dons.net.au> In-Reply-To: <Ys2GIIGXiWIFChWP@nuc> References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <Ys2GIIGXiWIFChWP@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 13 Jul 2022, at 00:03, Mark Johnston <markj@freebsd.org> wrote:
>> This was easily fixed but I want to make the handling of a similar =
error in future correct. The virtfs_unmount code as it stands will fail =
when the kernel tries to rollback the mount. The end result is the ref =
count for the file system is not decremented so the KLD can't be =
unloaded.
>=20
> How does virtfs_unmount() fail? The tsleep() call there looks
> suspicious, it's using the address of a local variable as a wait
> channel, so I don't understand how it'll ever get signalled.
Yes good point, I don't think it ever gets woken up - it just times out.
Without any changes (ie what is in my git tree at now) it returns EBUSY.
If I change it like so:
if (mntflags & MNT_FORCE || mp->mnt_kern_flag & MNTK_UNMOUNTF)
flags |=3D FORCECLOSE;
And then later to squash the return value to 0 if FORCECLOSE is set then =
mount hangs:
load: 0.46 cmd: mount 988 [mntref] 1.42r 0.00u 0.03s 0% 2252k
mi_switch+0xc2 _sleep+0x1fc vfs_mount_destroy+0xa4 =
vfs_domount_first+0x382 vfs_domount+0x2ad vfs_donmount+0x8f8 =
sys_nmount+0x69 amd64_syscall+0x10c fast_syscall_common+0xf8
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6539252-5E60-4F88-B7CD-A1248598D722>