Re: [PATCH] fuse: mark DAX inode releases as blocking

[Jingbo Xu <jefflexu@linux.alibaba.com>]

On 1/27/26 7:18 PM, Sergio Lopez Pascual wrote:
> Jingbo Xu <jefflexu@linux.alibaba.com> writes:
> 
>> On 1/27/26 2:40 AM, Darrick J. Wong wrote:
>>
>>> I wonder if fuse ought to grow the ability to whine when something is
>>> trying to issue a synchronous fuse command while running in a command
>>> queue completion context (aka the worker threads) but I don't know how
>>> difficult that would *really* be.
>>
>> I had also observed similar issue where the FUSE daemon thread is
>> hanging in:
>>
>> request_wait_answer
>> fuse_simple_request
>> fuse_flush_times
>> fuse write_inode
>> writeback_single_inode
>> write_inode_now
>> fuse_release
>> _fput
>>
>> At that time I had no idea how FUSE daemon thread could trigger fuse
>> file release and thus I didn't dive into this further...
>>
>> I think commit 26e5c67deb2e ("fuse: fix livelock in synchronous file put
>> from fuseblk workers") is not adequate in this case, as the commit only
>> makes FUSE_RELEASE request asynchronously, while in this case the daemon
>> thread can wait for FUSE_WRITE and FUSE_SETATTR.
>>
>> Maybe the very first entry i.e. fuse_release() needs to be executed in
>> an asynchronous context (e.g. workqueue)...
> 
> Do you have the rest of the stacktrace? We need to know if it's running
> in the context of the worker thread, as otherwise it must be a different
> problem.


This is observed in scenarios of FUSE rather than virtiofs.

The complete stacktrace of FUSE daemon worker thread (in userspace) is like:

 request_wait_answer
 fuse_simple_request
 fuse_flush_times
 fuse write_inode
 writeback_single_inode
 write_inode_now
 fuse_release
 __fput
 ____fput
 task_work_run
 exit_to_user_mode_prepare
 syscall exit_to_user_mode
 do_syscall_64
 entry_SYSCALL_64_after_hwframe



-- 
Thanks,
Jingbo