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