On 9/9/25 12:14, Miklos Szeredi wrote:
> On Tue, 9 Sept 2025 at 11:50, Jian Huang Li <ali@xxxxxxx> wrote:
>>
>> fuse: fix potential memory leak from fuse_uring_cancel
>>
>> If umount or fuse daemon quits at early stage, could happen all ring queues
>> have already stopped and later some FUSE_IO_URING_CMD_REGISTER commands get
>> canceled, that leaves ring entities in ent_in_userspace list and will not
>> be freed by fuse_uring_destruct.
>> Move such ring entities to ent_canceled list and ensure fuse_uring_destruct
>> frees these ring entities.
>
> Thank you for the report.
>
> Do you have a reproducer?
We run with 2 more patches to pin the memory. That pin slows down
startup a bit and then it becomes visible with xfstests generic/001. I
guess it could be artificially reproduced with the current code by
adding some delays into libfuse.
>
>> Fixes: b6236c8407cb ("fuse: {io-uring} Prevent mount point hang on
>> fuse-server termination")
>> Signed-off-by: Jian Huang Li <ali@xxxxxxx>
>> ---
>> fs/fuse/dev_uring.c | 13 +++++++++++--
>> fs/fuse/dev_uring_i.h | 6 ++++++
>> 2 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/fuse/dev_uring.c b/fs/fuse/dev_uring.c
>> index 249b210becb1..db35797853c1 100644
>> --- a/fs/fuse/dev_uring.c
>> +++ b/fs/fuse/dev_uring.c
>> @@ -203,6 +203,12 @@ void fuse_uring_destruct(struct fuse_conn *fc)
>> WARN_ON(!list_empty(&queue->ent_commit_queue));
>> WARN_ON(!list_empty(&queue->ent_in_userspace));
>>
>> + list_for_each_entry_safe(ent, next, &queue->ent_canceled,
>> + list) {
>> + list_del_init(&ent->list);
>> + kfree(ent);
>> + }
>
> Instead of introducing yet another list, we could do the same
> iterate/free on the ent_in_userspace list?
Yeah, would be possible, but probably hard to understand for someone
reading the code? At a minimum it would need a good comment.
Thanks,
Bernd
