Re: [PATCH for-2.6.33] xfs: flush all log buffers in xlog_dealloc_log

Dave Chinner
2010-02-05T02:57:06Z

On Thu, Feb 04, 2010 at 11:10:50AM -0500, Christoph Hellwig wrote:
> On Thu, Feb 04, 2010 at 07:14:22PM +1100, Dave Chinner wrote:
> > On Wed, Feb 03, 2010 at 05:55:45AM -0500, Christoph Hellwig wrote:
> > > Actually I'll take this one back - the log buffers aren't delwri
> > > so xfs_flush_buftarg probably only helped by timing or the
> > > xfs_buf_runall_queues on xfslogd_workqueue. Need to think about
> > > this a bit more.
> >
> > Can you point me at the bug report? IIRC I've seen this in the
> > past where we freed the log before we've done all the correct
> > shutdown processing and they got fixed by correcting the
> > order of shutdown to ensure the log is idle before freeing
> > it...
>
> Yes, that I was going to look into next. The recent report
> is http://bugzilla.kernel.org/show_bug.cgi?id=15150

That was from 2.6.27. I didn't think that we finished the
mount/unmount path cleanup that fixed all those problems until
2.6.28 or .29...

> and there's
> also a very similar one from Ed Cashin <ecashin@coraid.com> in
> mail archives from November.

Yeah, that's clearly IO completion after the call to
xfs_unmountfs_wait(). That does a xfs_wait_buftarg() call
which waits for all hashed buffers on the buftarg except for
those that are XBF_FS_MANAGED - the superblock.

Looking at xfs_fs_put_super(), the superblock buffer is freed after
xfs_unmountfs() frees the log, so if the superblock was logged
and is undergoing IO then xfs_unmountfs_wait() would not have
blocked on it and it could leak past the "no more IO should
bein progress" barrier that xfs_unmountfs_wait() is supposed to
provide.

Does this look like a plausible cause of the problem?

Is so, given that the superblock is the only buffer that is marked
XBF_FS_MANAGED now and it seems to me that xfs_wait_buftarg()
should be waiting on it, maybe the fix needed is to
xfs_wait_buftarg()....

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com