linux-kernel - Re: do_remount_sb(RDONLY) race? (was: XFS oops under 2.6.23.9)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Jan 2008 16:24:33 +1030 (CST)
From:	Jonathan Woithe <jwoithe@...sics.adelaide.edu.au>
To:	dgc@....com (David Chinner)
Cc:	jwoithe@...sics.adelaide.edu.au (Jonathan Woithe),
	linux-kernel@...r.kernel.org
Subject: Re: do_remount_sb(RDONLY) race? (was: XFS oops under 2.6.23.9)

Hi Dave

> 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=516b2e7c2661615ba5d5ad9fb584f068363502d3
> 
> 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....

Thanks for the patch.  I will apply it and see what happens.

Will this be in 2.6.24?

Regards
  jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/