From: Vivek Goyal <vgoyal@redhat.com> To: virtio-fs@redhat.com, qemu-devel@nongnu.org Cc: miklos@szeredi.hu, stefanha@redhat.com, vgoyal@redhat.com, dgilbert@redhat.com Subject: [PATCH 1/4] virtiofsd: Release file locks using F_UNLCK Date: Fri, 15 Nov 2019 15:55:40 -0500 [thread overview] Message-ID: <20191115205543.1816-2-vgoyal@redhat.com> (raw) In-Reply-To: <20191115205543.1816-1-vgoyal@redhat.com> We are emulating posix locks for guest using open file description locks in virtiofsd. When any of the fd is closed in guest, we find associated OFD lock fd (if there is one) and close it to release all the locks. Assumption here is that there is no other thread using lo_inode_plock structure or plock->fd, hence it is safe to do so. But now we are about to introduce blocking variant of locks (SETLKW), and that means we might be waiting to a lock to be available and using plock->fd. And that means there are still users of plock structure. So release locks using fcntl(SETLK, F_UNLCK) instead and plock will be freed later. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> --- contrib/virtiofsd/passthrough_ll.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/contrib/virtiofsd/passthrough_ll.c b/contrib/virtiofsd/passthrough_ll.c index bc214df0c7..028e7da273 100644 --- a/contrib/virtiofsd/passthrough_ll.c +++ b/contrib/virtiofsd/passthrough_ll.c @@ -936,6 +936,14 @@ static void put_shared(struct lo_data *lo, struct lo_inode *inode) } } +static void release_plock(gpointer data) +{ + struct lo_inode_plock *plock = data; + + close(plock->fd); + free(plock); +} + /* Increments nlookup and caller must release refcount using * lo_inode_put(&parent). */ @@ -994,7 +1002,8 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name, inode->key.ino = e->attr.st_ino; inode->key.dev = e->attr.st_dev; pthread_mutex_init(&inode->plock_mutex, NULL); - inode->posix_locks = g_hash_table_new(g_direct_hash, g_direct_equal); + inode->posix_locks = g_hash_table_new_full(g_direct_hash, + g_direct_equal, NULL, release_plock); get_shared(lo, inode); @@ -1436,9 +1445,6 @@ static void unref_inode(struct lo_data *lo, struct lo_inode *inode, uint64_t n) if (!inode->nlookup) { lo_map_remove(&lo->ino_map, inode->fuse_ino); g_hash_table_remove(lo->inodes, &inode->key); - if (g_hash_table_size(inode->posix_locks)) { - fuse_log(FUSE_LOG_WARNING, "Hash table is not empty\n"); - } g_hash_table_destroy(inode->posix_locks); pthread_mutex_destroy(&inode->plock_mutex); @@ -1868,6 +1874,7 @@ static struct lo_inode_plock *lookup_create_plock_ctx(struct lo_data *lo, plock->fd = fd; g_hash_table_insert(inode->posix_locks, GUINT_TO_POINTER(plock->lock_owner), plock); + fuse_log(FUSE_LOG_DEBUG, "lookup_create_plock_ctx(): Inserted element in posix_locks hash table with value pointer %p\n", plock); return plock; } @@ -2046,6 +2053,7 @@ static void lo_flush(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi) (void) ino; struct lo_inode *inode; struct lo_inode_plock *plock; + struct flock flock; inode = lo_inode(req, ino); if (!inode) { @@ -2058,14 +2066,16 @@ static void lo_flush(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi) plock = g_hash_table_lookup(inode->posix_locks, GUINT_TO_POINTER(fi->lock_owner)); if (plock) { - g_hash_table_remove(inode->posix_locks, - GUINT_TO_POINTER(fi->lock_owner)); /* - * We had used open() for locks and had only one fd. So - * closing this fd should release all OFD locks. + * An fd is being closed. For posix locks, this means + * drop all the associated locks. */ - close(plock->fd); - free(plock); + memset(&flock, 0, sizeof(struct flock)); + flock.l_type = F_UNLCK; + flock.l_whence = SEEK_SET; + /* Unlock whole file */ + flock.l_start = flock.l_len = 0; + fcntl(plock->fd, F_SETLK, &flock); } pthread_mutex_unlock(&inode->plock_mutex); -- 2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com> To: virtio-fs@redhat.com, qemu-devel@nongnu.org Cc: miklos@szeredi.hu, vgoyal@redhat.com Subject: [Virtio-fs] [PATCH 1/4] virtiofsd: Release file locks using F_UNLCK Date: Fri, 15 Nov 2019 15:55:40 -0500 [thread overview] Message-ID: <20191115205543.1816-2-vgoyal@redhat.com> (raw) In-Reply-To: <20191115205543.1816-1-vgoyal@redhat.com> We are emulating posix locks for guest using open file description locks in virtiofsd. When any of the fd is closed in guest, we find associated OFD lock fd (if there is one) and close it to release all the locks. Assumption here is that there is no other thread using lo_inode_plock structure or plock->fd, hence it is safe to do so. But now we are about to introduce blocking variant of locks (SETLKW), and that means we might be waiting to a lock to be available and using plock->fd. And that means there are still users of plock structure. So release locks using fcntl(SETLK, F_UNLCK) instead and plock will be freed later. Signed-off-by: Vivek Goyal <vgoyal@redhat.com> --- contrib/virtiofsd/passthrough_ll.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/contrib/virtiofsd/passthrough_ll.c b/contrib/virtiofsd/passthrough_ll.c index bc214df0c7..028e7da273 100644 --- a/contrib/virtiofsd/passthrough_ll.c +++ b/contrib/virtiofsd/passthrough_ll.c @@ -936,6 +936,14 @@ static void put_shared(struct lo_data *lo, struct lo_inode *inode) } } +static void release_plock(gpointer data) +{ + struct lo_inode_plock *plock = data; + + close(plock->fd); + free(plock); +} + /* Increments nlookup and caller must release refcount using * lo_inode_put(&parent). */ @@ -994,7 +1002,8 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name, inode->key.ino = e->attr.st_ino; inode->key.dev = e->attr.st_dev; pthread_mutex_init(&inode->plock_mutex, NULL); - inode->posix_locks = g_hash_table_new(g_direct_hash, g_direct_equal); + inode->posix_locks = g_hash_table_new_full(g_direct_hash, + g_direct_equal, NULL, release_plock); get_shared(lo, inode); @@ -1436,9 +1445,6 @@ static void unref_inode(struct lo_data *lo, struct lo_inode *inode, uint64_t n) if (!inode->nlookup) { lo_map_remove(&lo->ino_map, inode->fuse_ino); g_hash_table_remove(lo->inodes, &inode->key); - if (g_hash_table_size(inode->posix_locks)) { - fuse_log(FUSE_LOG_WARNING, "Hash table is not empty\n"); - } g_hash_table_destroy(inode->posix_locks); pthread_mutex_destroy(&inode->plock_mutex); @@ -1868,6 +1874,7 @@ static struct lo_inode_plock *lookup_create_plock_ctx(struct lo_data *lo, plock->fd = fd; g_hash_table_insert(inode->posix_locks, GUINT_TO_POINTER(plock->lock_owner), plock); + fuse_log(FUSE_LOG_DEBUG, "lookup_create_plock_ctx(): Inserted element in posix_locks hash table with value pointer %p\n", plock); return plock; } @@ -2046,6 +2053,7 @@ static void lo_flush(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi) (void) ino; struct lo_inode *inode; struct lo_inode_plock *plock; + struct flock flock; inode = lo_inode(req, ino); if (!inode) { @@ -2058,14 +2066,16 @@ static void lo_flush(fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi) plock = g_hash_table_lookup(inode->posix_locks, GUINT_TO_POINTER(fi->lock_owner)); if (plock) { - g_hash_table_remove(inode->posix_locks, - GUINT_TO_POINTER(fi->lock_owner)); /* - * We had used open() for locks and had only one fd. So - * closing this fd should release all OFD locks. + * An fd is being closed. For posix locks, this means + * drop all the associated locks. */ - close(plock->fd); - free(plock); + memset(&flock, 0, sizeof(struct flock)); + flock.l_type = F_UNLCK; + flock.l_whence = SEEK_SET; + /* Unlock whole file */ + flock.l_start = flock.l_len = 0; + fcntl(plock->fd, F_SETLK, &flock); } pthread_mutex_unlock(&inode->plock_mutex); -- 2.20.1
next prev parent reply other threads:[~2019-11-15 21:03 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-15 20:55 [PATCH 0/4] [RFC] virtiofsd, vhost-user-fs: Add support for notification queue Vivek Goyal 2019-11-15 20:55 ` [Virtio-fs] " Vivek Goyal 2019-11-15 20:55 ` Vivek Goyal [this message] 2019-11-15 20:55 ` [Virtio-fs] [PATCH 1/4] virtiofsd: Release file locks using F_UNLCK Vivek Goyal 2019-11-22 10:07 ` Stefan Hajnoczi 2019-11-22 10:07 ` [Virtio-fs] " Stefan Hajnoczi 2019-11-22 13:45 ` Vivek Goyal 2019-11-22 13:45 ` [Virtio-fs] " Vivek Goyal 2019-11-15 20:55 ` [PATCH 2/4] virtiofd: Create a notification queue Vivek Goyal 2019-11-15 20:55 ` [Virtio-fs] " Vivek Goyal 2019-11-22 10:19 ` Stefan Hajnoczi 2019-11-22 10:19 ` [Virtio-fs] " Stefan Hajnoczi 2019-11-22 14:47 ` Vivek Goyal 2019-11-22 14:47 ` [Virtio-fs] " Vivek Goyal 2019-11-22 17:29 ` Dr. David Alan Gilbert 2019-11-22 17:29 ` [Virtio-fs] " Dr. David Alan Gilbert 2019-11-15 20:55 ` [PATCH 3/4] virtiofsd: Specify size of notification buffer using config space Vivek Goyal 2019-11-15 20:55 ` [Virtio-fs] " Vivek Goyal 2019-11-22 10:33 ` Stefan Hajnoczi 2019-11-22 10:33 ` [Virtio-fs] " Stefan Hajnoczi 2019-11-25 14:57 ` Vivek Goyal 2019-11-25 14:57 ` [Virtio-fs] " Vivek Goyal 2019-11-15 20:55 ` [PATCH 4/4] virtiofsd: Implement blocking posix locks Vivek Goyal 2019-11-15 20:55 ` [Virtio-fs] " Vivek Goyal 2019-11-22 10:53 ` Stefan Hajnoczi 2019-11-22 10:53 ` [Virtio-fs] " Stefan Hajnoczi 2019-11-25 15:38 ` Vivek Goyal 2019-11-22 17:47 ` Dr. David Alan Gilbert 2019-11-22 17:47 ` [Virtio-fs] " Dr. David Alan Gilbert 2019-11-25 15:44 ` Vivek Goyal 2019-11-26 13:02 ` Dr. David Alan Gilbert 2019-11-27 19:08 ` Vivek Goyal 2019-12-09 11:06 ` 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=20191115205543.1816-2-vgoyal@redhat.com \ --to=vgoyal@redhat.com \ --cc=dgilbert@redhat.com \ --cc=miklos@szeredi.hu \ --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: 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.