From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-fs@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Virtio-fs] [PATCH 3/5] virtiofsd: make lo_release() atomic
Date: Wed, 31 Jul 2019 17:56:33 +0100 [thread overview]
Message-ID: <20190731165633.GJ3203@work-vm> (raw)
In-Reply-To: <20190726091103.23503-4-stefanha@redhat.com>
* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> Hold the lock across both lo_map_get() and lo_map_remove() to prevent
> races between two FUSE_RELEASE requests. In this case I don't see a
> serious bug but it's safer to do things atomically.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
OK, although I suspect there are lots of places the inode pointers
are passed without the lock, so it might not help much.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
and applied
> ---
> contrib/virtiofsd/passthrough_ll.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/virtiofsd/passthrough_ll.c b/contrib/virtiofsd/passthrough_ll.c
> index 277a17fc03..c1500e092d 100644
> --- a/contrib/virtiofsd/passthrough_ll.c
> +++ b/contrib/virtiofsd/passthrough_ll.c
> @@ -1759,14 +1759,18 @@ static void lo_open(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi)
> static void lo_release(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi)
> {
> struct lo_data *lo = lo_data(req);
> - int fd;
> + struct lo_map_elem *elem;
> + int fd = -1;
>
> (void) ino;
>
> - fd = lo_fi_fd(req, fi);
> -
> pthread_mutex_lock(&lo->mutex);
> - lo_map_remove(&lo->fd_map, fi->fh);
> + elem = lo_map_get(&lo->fd_map, fi->fh);
> + if (elem) {
> + fd = elem->fd;
> + elem = NULL;
> + lo_map_remove(&lo->fd_map, fi->fh);
> + }
> pthread_mutex_unlock(&lo->mutex);
>
> close(fd);
> --
> 2.21.0
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-fs@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/5] virtiofsd: make lo_release() atomic
Date: Wed, 31 Jul 2019 17:56:33 +0100 [thread overview]
Message-ID: <20190731165633.GJ3203@work-vm> (raw)
In-Reply-To: <20190726091103.23503-4-stefanha@redhat.com>
* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> Hold the lock across both lo_map_get() and lo_map_remove() to prevent
> races between two FUSE_RELEASE requests. In this case I don't see a
> serious bug but it's safer to do things atomically.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
OK, although I suspect there are lots of places the inode pointers
are passed without the lock, so it might not help much.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
and applied
> ---
> contrib/virtiofsd/passthrough_ll.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/virtiofsd/passthrough_ll.c b/contrib/virtiofsd/passthrough_ll.c
> index 277a17fc03..c1500e092d 100644
> --- a/contrib/virtiofsd/passthrough_ll.c
> +++ b/contrib/virtiofsd/passthrough_ll.c
> @@ -1759,14 +1759,18 @@ static void lo_open(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi)
> static void lo_release(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi)
> {
> struct lo_data *lo = lo_data(req);
> - int fd;
> + struct lo_map_elem *elem;
> + int fd = -1;
>
> (void) ino;
>
> - fd = lo_fi_fd(req, fi);
> -
> pthread_mutex_lock(&lo->mutex);
> - lo_map_remove(&lo->fd_map, fi->fh);
> + elem = lo_map_get(&lo->fd_map, fi->fh);
> + if (elem) {
> + fd = elem->fd;
> + elem = NULL;
> + lo_map_remove(&lo->fd_map, fi->fh);
> + }
> pthread_mutex_unlock(&lo->mutex);
>
> close(fd);
> --
> 2.21.0
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-07-31 16:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 9:10 [Virtio-fs] [PATCH 0/5] virtiofsd: multithreading preparation Stefan Hajnoczi
2019-07-26 9:10 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-26 9:10 ` [Virtio-fs] [PATCH 1/5] virtiofsd: skip unnecessary vu_queue_get_avail_bytes() Stefan Hajnoczi
2019-07-26 9:10 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-26 21:35 ` [Virtio-fs] " Liu Bo
2019-07-26 21:35 ` [Qemu-devel] " Liu Bo
2019-07-31 16:50 ` Dr. David Alan Gilbert
2019-07-31 16:50 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-07-26 9:11 ` [Virtio-fs] [PATCH 2/5] virtiofsd: prevent lo_lookup() NULL pointer dereference Stefan Hajnoczi
2019-07-26 9:11 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-26 21:26 ` [Virtio-fs] " Liu Bo
2019-07-26 21:26 ` [Qemu-devel] " Liu Bo
2019-07-29 8:15 ` Stefan Hajnoczi
2019-07-29 8:15 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-28 2:06 ` piaojun
2019-07-29 12:35 ` piaojun
2019-07-29 15:41 ` [Virtio-fs] [Qemu-devel] " Stefan Hajnoczi
2019-07-29 15:41 ` [Qemu-devel] [Virtio-fs] " Stefan Hajnoczi
2019-07-30 0:34 ` piaojun
2019-07-26 9:11 ` [Virtio-fs] [PATCH 3/5] virtiofsd: make lo_release() atomic Stefan Hajnoczi
2019-07-26 9:11 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-31 16:56 ` Dr. David Alan Gilbert [this message]
2019-07-31 16:56 ` Dr. David Alan Gilbert
2019-07-26 9:11 ` [Virtio-fs] [PATCH 4/5] virtiofsd: drop lo_dirp->fd field Stefan Hajnoczi
2019-07-26 9:11 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-31 17:27 ` [Virtio-fs] " Dr. David Alan Gilbert
2019-07-31 17:27 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-01 9:07 ` [Virtio-fs] " Stefan Hajnoczi
2019-08-01 9:07 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-26 9:11 ` [Virtio-fs] [PATCH 5/5] virtiofsd: prevent races with lo_dirp_put() Stefan Hajnoczi
2019-07-26 9:11 ` [Qemu-devel] " Stefan Hajnoczi
2019-07-31 17:44 ` [Virtio-fs] " Dr. David Alan Gilbert
2019-07-31 17:44 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-01 9:15 ` [Virtio-fs] " Stefan Hajnoczi
2019-08-01 9:15 ` [Qemu-devel] " Stefan Hajnoczi
2019-08-01 11:14 ` [Virtio-fs] " Dr. David Alan Gilbert
2019-08-01 11:14 ` [Qemu-devel] " Dr. David Alan Gilbert
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=20190731165633.GJ3203@work-vm \
--to=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--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 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.