linux-ext4 - 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]

Message-ID: <CAGBYx2YA3B5-nLxwdHavmd=794ycrpqnMbvM=VabrdPL2FQ0sw@mail.gmail.com>
Date:	Tue, 6 Dec 2011 17:32:05 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Allison Henderson <achender@...ux.vnet.ibm.com>,
	"Ted Ts'o" <tytso@....edu>, Curt Wohlgemuth <curtw@...gle.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, Dec 6, 2011 at 4:55 PM, Hugh Dickins <hughd@...gle.com> wrote:
> On Mon, 5 Dec 2011, Allison Henderson wrote:
>> On 12/05/2011 04:38 PM, Hugh Dickins wrote:
>> >
>> > This has been outstanding for a month now, and we've heard no progress:
>> > please revert commit 02fac1297eb3 "ext4: fix partial page writes" for rc5.
>> >
>> > The problems appear on a 1k-blocksize filesystem under memory pressure:
>> > the hunk in ext4_da_write_end() causes oops, because it's playing with
>> > a page after generic_write_end() dropped our last reference to it; and
>> > backing out the hunk in ext4_da_write_begin() is then found to stop
>> > rare data corruption seen when kbuilding.
>> >
>> > Although I earlier reported that backing out the patch caused an fsx
>> > test to fail earlier, I've since found great variation in how soon it
>> > fails, and seen it fail just as quickly with 02fac1297eb3 still in.
>> > I also reported that I had to go back to 2.6.38 for fsx not to fail
>> > under memory pressure: you won't be surprised that that turned out to
>> > be because 2.6.38 defaults nomblk_io_submit but 2.6.39 mblk_io_submit.
>>
>> 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.
ext2?  So files are indirect mapped?  If so, the failure should has
nothing to do with punching hole, I remember that punch hole is not
supported for indirect mapped files.

Do you mean fsx failure or the bug you reported earlier due to
referencing a unlocked page?

Yongqiang.
>
> 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.
>
> Hugh



-- 
Best Wishes
Yongqiang Yang
--
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