On 2/21/24 4:47 PM, Dave Chinner wrote:
From: Dave Chinner <dchinner@xxxxxxxxxx> syzbot reported an ext4 panic during a page fault where found a journal handle when it didn't expect to find one. The structure it tripped over had a value of 'TRAN' in the first entry in the structure, and that indicates it tripped over a struct xfs_trans instead of a jbd2 handle. The reason for this is that the page fault was taken during a copy-out to a user buffer from an xfs bulkstat operation. XFS uses an "empty" transaction context for bulkstat to do automated metadata buffer cleanup, and so the transaction context is valid across the copyout of the bulkstat info into the user buffer. We are using empty transaction contexts like this in XFS in more places to reduce the risk of failing to release objects we reference during the operation, especially during error handling. Hence we really need to ensure that we can take page faults from these contexts without leaving landmines for the code processing the page fault to trip over. We really only use current->journal_info for a single warning check in xfs_vm_writepages() to ensure we aren't doing writeback from a transaction context. Writeback might need to do allocation, so it can need to run transactions itself. Hence it's a debug check to warn us that we've done something silly, and largely it is not all that useful. So let's just remove all the use of current->journal_info in XFS and get rid of all the potential issues from nested contexts where current->journal_info might get misused by another filesytsem context. Reported-by: syzbot+cdee56dbcdf0096ef605@xxxxxxxxxxxxxxxxxxxxxxxxx Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> ---
This will also address a problem seen by asyzkaller generated test where a multithreaded test consisting of XFS_IOC_BULKSTAT and buffered write can unnecessarily trigger the warning in xfs_vm_writepages(). I was thinking of conditionally removing the I_DONTCACHE in xfs_bulkstat_one_int() but cannot recreate the problem without cheating (forcing the race to happen abnormally).
Reviewed-by: Mark Tinguely <mark.tinguely@oracle,com>
