Re: [PATCH 1/2] fuse: Clear FR_PENDING in request_wait_answer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3/19/25 22:15, Joanne Koong wrote:
> On Wed, Mar 19, 2025 at 5:37 AM Bernd Schubert <bschubert@xxxxxxx> wrote:
>>
>> The request is removed from the list of pending requests,
>> directly after follows a __fuse_put_request() which is
>> likely going to destruct the request, but that is not
>> guaranteed, better if FR_PENDING gets cleared.
> 
> I think it is guaranteed that the request will be freed. there's only
> one call path for request_wait_answer():
> __fuse_simple_request()
>     fuse_get_req() -> request is allocated (req refcount is 1)
>     __fuse_request_send()
>         __fuse_get_request() -> req refcount is 2
>         fuse_send_one()
>         request_wait_answer()
>    fuse_put_request() -> req refcount is dropped
> 
> if we hit that "if (test_bit(FR_PENDING, &req->flags))" case and
> request_wait_answer() drops the ref, then the request will be freed
> (or else it's leaked). imo we don't need this patch.
> 

I thought I had seen a path that was holding the request, but now I see
that every __fuse_get_request() actually also moves the request to
another list. I'm going to add a comments into the next patch explaining
why FR_PENDING is not cleared.


Thanks,
Bernd




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux