diff options
author | Chandan Babu R <chandanbabu@kernel.org> | 2023-09-13 07:55:00 +0300 |
---|---|---|
committer | Chandan Babu R <chandanbabu@kernel.org> | 2023-09-13 07:55:00 +0300 |
commit | fffcdcc31fa1e6374c4d6d2177b7089994fe13b8 (patch) | |
tree | a4c3b4f8095459ec34e541c04b61bb4318249b54 /fs/xfs/xfs_itable.c | |
parent | b6c2b6378d642ee5f46f60711473a7cc6d9cb1e8 (diff) | |
parent | 68b957f64fca1930164bfc6d6d379acdccd547d7 (diff) | |
download | linux-fffcdcc31fa1e6374c4d6d2177b7089994fe13b8.tar.xz |
Merge tag 'fix-iunlink-6.6_2023-09-12' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.6-fixesA
xfs: reload the last iunlink item
It turns out that there are some serious bugs in how xfs handles the
unlinked inode lists. Way back before 4.14, there was a bug where a ro
mount of a dirty filesystem would recover the log bug neglect to purge
the unlinked list. This leads to clean unmounted filesystems with
unlinked inodes. Starting around 5.15, we also converted the codebase
to maintain a doubly-linked incore unlinked list. However, we never
provided the ability to load the incore list from disk. If someone
tries to allocate an O_TMPFILE file on a clean fs with a pre-existing
unlinked list or even deletes a file, the code will fail and the fs
shuts down.
This first part of the correction effort adds the ability to load the
first inode in the bucket when unlinking a file; and to load the next
inode in the list when inactivating (freeing) an inode.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
* tag 'fix-iunlink-6.6_2023-09-12' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: load uncached unlinked inodes into memory on demand
Diffstat (limited to 'fs/xfs/xfs_itable.c')
0 files changed, 0 insertions, 0 deletions