Commit ae21c8b3 authored by Long Li's avatar Long Li
Browse files

xfs: shutdown to ensure submits buffers on LSN boundaries

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


CVE: NA

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

While performing the io fault injection test, I caught the following data
corruption report:

 XFS (dm-0): Internal error ltbno + ltlen > bno at line 1957 of file fs/xfs/libxfs/xfs_alloc.c.  Caller xfs_free_ag_extent+0x79c/0x1130
 CPU: 3 PID: 33 Comm: kworker/3:0 Not tainted 6.5.0-rc7-next-20230825-00001-g7f8666926889 #214
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
 Workqueue: xfs-inodegc/dm-0 xfs_inodegc_worker
 Call Trace:
  <TASK>
  dump_stack_lvl+0x50/0x70
  xfs_corruption_error+0x134/0x150
  xfs_free_ag_extent+0x7d3/0x1130
  __xfs_free_extent+0x201/0x3c0
  xfs_trans_free_extent+0x29b/0xa10
  xfs_extent_free_finish_item+0x2a/0xb0
  xfs_defer_finish_noroll+0x8d1/0x1b40
  xfs_defer_finish+0x21/0x200
  xfs_itruncate_extents_flags+0x1cb/0x650
  xfs_free_eofblocks+0x18f/0x250
  xfs_inactive+0x485/0x570
  xfs_inodegc_worker+0x207/0x530
  process_scheduled_works+0x24a/0xe10
  worker_thread+0x5ac/0xc60
  kthread+0x2cd/0x3c0
  ret_from_fork+0x4a/0x80
  ret_from_fork_asm+0x11/0x20
  </TASK>
 XFS (dm-0): Corruption detected. Unmount and run xfs_repair

After analyzing the disk image, it was found that the corruption was
triggered by the fact that extent was recorded in both the inode and AGF
btrees. After a long time of reproduction and analysis, we found that the
root cause of the problem was that the AGF btree block was not recovered.

Consider the following scenario, Transaction A and Transaction B are in
the same record, so Transaction A and Transaction B share the same LSN1.
If the buf item in Transaction A has been recovered, then the buf item in
Transaction B cannot be recovered, because log recovery skips items with a
metadata LSN >= the current LSN of the recovery item. If there is still an
inode item in transaction B that records the Extent X, the Extent X will
be recorded in both the inode and the AGF btree block after transaction B
is recovered.

  |------------Record (LSN1)------------------|---Record (LSN2)---|
  |----------Trans A------------|-------------Trans B-------------|
  |     Buf Item(Extent X)      | Buf Item / Inode item(Extent X) |
  |     Extent X is freed       |     Extent X is allocated       |

After commit 12818d24 ("xfs: rework log recovery to submit buffers on
LSN boundaries") was introduced, during log recovery we submits buffers on
lsn boundaries. The above problem can be avoided under normal paths, but
is not guaranteed under abnormal paths. Consider the following process, if
an error is encountered after recover buf item in transaction A and before
recover buf item in transaction B, buffers that have been added to
buffer_list will still be submitted, this violates the submits rule on lsn
boundaries. So buf item in Transaction B cannot be recovered on the next
mount due to current lsn equal to metadata lsn.

  xlog_do_recovery_pass
    xlog_recover_process
      xlog_recover_process_data
        ...
          xlog_recover_buf_commit_pass2
            xlog_recover_do_reg_buffer  //recover buf item in Trans A
            xfs_buf_delwri_queue(bp, buffer_list)
        ...
        ====> Encountered error and returned
        ...
          xlog_recover_buf_commit_pass2
            xlog_recover_do_reg_buffer  //recover buf item in Trans B
            xfs_buf_delwri_queue(bp, buffer_list)
    if (!list_empty(&buffer_list))
      xfs_buf_delwri_submit(&buffer_list); //submit regardless of error

In order to make sure that submits buffers on lsn boundaries in the
abnormal paths, we need to check error status before submit buffers that
have been added from the last record processed.

Signed-off-by: default avatarLong Li <leo.lilong@huawei.com>
parent 77a884b5
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment