wireguard-linux/fs/xfs/xfs_error.c, branch jd/unified-crypt-queue

xfs: xfs_buf_corruption_error should take __this_address

2020-03-12T14:58:12Z

Add a xfs_failaddr_t parameter to this function so that callers can potentially pass in (and therefore report) the exact point in the code where we decided that a metadata buffer was corrupt. This enables us to wire it up to checking functions that have to run outside of verifiers. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner

xfs: add a function to deal with corrupt buffers post-verifiers

2020-03-12T14:58:12Z

Add a helper function to get rid of buffers that we have decided are corrupt after the verifiers have run. This function is intended to handle metadata checks that can't happen in the verifiers, such as inter-block relationship checking. Note that we now mark the buffer stale so that it will not end up on any LRU and will be purged on release. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner

xfs: report corruption only as a regular error

2019-11-18T16:40:44Z

Redefine XFS_IS_CORRUPT so that it reports corruptions only via xfs_corruption_report. Since these are on-disk contents (and not checks of internal state), we don't ever want to panic the kernel. This also amends the corruption report to recommend unmounting and running xfs_repair. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig

xfs: use super s_id instead of struct xfs_mount m_fsname

2019-11-05T16:28:25Z

Eliminate struct xfs_mount field m_fsname by using the super block s_id field directly. Signed-off-by: Ian Kent Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong

xfs: always log corruption errors

2019-11-04T21:55:54Z

Make sure we log something to dmesg whenever we return -EFSCORRUPTED up the call stack. Signed-off-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig

xfs: constify the buffer pointer arguments to error functions

2019-11-04T21:55:34Z

Some of the xfs error message functions take a pointer to a buffer that will be dumped to the system log. The logging functions don't change the contents, so constify all the parameters. This enables the next patch to ensure that we log bad metadata when we encounter it. Signed-off-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig

fs: xfs: Remove KM_NOSLEEP and KM_SLEEP.

2019-08-26T19:06:22Z

Since no caller is using KM_NOSLEEP and no callee branches on KM_SLEEP, we can remove KM_NOSLEEP and replace KM_SLEEP with 0. Signed-off-by: Tetsuo Handa Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong

xfs: add struct xfs_mount pointer to struct xfs_buf

2019-06-29T02:27:29Z

We need to derive the mount pointer from a buffer in a lot of place. Add a direct pointer to short cut the pointer chasing. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong

xfs: move xfs_ino_geometry to xfs_shared.h

2019-06-29T02:25:35Z

The inode geometry structure isn't related to ondisk format; it's support for the mount structure. Move it to xfs_shared.h. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Christoph Hellwig

xfs: cache unlinked pointers in an rhashtable

2019-02-12T00:07:01Z

Use a rhashtable to cache the unlinked list incore. This should speed up unlinked processing considerably when there are a lot of inodes on the unlinked list because iunlink_remove no longer has to traverse an entire bucket list to find which inode points to the one being removed. The incore list structure records "X.next_unlinked = Y" relations, with the rhashtable using Y to index the records. This makes finding the inode X that points to a inode Y very quick. If our cache fails to find anything we can always fall back on the old method. FWIW this drastically reduces the amount of time it takes to remove inodes from the unlinked list. I wrote a program to open a lot of O_TMPFILE files and then close them in the same order, which takes a very long time if we have to traverse the unlinked lists. With the ptach, I see: + /d/t/tmpfile/tmpfile Opened 193531 files in 6.33s. Closed 193531 files in 5.86s real 0m12.192s user 0m0.064s sys 0m11.619s + cd / + umount /mnt real 0m0.050s user 0m0.004s sys 0m0.030s And without the patch: + /d/t/tmpfile/tmpfile Opened 193588 files in 6.35s. Closed 193588 files in 751.61s real 12m38.853s user 0m0.084s sys 12m34.470s + cd / + umount /mnt real 0m0.086s user 0m0.000s sys 0m0.060s Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster