Commit 12a5c9f8 authored by yangerkun's avatar yangerkun Committed by Long Li
Browse files

xfs: fix xfs shutdown since we reserve more blocks in agfl fixup

hulk inclusion
category: bugfix
bugzilla: 188788, https://gitee.com/openeuler/kernel/issues/I76JSK
CVE: NA

--------------------------------

Twice fixup for the same ag may happen within exact one tp, and the
consume of agfl after first fixup may trigger failure of second fixup,
which is a unintended behavior and then xfs shutdown[1][2].

Gao Xiang describe one solution that we can reserve more blocks when first
fixup, but there is some logical error:

- we may first see postallocs as 1 and second as 0, this can trigger
  pointless agfl filling or shortening
- upper case(postallocs first equals to 1, second equals to 0) give us
  examples that we need shorten the agfl, but xfs_alloc_fix_freelist can
  only free agfl after success freespace check. Besides, the filling or
  shortening of agfl won't change fdblocks, so we can fall into that we
  can see fdblocks(or resblocks) but ag fixup will reject us, and then
  xfs can shutdown too
- once postallocs equals to 1, it can also change the logical of
  xfs_alloc_ag_max_usable, which will change the block allocation
  logical(found this problem by check each ag's freeblocks after
  we fallocate a huge file)
- once postallocs equals to 1, we reserve 2 * xfs_alloc_min_freelist(),
  but sometimes it seems not enough once bnt/cnt grow and the second fixup
  need more reserve...

This patch fix all bug above by using m_ag_maxlevels to reserve more
blocks, and adapt xfs_alloc_set_aside/xfs_alloc_ag_max_usable to match
this more reserve. Besides, we just reserve more, won't fill or shorten
agfl according to that reserve.

[1] https://www.spinics.net/lists/linux-xfs/msg66440.html
[2] https://lore.kernel.org/linux-xfs/20221228133204.4021519-1-guoxuenan@huawei.com/



Fixes: 53f85096 ("xfs: account extra freespace btree splits for multiple allocations")
Signed-off-by: default avataryangerkun <yangerkun@huawei.com>
Signed-off-by: default avatarLong Li <leo.lilong@huawei.com>
parent cb560841
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment