On Thu, Jun 2, 2022 at 8:55 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Thu, Jun 2, 2022 at 8:15 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > On Thu, Jun 02, 2022 at 07:24:26AM +0300, Amir Goldstein wrote: > > > On Thu, Jun 2, 2022 at 3:38 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > > > > > On Wed, Jun 01, 2022 at 01:45:46PM +0300, Amir Goldstein wrote: > > > > > From: Brian Foster <bfoster@xxxxxxxxxx> > > > > > > > > > > commit 1cd738b13ae9b29e03d6149f0246c61f76e81fcf upstream. > > > > > > > > > > The assert in xfs_btree_del_cursor() checks that the bmapbt block > > > > > allocation field has been handled correctly before the cursor is > > > > > freed. This field is used for accurate calculation of indirect block > > > > > reservation requirements (for delayed allocations), for example. > > > > > generic/019 reproduces a scenario where this assert fails because > > > > > the filesystem has shutdown while in the middle of a bmbt record > > > > > insertion. This occurs after a bmbt block has been allocated via the > > > > > cursor but before the higher level bmap function (i.e. > > > > > xfs_bmap_add_extent_hole_real()) completes and resets the field. > > > > > > > > > > Update the assert to accommodate the transient state if the > > > > > filesystem has shutdown. While here, clean up the indentation and > > > > > comments in the function. > > > > > > > > > > Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx> > > > > > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > > > > --- > > > > > fs/xfs/libxfs/xfs_btree.c | 33 ++++++++++++--------------------- > > > > > 1 file changed, 12 insertions(+), 21 deletions(-) > > > > > > > > https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/?h=for-next&id=56486f307100e8fc66efa2ebd8a71941fa10bf6f > > > > > > > > > > Warm from the over :) > > > > > > I will need more time to verify that this new fix is not breaking LTS > > > but I don't think that it should be blocking taking the old 5.12 fix now. > > > Right? > > > > Rule #1: don't introduce new bugs into stable kernels. > > > > This commit has a known (and fixed) bug in it. If you are going to > > back port it to a stable kernel, then you need to also pull in the > > fix for that commit, too. > > Oh. I misunderstood. > I thought this wasn't a Fixes: situation. > I thought you pointed me to another related bug fix. > Just to make sure we are all on the same page. I have applied both patches to my test tree: 1. 1cd738b13ae9 xfs: consider shutdown in bmapbt cursor delete assert 2. 56486f307100 xfs: assert in xfs_btree_del_cursor should take into account error Patch #2 looks pretty safe and it only affects builds with XFS_WARN/DEBUG, so I am not too concerned about a soaking period. I plan to send it along with patch #1 to stable after a few more test runs. If my understanding is correct, the ASSERT has been there since git epoc. The too strict ASSERT was relaxed two times by patch #1 and then by patch #2. Maybe I am missing something, but I do not see how applying patch #1 introduces a bug, but anyway, I am going to send both patches together. Thanks, Amir.
