linux-kernel - Re: Bug with "fix partial page writes" [3.2-rc regression]

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:	Tue, 6 Dec 2011 14:47:02 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
cc:	Ted Ts'o <tytso@....edu>, Curt Wohlgemuth <curtw@...gle.com>,
	Yongqiang Yang <xiaoqiangnk@...il.com>,
	Surbhi Palande <csurbhi@...il.com>,
	Rafael Wysocki <rjw@...k.pl>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Bug with "fix partial page writes" [3.2-rc regression]

On Tue, 6 Dec 2011, Allison Henderson wrote:
> On 12/06/2011 01:55 AM, Hugh Dickins wrote:
> > On Mon, 5 Dec 2011, Allison Henderson wrote:
> > > 
> > > Have you tried Yongqiang's patch "[PATCH 1/2] ext4: let mpage_submit_io
> > > works well when blocksize<  pagesize" ?  I have tried it and it does
> > > seem to
> > > help, but I am still running into some failures that I am trying to
> > > debug,
> > > but let please let us know if it helps the issues that you are seeing.
> > > Thx!
> > 
> > That 1/2, or the 2/2 "ext4: let ext4_discard_partial_buffers handle
> > pages without buffers correctly"?  The latter is mostly a reversion
> > of your 02fac1297eb3, so that's the one I need to fix the oops and
> > rare data corruption.  Perhaps you're suggesting 1/2 for fsx failures
> > under memory pressure?
> > 
> > I've now tried the fsx test on three machines, with both 1/2 and 2/2
> > applied to 3.2-rc4.  On one machine, with ext2 on loop on tmpfs, the
> > fsx test failed in a couple of minutes with those patches; on another
> > machine, with ext2 on loop on tmpfs, it failed after about 40 minutes
> > with  the patches; on this laptop, with ext2 on SSD, it's just now
> > failed after 35 minutes with the patches.
> > 
> > That's not to say that Yongqiang's patches aren't good; but I cannot
> > detect whether they make any improvement or not, since lasting for 2 or
> > 40 minutes is typical for fsx under memory pressure with recent kernels.
> 
> 
> Well, initially I meant to just try the whole set, but now that I try just
> one of them, I find that I get further with only the first one.  I think
> Yongqiang and I have a similar set up because I get the hang if I dont have
> the first patch, and I get the fsx write failure (in about 20 or so minutes)
> if I have the second one.  But I think Yongqiang's right, we need to figure
> out why the page is uptodate when it shouldn't be.

I've not seen a hang myself.  I'm reluctant to drop the second patch,
since it appears to fix the real problems (oops and corruption) that
I have seen, and fsx fails with or without it; but I don't know whether
it's any better than simply reverting yours.

I would certainly like fsx under memory pressure to be reliable again -
that will help all our testing of new changes; but I think it's more
urgent to get normal loads to be reliable again.

If you can call building on -t ext2 -b 1024 under memory pressure normal ;)

Hugh
--
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/