summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_file.c
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2018-04-18 08:25:21 -0700
committerDarrick J. Wong <darrick.wong@oracle.com>2018-05-09 10:04:00 -0700
commitb027d4c97b9675c2ad75dec94be4e46dceb3ec74 (patch)
tree4f028dec9732af9663d53ac89841af52a9f2778f /fs/xfs/xfs_file.c
parent8925a3dc4771004b3e697e7159fa87be2aa5dd43 (diff)
downloadtalos-obmc-linux-b027d4c97b9675c2ad75dec94be4e46dceb3ec74.tar.gz
talos-obmc-linux-b027d4c97b9675c2ad75dec94be4e46dceb3ec74.zip
xfs: don't retry xfs_buf_find on XBF_TRYLOCK failure
When looking at an event trace recently, I noticed that non-blocking buffer lookup attempts would fail on cached locked buffers and then run the slow cache-miss path. This means we are doing an xfs_buf allocation, lookup and free unnecessarily every time we avoid blocking on a locked buffer. Fix this by changing _xfs_buf_find() to return an error status to the caller to indicate that we failed the lock attempt rather than just returning a NULL. This allows the higher level code to discriminate between a cache miss and an cache hit that we failed to lock. This also allows us to return a -EFSCORRUPTED state if we are asked to look up a block number outside the range of the filesystem in _xfs_buf_find(), which moves us one step closer to being able to handle such errors in a more graceful manner at the higher levels. Signed-Off-By: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Diffstat (limited to 'fs/xfs/xfs_file.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud