All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: virtio-fs-list <virtio-fs@redhat.com>, linux-fsdevel@vger.kernel.org
Subject: Re: [Virtio-fs] [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


WARNING: multiple messages have this Message-ID (diff)
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


  reply	other threads:[~2021-10-06 15:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 14:38 [Virtio-fs] [PATCH 0/8] virtiofs: Notification queue and blocking posix locks Vivek Goyal
2021-09-30 14:38 ` Vivek Goyal
2021-09-30 14:38 ` [Virtio-fs] [PATCH 1/8] virtiofs: Disable interrupt requests properly Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-09-30 14:38 ` [Virtio-fs] [PATCH 2/8] virtiofs: Fix a comment about fuse_dev allocation Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-09-30 14:38 ` [Virtio-fs] [PATCH 3/8] virtiofs: Add an index to keep track of first request queue Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-09-30 14:38 ` [Virtio-fs] [PATCH 4/8] virtiofs: Decouple queue index and queue type Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-09-30 14:38 ` [Virtio-fs] [PATCH 5/8] virtiofs: Add a virtqueue for notifications Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-10-06 12:46   ` [Virtio-fs] " Miklos Szeredi
2021-10-06 12:46     ` Miklos Szeredi
2021-10-06 12:54     ` [Virtio-fs] " Vivek Goyal
2021-10-06 12:54       ` Vivek Goyal
2021-09-30 14:38 ` [Virtio-fs] [PATCH 6/8] virtiofs: Add a helper to end request and decrement inflight number Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-09-30 14:38 ` [Virtio-fs] [PATCH 7/8] virtiofs: Add new notification type FUSE_NOTIFY_LOCK Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-10-06 12:55   ` [Virtio-fs] " Miklos Szeredi
2021-10-06 12:55     ` Miklos Szeredi
2021-10-06 15:01     ` Vivek Goyal [this message]
2021-10-06 15:01       ` Vivek Goyal
2021-10-06 13:02   ` [Virtio-fs] " Miklos Szeredi
2021-10-06 13:02     ` Miklos Szeredi
2021-10-06 16:12     ` [Virtio-fs] " Vivek Goyal
2021-10-06 16:12       ` Vivek Goyal
2021-10-07 13:45       ` [Virtio-fs] " Miklos Szeredi
2021-10-07 13:45         ` Miklos Szeredi
2021-10-07 14:21         ` [Virtio-fs] " Vivek Goyal
2021-10-07 14:21           ` Vivek Goyal
2021-10-07 18:11           ` [Virtio-fs] " Miklos Szeredi
2021-10-07 18:11             ` Miklos Szeredi
2021-10-07 18:32             ` [Virtio-fs] " Vivek Goyal
2021-10-07 18:32               ` Vivek Goyal
2021-10-07 18:46               ` [Virtio-fs] " Miklos Szeredi
2021-10-07 18:46                 ` Miklos Szeredi
2021-09-30 14:38 ` [Virtio-fs] [PATCH 8/8] virtiofs: Handle reordering of reply and notification event Vivek Goyal
2021-09-30 14:38   ` Vivek Goyal
2021-09-30 15:43 ` [Virtio-fs] [PATCH 0/8] virtiofs: Notification queue and blocking posix locks Vivek Goyal
2021-09-30 15:43   ` 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=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.