Re: [RESEND, PATCH v2] fuse: Don't drop NOTIFY_REPLY if we promised it

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

 



On Tue, Feb 19, 2019 at 10:42 AM Kirill Smelkov <kirr@xxxxxxxxxx> wrote:
>
> A successful call to NOTIFY_RETRIEVE by filesystem carries promise from
> the kernel to send back NOTIFY_REPLY message. However if the filesystem
> is not reading requests with fuse_conn->max_pages capacity,

That's a violation of the contract by the fuse server, not the kernel.

> fuse_dev_do_read might see that the "request is too large" and decide to
> "reply with an error and restart the read". "Reply with an error" has
> underlying assumption that there is a "requester thread" that is waiting
> for request completion, which is true for most requests, but is not true
> for NOTIFY_REPLY: NOTIFY_RETRIEVE handler completes with OK status right
> after it could successfully queue NOTIFY_REPLY message without waiting
> for NOTIFY_REPLY completion. This leads to situation when filesystem
> requested to retrieve inode data with NOTIFY_RETRIEVE, got err=OK for
> that notification request, but NOTIFY_REPLY is not coming back.
>
> More, since there is no "requester thread" to handle the error, the
> situation shows itself as /sys/fs/fuse/connections/X/waiting=1 _and_
> /dev/fuse read(s) queued. Which is misleading since NOTIFY_REPLY request
> was removed from pending queue and abandoned.

Now I don't understand how that would happen.   If the request is
abandoned, its refcount should go down to zero and the num_waiting
count decremented accordingly.

Thanks,
Miklos



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux