Re: [PATCH] writeback_inodes can race with unmount

From: Andrew Morton
Date: Tue Jun 08 2004 - 16:54:54 EST


Chris Mason <mason@xxxxxxxx> wrote:
>
> On Tue, 2004-06-08 at 15:57, Mika Penttilä wrote:
> > Chris Mason wrote:
> >
> > >There's a small window where the filesystem can be unmounted during
> > >writeback_inodes. The end result is the iput done by sync_sb_inodes
> > >could be done after the FS put_super and and the super has been removed
> > >from all lists.
> > >
> > >
> >
> > Why don't we have the same race in the sync() path as well? Moving the
> > locking to sync_sb_inodes() itself would fix it also.
>
> In the sync() path we're already taking a read lock on s_umount sem.
> Moving the locking into sync_sb_inodes would be tricky, it is sometimes
> called with the write lock on s_umount_sem held and sometimes with a
> read lock.
>

Plus we'd be dead if we had to do the above. If that read_trylock() fails
the sync() will forget to sync stuff.

And, contra your description, we'll fail the trylock relatively frequently
- when some other process is writing back this superblock.

But as this codepath is never used for data-integrity writeout things
should be OK. I'll slip a comment in there and maybe a
BUG_ON(wbc->sync_mode == WB_SYNC_ALL).

You didn't tell us where the window is? It's a bit weird that some other
process can come in and unmount the fs while there are non-zero-refcount
inodes floating about on the superblock.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/