On Wed, Sep 14, 2022 at 11:52:28 AM -0700, Darrick J. Wong wrote: > On Mon, Sep 12, 2022 at 06:57:24PM +0530, Chandan Babu R wrote: >> Hi Darrick, >> >> This 5.4.y backport series contains fixes from v5.5 release. >> >> This patchset has been tested by executing fstests (via kdevops) using >> the following XFS configurations, >> >> 1. No CRC (with 512 and 4k block size). >> 2. Reflink/Rmapbt (1k and 4k block size). >> 3. Reflink without Rmapbt. >> 4. External log device. >> >> The following lists patches which required other dependency patches to >> be included, >> >> 1. 050552cbe06a3a9c3f977dcf11ff998ae1d5c2d5 >> xfs: fix some memory leaks in log recovery >> - 895e196fb6f84402dcd0c1d3c3feb8a58049564e >> xfs: convert EIO to EFSCORRUPTED when log contents are invalid >> - 895e196fb6f84402dcd0c1d3c3feb8a58049564e >> xfs: constify the buffer pointer arguments to error functions >> - a5155b870d687de1a5f07e774b49b1e8ef0f6f50 >> xfs: always log corruption errors >> 2. 13eaec4b2adf2657b8167b67e27c97cc7314d923 >> xfs: don't commit sunit/swidth updates to disk if that would cause >> repair failures >> - 1cac233cfe71f21e069705a4930c18e48d897be6 >> xfs: refactor agfl length computation function >> - 4f5b1b3a8fa07dc8ecedfaf539b3deed8931a73e >> xfs: split the sunit parameter update into two parts > > For patches 1-2, 4, 7-14, 16-18, > Acked-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > I don't know why patches 3, 5-6, or 15 are necessary -- I don't think > they're fixing any user-visible issues; is that so that you can run QA > with CONFIG_XFS_DEBUG=y and avoid false failures due to bad asserts? > Similar to testing upstream kernel, I thought I had configured the 5.4 LTS kernel with CONFIG_XFS_DEBUG=y. But it turned out that I had not enabled the option. I had to re-test both the unpatched and patched kernel once again to make sure that there were no new regressions. Sorry about the delay in responding. I think I will drop patch 3. As stated by you, the remaining patches are required to prevent false failures. -- chandan
