linux-ext4 - Re: [5.10.y] Regression in EXT3/4 with v5.10.227, LTP preadv03 is failing

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: <lrkyqldyhpeb5.fsf@dev-dsk-mngyadam-1c-a2602c62.eu-west-1.amazon.com>
Date: Mon, 21 Oct 2024 19:15:58 +0200
From: Mahmoud Adam <mngyadam@...zon.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: <jack@...e.cz>, <hch@....de>, <sashal@...nel.org>, <tytso@....edu>,
	<linux-ext4@...r.kernel.org>, <regressions@...ts.linux.dev>
Subject: Re: [5.10.y] Regression in EXT3/4 with v5.10.227, LTP preadv03 is
 failing

Greg KH <gregkh@...uxfoundation.org> writes:

> On Mon, Oct 21, 2024 at 05:43:54PM +0200, Mahmoud Adam wrote:
>> 
>> Hello,
>> 
>>   In the latest 5.10.227 we see LTP preadv03 failing on EXT3/4, when
>> bisected it was found that the commit dde4c1e1663b6 ("ext4: properly
>> sync file size update after O_SYNC direct IO") is causing it
>> 
>> This seems similar to what occurred before[1] and if I understand
>> correctly it was because of missing dependency backport 936e114a245b6
>> ("iomap: update ki_pos a little later in iomap_dio_complete") which was
>> then backported to 5.15 & 6.1 but not to 5.10.
>> 
>> *This is not failing on 5.15 nor 6.1, and it does fail consistently in x86-64 & ARM
>> 
>> [1]: https://lore.kernel.org/all/20231205122122.dfhhoaswsfscuhc3@quack3/
>> 
>
>
> What do you suggest be done?
>

I think as an urgent fix I would suggest reverting the mentioned commit
and commits that depend on it from 5.10.y..

4911610c7a1fe ("ext4: fix warning in ext4_dio_write_end_io()")
f8a7c342326f6 ("ext4: dax: fix overflowing extents beyond inode size when partially writing")
dde4c1e1663b6 ("ext4: properly sync file size update after O_SYNC direct
IO")

maybe someone from the ext4 side confirm that as well?

thanks,
MNAdam