All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ioannis Angelakopoulos <iangelak@redhat.com>
To: qemu-devel@nongnu.org, virtio-fs@redhat.com
Cc: iangelak@redhat.com, stefanha@redhat.com, dgilbert@redhat.com,
	vgoyal@redhat.com
Subject: [PATCH 0/6] virtiofsd: Support for remote blocking posix locks
Date: Wed, 16 Jun 2021 15:39:15 -0400	[thread overview]
Message-ID: <20210616193921.608720-1-iangelak@redhat.com> (raw)

Hi,

Here is the implementation for the remote blocking posix locks in
virtiofsd.

This patch series also addresses the issues that were not fixed in:
[Virtio-fs] [PATCH v2 0/5] [RFC] virtiofsd, vhost-user-fs: Add support
for notification queue
https://patchwork.kernel.org/project/qemu-devel/cover/20191204190836.31324-1-vgoyal@redhat.com/

The main issue was that the guest could not reboot when a thread of the
virtiofsd process was blocked, waiting to acquire a lock. The
introduction of a custom threadpool dedicated to servicing only locking
requests addresses the aforementioned issue.

Description:

Through the addition of a notification queue it is possible for a
guest now to block waiting for a remote lock held by another guest.

When the lock is available virtiofsd sends a notification to the guest
that unblocks the process/thread waiting for the lock in order to
acquire it.

This implementation also handles cases where the guest that is
waiting for a lock, hard-reboots through SYSRQ
(echo "b" > /proc/sysrq-trigger). Specifically, a custom threadpool
(posix theads) in virtiofsd is used to service the locking requests.
If one of the threads is blocked waiting for a lock and the guest
hard-reboots then virtiofsd sends a signal to the blocked thread waking 
it up so that it exits and then virtiofsd cleans up its state and
re-initializes.

Finally, the custom threadpool enables virtiofsd to concurrently service
other requests that are non-blocking or block for a limited time while
the custom threadpool services locking requests that might block. This is
especially useful in the case where the GThreadPool is not utilized.

Thanks,
Ioannis

Ioannis Angelakopoulos (2):
  virtiofsd: Thread state cleanup when blocking posix locks are used
  virtiofsd: Custom threadpool for remote blocking posix locks requests

Vivek Goyal (4):
  virtiofsd: Release file locks using F_UNLCK
  virtiofsd: Create a notification queue
  virtiofsd: Specify size of notification buffer using config space
  virtiofsd: Implement blocking posix locks

 hw/virtio/vhost-user-fs.c                  |  57 +-
 include/hw/virtio/vhost-user-fs.h          |   4 +-
 include/standard-headers/linux/fuse.h      |   8 +
 include/standard-headers/linux/virtio_fs.h |   5 +
 tools/virtiofsd/fuse_i.h                   |   2 +
 tools/virtiofsd/fuse_lowlevel.c            |  40 +-
 tools/virtiofsd/fuse_lowlevel.h            |  26 +
 tools/virtiofsd/fuse_virtio.c              | 626 +++++++++++++++++++--
 tools/virtiofsd/passthrough_ll.c           |  90 ++-
 9 files changed, 804 insertions(+), 54 deletions(-)

-- 
2.27.0



WARNING: multiple messages have this Message-ID (diff)
From: Ioannis Angelakopoulos <iangelak@redhat.com>
To: qemu-devel@nongnu.org, virtio-fs@redhat.com
Cc: vgoyal@redhat.com
Subject: [Virtio-fs] [PATCH 0/6] virtiofsd: Support for remote blocking posix locks
Date: Wed, 16 Jun 2021 15:39:15 -0400	[thread overview]
Message-ID: <20210616193921.608720-1-iangelak@redhat.com> (raw)

Hi,

Here is the implementation for the remote blocking posix locks in
virtiofsd.

This patch series also addresses the issues that were not fixed in:
[Virtio-fs] [PATCH v2 0/5] [RFC] virtiofsd, vhost-user-fs: Add support
for notification queue
https://patchwork.kernel.org/project/qemu-devel/cover/20191204190836.31324-1-vgoyal@redhat.com/

The main issue was that the guest could not reboot when a thread of the
virtiofsd process was blocked, waiting to acquire a lock. The
introduction of a custom threadpool dedicated to servicing only locking
requests addresses the aforementioned issue.

Description:

Through the addition of a notification queue it is possible for a
guest now to block waiting for a remote lock held by another guest.

When the lock is available virtiofsd sends a notification to the guest
that unblocks the process/thread waiting for the lock in order to
acquire it.

This implementation also handles cases where the guest that is
waiting for a lock, hard-reboots through SYSRQ
(echo "b" > /proc/sysrq-trigger). Specifically, a custom threadpool
(posix theads) in virtiofsd is used to service the locking requests.
If one of the threads is blocked waiting for a lock and the guest
hard-reboots then virtiofsd sends a signal to the blocked thread waking 
it up so that it exits and then virtiofsd cleans up its state and
re-initializes.

Finally, the custom threadpool enables virtiofsd to concurrently service
other requests that are non-blocking or block for a limited time while
the custom threadpool services locking requests that might block. This is
especially useful in the case where the GThreadPool is not utilized.

Thanks,
Ioannis

Ioannis Angelakopoulos (2):
  virtiofsd: Thread state cleanup when blocking posix locks are used
  virtiofsd: Custom threadpool for remote blocking posix locks requests

Vivek Goyal (4):
  virtiofsd: Release file locks using F_UNLCK
  virtiofsd: Create a notification queue
  virtiofsd: Specify size of notification buffer using config space
  virtiofsd: Implement blocking posix locks

 hw/virtio/vhost-user-fs.c                  |  57 +-
 include/hw/virtio/vhost-user-fs.h          |   4 +-
 include/standard-headers/linux/fuse.h      |   8 +
 include/standard-headers/linux/virtio_fs.h |   5 +
 tools/virtiofsd/fuse_i.h                   |   2 +
 tools/virtiofsd/fuse_lowlevel.c            |  40 +-
 tools/virtiofsd/fuse_lowlevel.h            |  26 +
 tools/virtiofsd/fuse_virtio.c              | 626 +++++++++++++++++++--
 tools/virtiofsd/passthrough_ll.c           |  90 ++-
 9 files changed, 804 insertions(+), 54 deletions(-)

-- 
2.27.0


             reply	other threads:[~2021-06-16 20:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 19:39 Ioannis Angelakopoulos [this message]
2021-06-16 19:39 ` [Virtio-fs] [PATCH 0/6] virtiofsd: Support for remote blocking posix locks Ioannis Angelakopoulos
2021-06-16 19:39 ` [PATCH 1/6] virtiofsd: Release file locks using F_UNLCK Ioannis Angelakopoulos
2021-06-16 19:39   ` [Virtio-fs] " Ioannis Angelakopoulos
2021-06-16 19:39 ` [PATCH 2/6] virtiofsd: Create a notification queue Ioannis Angelakopoulos
2021-06-16 19:39   ` [Virtio-fs] " Ioannis Angelakopoulos
2021-06-16 19:39 ` [PATCH 3/6] virtiofsd: Specify size of notification buffer using config space Ioannis Angelakopoulos
2021-06-16 19:39   ` [Virtio-fs] " Ioannis Angelakopoulos
2021-06-16 19:39 ` [PATCH 4/6] virtiofsd: Implement blocking posix locks Ioannis Angelakopoulos
2021-06-16 19:39   ` [Virtio-fs] " Ioannis Angelakopoulos
2021-06-16 19:39 ` [PATCH 5/6] virtiofsd: Thread state cleanup when blocking posix locks are used Ioannis Angelakopoulos
2021-06-16 19:39   ` [Virtio-fs] " Ioannis Angelakopoulos
2021-06-16 19:39 ` [PATCH 6/6] virtiofsd: Custom threadpool for remote blocking posix locks requests Ioannis Angelakopoulos
2021-06-16 19:39   ` [Virtio-fs] " Ioannis Angelakopoulos

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=20210616193921.608720-1-iangelak@redhat.com \
    --to=iangelak@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.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 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.