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: <20241022094032.h5fnoqcudkxjp3vu@quack3>
Date: Tue, 22 Oct 2024 11:40:32 +0200
From: Jan Kara <jack@...e.cz>
To: Mahmoud Adam <mngyadam@...zon.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, 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

On Mon 21-10-24 19:15:58, Mahmoud Adam wrote:
> 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")

Looks sensible to me. Another possibility would be to backport commit
936e114a245b6e3 ("iomap: update ki_pos a little later in
iomap_dio_complete") to 5.10-stable. We've done this for other stable
branches which had this issue and so far I didn't hear about any fallout
from that.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ