Re: [PATCH] fuse: move page cache invalidation after AIO to workqueue

[Jingbo Xu]

On 3/3/26 8:37 PM, Bernd Schubert wrote:
> 
> 
> On 3/3/26 13:03, Jingbo Xu wrote:
>>
>>
>> On 3/3/26 6:23 PM, Bernd Schubert wrote:
>>> From: Cheng Ding <cding@xxxxxxx>
>>>
>>> Invalidating the page cache in fuse_aio_complete() causes deadlock.
>>> Call Trace:
>>>  <TASK>
>>>  __schedule+0x27c/0x6b0
>>>  schedule+0x33/0x110
>>>  io_schedule+0x46/0x80
>>>  folio_wait_bit_common+0x136/0x330
>>>  __folio_lock+0x17/0x30
>>>  invalidate_inode_pages2_range+0x1d2/0x4f0
>>>  fuse_aio_complete+0x258/0x270 [fuse]
>>>  fuse_aio_complete_req+0x87/0xd0 [fuse]
>>>  fuse_request_end+0x18e/0x200 [fuse]
>>>  fuse_uring_req_end+0x87/0xd0 [fuse]
>>>  fuse_uring_cmd+0x241/0xf20 [fuse]
>>>  io_uring_cmd+0x9f/0x140
>>>  io_issue_sqe+0x193/0x410
>>>  io_submit_sqes+0x128/0x3e0
>>>  __do_sys_io_uring_enter+0x2ea/0x490
>>>  __x64_sys_io_uring_enter+0x22/0x40
>>>
>>> Move the invalidate_inode_pages2_range() call to a workqueue worker
>>> to avoid this issue. This approach is similar to
>>> iomap_dio_bio_end_io().
>>>
>>> (Minor edit by Bernd to avoid a merge conflict in Miklos' for-next
>>> branch). The commit is based on that branch with the addition of
>>> https://lore.kernel.org/r/20260111073701.6071-1-jefflexu@xxxxxxxxxxxxxxxxx)
>>
>> I think it would be better to completely drop my previous patch and
>> rework on the bare ground, as the patch
>> (https://lore.kernel.org/r/20260111073701.6071-1-jefflexu@xxxxxxxxxxxxxxxxx)
>> is only in Miklos's branch, not merged to the master yet.
>>
>>
>> After reverting my previous patch, I think it would be cleaner by:
>>
>>
>> "The page cache invalidation for FOPEN_DIRECT_IO write in
>> fuse_direct_io() is moved to fuse_direct_write_iter() (with any progress
>> in write), to keep consistent with generic_file_direct_write().  This
>> covers the scenarios of both synchronous FOPEN_DIRECT_IO write
>> (regardless FUSE_ASYNC_DIO) and asynchronous FOPEN_DIRECT_IO write
>> without FUSE_ASYNC_DIO.
>>
>> After that, only asynchronous direct write (for both FOPEN_DIRECT_IO and
>> non-FOPEN_DIRECT_IO) with FUSE_ASYNC_DIO is left."
> 
> I think your suggestion moves into this direction
> 
> https://lore.kernel.org/all/20230918150313.3845114-1-bschubert@xxxxxxx/
> 

Yes it's similar in some way, but it's still simple enough as the short
term fix.

-- 
Thanks,
Jingbo