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: <2024102122-sustained-camcorder-32fa@gregkh>
Date: Mon, 21 Oct 2024 22:19:45 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Mahmoud Adam <mngyadam@...zon.com>
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

On Mon, Oct 21, 2024 at 07:15:58PM +0200, 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")

Great, can you submit a series of these reverted that you have tested to
fix the issue?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ