From: Miklos Szeredi <miklos@szeredi.hu>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux-fsdevel@vger.kernel.org,
virtio-fs-list <virtio-fs@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Ioannis Angelakopoulos <iangelak@redhat.com>,
jaggel@bu.edu, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 7/8] virtiofs: Add new notification type FUSE_NOTIFY_LOCK
Date: Wed, 6 Oct 2021 14:55:16 +0200 [thread overview]
Message-ID: <CAJfpegu5Y5X_CcKS9hsoW3ao5+WPJjm-6hsMVEiGU8PjSKy2gg@mail.gmail.com> (raw)
In-Reply-To: <20210930143850.1188628-8-vgoyal@redhat.com>
On Thu, 30 Sept 2021 at 16:39, Vivek Goyal <vgoyal@redhat.com> wrote:
>
> Add a new notification type FUSE_NOTIFY_LOCK. This notification can be
> sent by file server to signifiy that a previous locking request has
> completed and actual caller should be woken up.
>
> As of now we don't support blocking variant of posix locks and daemon
> returns -EOPNOTSUPP. Reason being that it can lead to deadlocks.
> Virtqueue size is limited and it is possible we fill virtqueue with
> all the requests of fcntl(F_SETLKW) and wait for reply. And later a
> subsequent unlock request can't make progress because virtqueue is full.
> And that means F_SETLKW can't make progress and we are deadlocked.
>
> This problem is not limited to posix locks only. I think blocking remote
> flock and open file description locks should face the same issue. Right
> now fuse does not support open file description locks, so its not
> a problem. But fuse/virtiofs does support remote flock and they can use
> same mechanism too.
>
> Use notification queue to solve this problem. After submitting lock
> request device will send a reply asking requester to wait. Once lock is
> available, requester will get a notification saying lock is available.
> That way we don't keep the request virtueue busy while we are waiting for
> lock and further unlock requests can make progress.
>
> When we get a reply in response to lock request, we need a way to know
> if we need to wait for notification or not. I have overloaded the
> fuse_out_header->error field. If value is ->error is 1, that's a signal
> to caller to wait for lock notification. Overloading ->error in this way
> is not the best way to do it. But I am running out of ideas.
Since all values besides -511..0 are reserved this seems okay.
However this needs to be a named value and added to uapi/linux/fuse.h.
next prev parent reply other threads:[~2021-10-06 12:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 14:38 [PATCH 0/8] virtiofs: Notification queue and blocking posix locks Vivek Goyal
2021-09-30 14:38 ` [PATCH 1/8] virtiofs: Disable interrupt requests properly Vivek Goyal
2021-09-30 14:38 ` [PATCH 2/8] virtiofs: Fix a comment about fuse_dev allocation Vivek Goyal
2021-09-30 14:38 ` [PATCH 3/8] virtiofs: Add an index to keep track of first request queue Vivek Goyal
2021-09-30 14:38 ` [PATCH 4/8] virtiofs: Decouple queue index and queue type Vivek Goyal
2021-09-30 14:38 ` [PATCH 5/8] virtiofs: Add a virtqueue for notifications Vivek Goyal
2021-10-06 12:46 ` Miklos Szeredi
2021-10-06 12:54 ` Vivek Goyal
2021-09-30 14:38 ` [PATCH 6/8] virtiofs: Add a helper to end request and decrement inflight number Vivek Goyal
2021-09-30 14:38 ` [PATCH 7/8] virtiofs: Add new notification type FUSE_NOTIFY_LOCK Vivek Goyal
2021-10-06 12:55 ` Miklos Szeredi [this message]
2021-10-06 15:01 ` Vivek Goyal
2021-10-06 13:02 ` Miklos Szeredi
2021-10-06 16:12 ` Vivek Goyal
2021-10-07 13:45 ` Miklos Szeredi
2021-10-07 14:21 ` Vivek Goyal
2021-10-07 18:11 ` Miklos Szeredi
2021-10-07 18:32 ` Vivek Goyal
2021-10-07 18:46 ` Miklos Szeredi
2021-09-30 14:38 ` [PATCH 8/8] virtiofs: Handle reordering of reply and notification event Vivek Goyal
2021-09-30 15:43 ` [PATCH 0/8] virtiofs: Notification queue and blocking posix locks Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJfpegu5Y5X_CcKS9hsoW3ao5+WPJjm-6hsMVEiGU8PjSKy2gg@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=dgilbert@redhat.com \
--cc=iangelak@redhat.com \
--cc=jaggel@bu.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=stefanha@redhat.com \
--cc=vgoyal@redhat.com \
--cc=virtio-fs@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).