On 5/30/24 11:00, Miklos Szeredi wrote:
> On Thu, 30 May 2024 at 05:20, Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote:
>
>>> + if (test_bit(FR_FINISHED, &req->flags)) {
>>> + list_del_init(&req->intr_entry);
>>> + spin_unlock(&fiq->lock ^
>> missing "return" here?
>
> Well spotted. Thanks.
>
>>> - err = -ENODEV;
>>> - spin_unlock(&fiq->lock);
>>> - fuse_put_request(req);
>>> - }
>>> + fuse_send_one(fiq, req);
>>>
>>> - return err;
>>> + return 0;
>>> }
>>
>> There's a minor changed behavior visible to users. Prior to the patch,
>> the FUSE_NOTIFY_RETRIEVE will returns -ENODEV when the connection is
>> aborted, but now it returns 0.
>>
>> It seems only example/notify_store_retrieve.c has used
>> FUSE_NOTIFY_RETRIEVE in libfuse. I'm not sure if this change really
>> matters.
>
> It will return -ENOTCONN from fuse_simple_notify_reply() ->
> fuse_get_req(). The -ENODEV would be a very short transient error
> during the abort, so it doesn't matter.
example/notify_store_retrieve and example/notify_inval_inode actually
get EBADF on umount. Issue is that FUSE_DESTROY is sent very late only,
but inodes already released. If server side sends a notification in the
wrong moment, it gets EBADF. We would need something like
FUSE_PREPARE_DESTROY that is being send when umount processing starts to
stop notifications. I'm not sure if that exists in the VFS and didn't
have time yet to check.
Thanks,
Bernd
