Hi!
> tst_test.c:1161: INFO: Testing on vfat
> tst_mkfs.c:90: INFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
> mkfs.vfat: unable to open /dev/loop0: Device or resource busy
> tst_mkfs.c:101: BROK: mkfs.vfat:1: tst_test.c failed with 741
This looks like mkfs.vfat got EBUSY after the loop device was
succesfully umounted.
We do run the test in a loop for several filesystems and the loop
generally does:
next:
mkfs
mount
test
umount
goto next;
--
Cyril Hrubis
[email protected]
On Thu, Jul 25, 2019 at 6:26 AM Cyril Hrubis <[email protected]> wrote:
>
> This looks like mkfs.vfat got EBUSY after the loop device was
> succesfully umounted.
Hmm. Smells like the RCU-delaying got triggered again.
We have that "synchronize_rcu_expedited()" in namespace_unlock(),
which is so that everything should be done by the time we return to
user space.
Al, maybe that RCU synchronization should be after the mntput()s?
Linus
On Thu, Jul 25, 2019 at 09:32:13AM -0700, Linus Torvalds wrote:
> On Thu, Jul 25, 2019 at 6:26 AM Cyril Hrubis <[email protected]> wrote:
> >
> > This looks like mkfs.vfat got EBUSY after the loop device was
> > succesfully umounted.
>
> Hmm. Smells like the RCU-delaying got triggered again.
>
> We have that "synchronize_rcu_expedited()" in namespace_unlock(),
> which is so that everything should be done by the time we return to
> user space.
>
> Al, maybe that RCU synchronization should be after the mntput()s?
There are several interesting issues in there, but synchronize_rcu()
should be between zeroing ->mnt_ns and dropping the final refs.
I'm digging through that crap right now; at least one bug is dealt
with by #fixes, but there's more, unfortunately.
On Thu, Jul 25, 2019 at 07:04:28PM +0100, Al Viro wrote:
> On Thu, Jul 25, 2019 at 09:32:13AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 25, 2019 at 6:26 AM Cyril Hrubis <[email protected]> wrote:
> > >
> > > This looks like mkfs.vfat got EBUSY after the loop device was
> > > succesfully umounted.
> >
> > Hmm. Smells like the RCU-delaying got triggered again.
> >
> > We have that "synchronize_rcu_expedited()" in namespace_unlock(),
> > which is so that everything should be done by the time we return to
> > user space.
> >
> > Al, maybe that RCU synchronization should be after the mntput()s?
>
> There are several interesting issues in there, but synchronize_rcu()
> should be between zeroing ->mnt_ns and dropping the final refs.
> I'm digging through that crap right now; at least one bug is dealt
> with by #fixes, but there's more, unfortunately.
No, it's not synchronize_rcu(). It's a bug dealt with in vfs.git #fixes,
triggering the struct mount leak in mount_subtree(), which is used
by btrfs. Immediately prior to vfat in their list...
(oh, and AFAICS "more" in the above had been a mismerge in -next, so
it might really be all there is to it)
Folks, see if vfs.git #fixes solves that one.