Re: [PATCH 0/2] fuse: Fix possible memleak at startup with immediate teardown

[Bernd Schubert <bernd@bsbernd.com>]

On 4/10/26 19:28, Joanne Koong wrote:
> On Fri, Apr 10, 2026 at 10:18 AM Bernd Schubert <bernd@bsbernd.com> wrote:
>>
>>
>>
>> On 4/10/26 19:09, Joanne Koong wrote:
>>> On Fri, Apr 10, 2026 at 12:21 AM Horst Birthelmer <horst@birthelmer.de> wrote:
>>>>
>>>> On Thu, Apr 09, 2026 at 04:09:53PM -0700, Joanne Koong wrote:
>>>>> On Thu, Apr 9, 2026 at 4:02 AM Bernd Schubert <bernd@bsbernd.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/21/25 23:33, Bernd Schubert wrote:
>>>>>>> Do not merge yet, the current series has not been tested yet.
>>>>>>
>>>>>> I'm glad that that I was hesitating to apply it, the DDN branch had it
>>>>>> for ages and this patch actually introduced a possible fc->num_waiting
>>>>>> issue, because fc->uring->queue_refs might go down to 0 though
>>>>>> fuse_uring_cancel() and then fuse_uring_abort() would never stop and
>>>>>> flush the queues without another addition.
>>>>>>
>>>>>
>>>>> Hi Bernd and Jian,
>>>>>
>>>>> For some reason the "[PATCH 2/2] fs/fuse: fix potential memory leak
>>>>> from fuse_uring_cancel" email was never delivered to my inbox, so I am
>>>>> just going to write my reply to that patch here instead, hope that's
>>>>> ok.
>>>>>
>>>>> Just to summarize, the race is that during unmount, fuse_abort() ->
>>>>> fuse_uring_abort() -> ... -> fuse_uring_teardown_entries() -> ... ->
>>>>> fuse_uring_entry_teardown() gets run but there may still be sqes that
>>>>> are being registered, which results in new ents that are created (and
>>>>> leaked) after the teardown logic has finished and the queues are
>>>>> stopped/dead. The async teardown work (fuse_uring_async_stop_queues())
>>>>> never gets scheduled because at the time of teardown, queue->refs is 0
>>>>> as those sqes have not fully created the ents and grabbed refs yet.
>>>>> fuse_uring_destruct() runs during unmount, but this doesn't clean up
>>>>> the created ents because those registered ents got put on the
>>>>> ent_in_userspace list which fuse_uring_destruct() doesn't go through
>>>>> to free, resulting in those ents being leaked.
>>>>>
>>>>> The root cause of the race is that ents are being registered even when
>>>>> the queue is already stopped/dead. I think if we at registration time
>>>>> check the queue state before calling fuse_uring_prepare_cancel(), we
>>>>> eliminate the race altogether. If we see that the abort path has
>>>>> already triggered (eg queue->stopped == true), we manually free the
>>>>> ent and return an error instead of adding it to a list, eg
>>>>
>>>> In my case (Bernd mentioned that I was investigating a hang during umount)
>>>> there were a lot of requests created during teardown, so what happened
>>>> was very similar, but for exact the opposite reason.
>>>> In fuse_uring_abort() queue_refs was already 0 due to an optimization
>>>> where the ring teardown ran before fuse_abort_conn().
>>>
>>> Hi Horst,
>>>
>>> Just to clarify, is this with running locally patched changes on your
>>> ddn kernel? In the upstream code I'm seeing that teardown is only
>>> called by the abort path, eg fuse_abort_conn() -> fuse_uring_abort()
>>> -> fuse_uring_stop_queues() -> teardown logic, so I'm not seeing how
>>> it's possible for teardown to run before fuse_abort_conn(). Is there
>>> something I'm missing?
>>
>> See my mail please it explains the history and shows the patch I had
>> posted to the list and which is not applied yet. The DDN branches have
>> it applied.
> 
> Hi Bernd,
> 
> Can you link to which mail you are referring to? Which patch are you
> talking about?

The mail I had sent earlier today, a few hours after Horsts. Somehow I
have the bad feeling that half of my mails are going into a spam folder.
I hope you get this one.

Here is the link to the message-id
https://lore.kernel.org/all/3eabbc7b-010f-4d4c-9145-30d69fe1aa79@bsbernd.com/


Thanks,
Bernd