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
