From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
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 11:01:03 -0400 [thread overview]
Message-ID: <YV26L03HvAfMd/VC@redhat.com> (raw)
In-Reply-To: <CAJfpegu5Y5X_CcKS9hsoW3ao5+WPJjm-6hsMVEiGU8PjSKy2gg@mail.gmail.com>
On Wed, Oct 06, 2021 at 02:55:16PM +0200, Miklos Szeredi wrote:
> 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.
Ok, I will define this value and put in uapi/linux/fuse.h.
Thanks
Vivek
next prev parent reply other threads:[~2021-10-06 15:01 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
2021-10-06 15:01 ` Vivek Goyal [this message]
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=YV26L03HvAfMd/VC@redhat.com \
--to=vgoyal@redhat.com \
--cc=dgilbert@redhat.com \
--cc=iangelak@redhat.com \
--cc=jaggel@bu.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stefanha@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).