From: Stefan Hajnoczi <stefanha@redhat.com>
To: virtio-fs@redhat.com, qemu-devel@nongnu.org
Cc: Liu Bo <bo.liu@linux.alibaba.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: [Qemu-devel] [PATCH 3/5] virtiofsd: rename inode->refcount to inode->nlookup
Date: Wed, 31 Jul 2019 17:10:04 +0100 [thread overview]
Message-ID: <20190731161006.9447-4-stefanha@redhat.com> (raw)
In-Reply-To: <20190731161006.9447-1-stefanha@redhat.com>
This reference counter plays a specific role in the FUSE protocol. It's
not a generic object reference counter and the FUSE kernel code calls it
"nlookup".
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
contrib/virtiofsd/passthrough_ll.c | 36 ++++++++++++++++++++----------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/contrib/virtiofsd/passthrough_ll.c b/contrib/virtiofsd/passthrough_ll.c
index e1d729d26b..135123366a 100644
--- a/contrib/virtiofsd/passthrough_ll.c
+++ b/contrib/virtiofsd/passthrough_ll.c
@@ -97,7 +97,19 @@ struct lo_inode {
int fd;
bool is_symlink;
struct lo_key key;
- uint64_t refcount; /* protected by lo->mutex */
+
+ /* This counter keeps the inode alive during the FUSE session.
+ * Incremented when the FUSE inode number is sent in a reply
+ * (FUSE_LOOKUP, FUSE_READDIRPLUS, etc). Decremented when an inode is
+ * released by requests like FUSE_FORGET, FUSE_RMDIR, FUSE_RENAME, etc.
+ *
+ * Note that this value is untrusted because the client can manipulate
+ * it arbitrarily using FUSE_FORGET requests.
+ *
+ * Protected by lo->mutex.
+ */
+ uint64_t nlookup;
+
uint64_t version_offset;
uint64_t ireg_refid;
fuse_ino_t fuse_ino;
@@ -485,7 +497,7 @@ retry:
if (last == path) {
p = &lo->root;
pthread_mutex_lock(&lo->mutex);
- p->refcount++;
+ p->nlookup++;
pthread_mutex_unlock(&lo->mutex);
} else {
*last = '\0';
@@ -688,8 +700,8 @@ static struct lo_inode *lo_find(struct lo_data *lo, struct stat *st)
pthread_mutex_lock(&lo->mutex);
p = g_hash_table_lookup(lo->inodes, &key);
if (p) {
- assert(p->refcount > 0);
- p->refcount++;
+ assert(p->nlookup > 0);
+ p->nlookup++;
}
pthread_mutex_unlock(&lo->mutex);
@@ -797,7 +809,7 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name,
goto out_err;
inode->is_symlink = S_ISLNK(e->attr.st_mode);
- inode->refcount = 1;
+ inode->nlookup = 1;
inode->fd = newfd;
newfd = -1;
inode->key.ino = e->attr.st_ino;
@@ -1051,7 +1063,7 @@ static void lo_link(fuse_req_t req, fuse_ino_t ino, fuse_ino_t parent,
goto out_err;
pthread_mutex_lock(&lo->mutex);
- inode->refcount++;
+ inode->nlookup++;
pthread_mutex_unlock(&lo->mutex);
e.ino = inode->fuse_ino;
update_version(lo, inode);
@@ -1200,9 +1212,9 @@ static void unref_inode(struct lo_data *lo, struct lo_inode *inode, uint64_t n)
return;
pthread_mutex_lock(&lo->mutex);
- assert(inode->refcount >= n);
- inode->refcount -= n;
- if (!inode->refcount) {
+ assert(inode->nlookup >= n);
+ inode->nlookup -= 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)) {
@@ -1225,7 +1237,7 @@ static int unref_all_inodes_cb(gpointer key, gpointer value,
struct lo_inode *inode = value;
struct lo_data *lo = user_data;
- inode->refcount = 0;
+ inode->nlookup = 0;
lo_map_remove(&lo->ino_map, inode->fuse_ino);
close(inode->fd);
@@ -1252,7 +1264,7 @@ static void lo_forget_one(fuse_req_t req, fuse_ino_t ino, uint64_t nlookup)
if (lo_debug(req)) {
fuse_debug(" forget %lli %lli -%lli\n",
(unsigned long long) ino,
- (unsigned long long) inode->refcount,
+ (unsigned long long) inode->nlookup,
(unsigned long long) nlookup);
}
@@ -2581,7 +2593,7 @@ static void setup_root(struct lo_data *lo, struct lo_inode *root)
root->fd = fd;
root->key.ino = stat.st_ino;
root->key.dev = stat.st_dev;
- root->refcount = 2;
+ root->nlookup = 2;
}
static void setup_proc_self_fd(struct lo_data *lo)
--
2.21.0
next prev parent reply other threads:[~2019-07-31 16:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 16:10 [Qemu-devel] [PATCH 0/5] virtiofsd: multithreading preparation part 2 Stefan Hajnoczi
2019-07-31 16:10 ` [Qemu-devel] [PATCH 1/5] virtiofsd: take lo->mutex around lo_add_fd_mapping() Stefan Hajnoczi
2019-07-31 18:45 ` Dr. David Alan Gilbert
2019-08-01 9:17 ` Stefan Hajnoczi
2019-07-31 16:10 ` [Qemu-devel] [PATCH 2/5] virtiofsd: take lo->mutex around lo_add_dirp_mapping() Stefan Hajnoczi
2019-08-01 11:45 ` Dr. David Alan Gilbert
2019-07-31 16:10 ` Stefan Hajnoczi [this message]
2019-08-01 12:00 ` [Qemu-devel] [PATCH 3/5] virtiofsd: rename inode->refcount to inode->nlookup Dr. David Alan Gilbert
2019-07-31 16:10 ` [Qemu-devel] [PATCH 4/5] virtiofsd: fix inode nlookup leaks Stefan Hajnoczi
2019-07-31 16:10 ` [Qemu-devel] [PATCH 5/5] virtiofsd: introduce inode refcount to prevent use-after-free Stefan Hajnoczi
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=20190731161006.9447-4-stefanha@redhat.com \
--to=stefanha@redhat.com \
--cc=bo.liu@linux.alibaba.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).