> On Wed, Jan 23, 2008 at 03:00:48PM +1030, Jonathan Woithe wrote:
> > Last night my laptop suffered an oops during closedown. The full oops
> > reports can be downloaded from
> >
> >
http://www.atrad.com.au/~jwoithe/xfs_oops/
>
> Assertion failed: atomic_read(&mp->m_active_trans) == 0, file:
> fs/xfs/xfs_vfsops.c, line 689.
>
> The remount read-only of the root drive supposedly completed
> while there was still active modification of the filesystem
> taking place.
>
> > Kernel version was kernel.org 2.6.23.9 compiled as a low latency desktop.
>
> The patch in 2.6.23 that introduced this check was:
>
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=516b2e7c26...
>
> Basically, the remount-readonly path was not flushing things
> properly, so we changed it to flushing things properly and ensure we
> got bug reports if it wasn't. Yours is the second report of not
> shutting down correctly since this change went in (we've seen it
> once in ~8 months in a QA environment).
>
> I've had suspicions of a race in the remount-ro code in
> do_remount_sb() w.r.t to the fs_may_remount_ro() check. That is, we
> do an unlocked check to see if we can remount readonly and then fail
> to check again once we've locked the superblock out and start the
> remount.
>
> The read only flag only gets set *after* we've made the filesystem
> readonly, which means before we are truly read only, we can race
> with other threads opening files read/write or filesystem
> modifcations can take place.
>
> The result of that race (if it is really unsafe) will be assert you
> see. The patch I wrote a couple of months ago to fix the problem
> is attached below....
