linux-ext4 - Re: EXT4-fs (dm-1): Couldn't remount RDWR because of unprocessed orphan inode list

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, 5 Oct 2011 20:03:39 +0200
From:	Jan Kara <jack@...e.cz>
To:	Christian Kujau <lists@...dbynature.de>
Cc:	Jan Kara <jack@...e.cz>, Eric Sandeen <sandeen@...hat.com>,
	linux-ext4@...r.kernel.org, mszeredi@...e.cz,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: EXT4-fs (dm-1): Couldn't remount RDWR because of unprocessed
 orphan inode list

On Thu 15-09-11 20:49:19, Christian Kujau wrote:
> On Mon, 12 Sep 2011 at 21:52, Christian Kujau wrote:
> > On Sat, 10 Sep 2011 at 22:04, Jan Kara wrote:
> > > On Fri 09-09-11 18:11:26, Christian Kujau wrote:
> > > > On Thu, 8 Sep 2011 at 20:51, Jan Kara wrote:
> > > > > There's race where VFS remount code can race with unlink and result will
> > > > > be unlinked file in orphan list on read-only filesystem. Christian seems to
> > > > > be hitting this race. Miklos Szeredi has patches
> > > > > (http://lkml.indiana.edu/hypermail/linux/kernel/1108.3/00169.html) to
> > > > > mostly close this hole but they're waiting for Al to find time to look at
> > > > > them / merge them AFAIK.
> > > > 
> > > > While these patches are still pending review, are they "dangerous" to 
> > > > apply? If not, I'd like to volunteer as a tester :-)
> > >   As far as I saw them, they should be pretty safe. So feel free to test
> > > them.
> > 
> > I've applied them to -rc5. It might take a few days untile the message 
> > occurs. Or, until "nothing happens", since I have the patches applied :-)
> 
> With Miklos' patches applied to -rc5, this happend again just now :-(
  Thanks for careful testing! Hmm, since you are able to reproduce on ppc
but not on x86 there might be some memory ordering bug in Miklos' patches
or it's simply because of different timing. Miklos, care to debug this
further?

> > Meanwhile I'm trying to reproduce this issue on an x86 machine, but 
> > haven't succeeded yet.
> 
> After a ~3k remounts with constantly reading from the filesystem in 
> question[0], I still was NOT able to reproduce this on an x86 VM :(
> 
> Any ideas?


								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html