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
next 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: linkBe 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.