From: Dominique Martinet <asmadeus@codewreck.org>
To: Jianyong Wu <jianyong.wu@arm.com>
Cc: ericvh@gmail.com, lucho@ionkov.net, qemu_oss@crudebyte.com,
groug@kaod.org, v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, justin.he@arm.com
Subject: Re: [PATCH RFC v2 4/4] 9p: fix race issue in fid contention.
Date: Wed, 23 Sep 2020 16:49:53 +0200 [thread overview]
Message-ID: <20200923144953.GA1685@nautica> (raw)
In-Reply-To: <20200923141146.90046-5-jianyong.wu@arm.com>
Overall looks good; a few comments.
Jianyong Wu wrote on Wed, Sep 23, 2020:
> open-unlink-f*syscall test:
> I have tested for f*syscall include: ftruncate fstat fchown fchmod faccessat.
Given the other thread, what did you test this with?
Since qemu doesn't work apparently do you have a in-house server at arm
I could test?
(I'll try with ganesha otherwise, it keeps files open so it should work
I think...)
> + atomic_set(&fid->count, 1);
I kind of like the refcount API becauese it has some extra overflow
checks; but it requires a bit more work around clunk (instead of bailing
out early if counter hits 0, you need to have it call a separate
function in case it does)
That's mostly esthetics though I'm not going to fuss over that.
> @@ -74,6 +77,7 @@ static struct p9_fid *v9fs_fid_find_inode(struct inode *inode, kuid_t uid)
> void v9fs_open_fid_add(struct inode *inode, struct p9_fid *fid)
> {
> spin_lock(&inode->i_lock);
> + atomic_set(&fid->count, 1);
Hm, that should be done at fid creation time in net/9p/client.c
p9_fid_create ; no ?
(you do it there already, I don't see what reseting count here brings
except confusion)
> diff --git a/fs/9p/fid.h b/fs/9p/fid.h
> index dfa11df02818..1fed96546728 100644
> --- a/fs/9p/fid.h
> +++ b/fs/9p/fid.h
> @@ -22,6 +22,14 @@ static inline struct p9_fid *clone_fid(struct p9_fid *fid)
> }
> static inline struct p9_fid *v9fs_fid_clone(struct dentry *dentry)
> {
> - return clone_fid(v9fs_fid_lookup(dentry));
> + struct p9_fid *fid, *nfid;
> +
> + fid = v9fs_fid_lookup(dentry);
> + if (!fid || IS_ERR(fid))
> + return fid;
> +
> + nfid = p9_client_walk(fid, 0, NULL, 1);
I think you clone_fid() here is slightly easier to understand; everyone
doesn't know that a walk with no component is a clone.
The compiler will optimize that IS_ERR(fid) is checked twice, it's fine.
> diff --git a/include/net/9p/client.h b/include/net/9p/client.h
> index ce7882da8e86..58ed9bd306bd 100644
> --- a/include/net/9p/client.h
> +++ b/include/net/9p/client.h
> @@ -140,10 +140,16 @@ struct p9_client {
> *
> * TODO: This needs lots of explanation.
> */
> +enum fid_source {
> + FID_FROM_OTHER,
> + FID_FROM_INODE,
> + FID_FROM_DENTRY,
> +};
leftovers from previous iteration.
Overall looks good to me.
I'd need to spend some time checking the actual counting part &
hammering the fs a bit then confirming no fid got forgotten (there's a
pr_info at umount time) but I'm happy with this ; thanks!
--
Dominique
next prev parent reply other threads:[~2020-09-23 14:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-23 14:11 [PATCH RFC v2 0/4] 9p: fix open-unlink-f*syscall bug Jianyong Wu
2020-09-23 14:11 ` [PATCH v2 1/4] fs/9p: fix create-unlink-getattr idiom Jianyong Wu
2020-09-23 14:11 ` [PATCH v2 2/4] fs/9p: track open fids Jianyong Wu
2020-09-23 14:11 ` [PATCH v2 3/4] fs/9p: search open fids first Jianyong Wu
2020-09-23 14:11 ` [PATCH RFC v2 4/4] 9p: fix race issue in fid contention Jianyong Wu
2020-09-23 14:49 ` Dominique Martinet [this message]
2020-09-24 8:38 ` Jianyong Wu
2020-09-24 8:56 ` Greg Kurz
2020-09-24 9:51 ` Dominique Martinet
2020-09-25 9:49 ` Jianyong Wu
2020-11-03 10:41 ` Dominique Martinet
2020-11-04 11:32 ` Christian Schoenebeck
2020-11-04 11:57 ` Dominique Martinet
2020-11-05 12:32 ` Christian Schoenebeck
2020-11-05 7:05 ` Jianyong Wu
2020-11-19 16:06 ` [PATCH 0/2] follow-up to " Dominique Martinet
2020-11-19 16:06 ` [PATCH 1/2] 9p: apply review requests for fid refcounting Dominique Martinet
2020-11-19 16:06 ` [PATCH 2/2] 9p: Fix writeback fid incorrectly being attached to dentry Dominique Martinet
-- strict thread matches above, loose matches on Subject: below --
2020-09-24 4:50 [PATCH RFC v2 4/4] 9p: fix race issue in fid contention kernel test robot
2020-09-24 7:01 ` Dan Carpenter
2020-09-24 8:29 [kbuild] " Reshetova, Elena
2020-09-24 8:40 ` Dan Carpenter
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=20200923144953.GA1685@nautica \
--to=asmadeus@codewreck.org \
--cc=ericvh@gmail.com \
--cc=groug@kaod.org \
--cc=jianyong.wu@arm.com \
--cc=justin.he@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=qemu_oss@crudebyte.com \
--cc=v9fs-developer@lists.sourceforge.net \
/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.