From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: v9fs-developer@lists.sourceforge.net,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
syzbot <syzbot+2f20b523930c32c160cc@syzkaller.appspotmail.com>,
syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/9p: use a dedicated spinlock for trans_fd
Date: Fri, 7 Oct 2022 10:05:39 +0900 [thread overview]
Message-ID: <Yz97YyDlV8tOr82t@codewreck.org> (raw)
In-Reply-To: <2356596.7K3kzkM6Yp@silver>
Christian Schoenebeck wrote on Thu, Oct 06, 2022 at 03:16:40PM +0200:
> > net/9p/trans_fd.c | 42 ++++++++++++++++++++++++++----------------
> > 1 file changed, 26 insertions(+), 16 deletions(-)
>
> Late on the party, sorry. Note that you already queued a slightly different
> version than this patch here, anyway, one thing ...
Did I? Oh, I apparently reworded the commit message a bit, sorry:
(where HEAD is this patch and 1622... the queued patch)
$ git range-diff HEAD^- 16228c9a4215^-
1: e35fb8546af2 ! 1: 16228c9a4215 net/9p: use a dedicated spinlock for trans_fd
@@ Commit message
Since the locks actually protect different things in client.c and in
trans_fd.c, just replace trans_fd.c's lock by a new one specific to the
- transport instead of using spin_lock_irq* variants everywhere
- (client.c's protect the idr for tag allocations, while
- trans_fd.c's protects its own req list and request status field
+ transport (client.c's protect the idr for fid/tag allocations,
+ while trans_fd.c's protects its own req list and request status field
that acts as the transport's state machine)
- Link: https://lkml.kernel.org/r/20220904112928.1308799-1-asmadeus@codewreck.org
+ Link: https://lore.kernel.org/r/20220904112928.1308799-1-asmadeus@codewreck.org
Link: https://lkml.kernel.org/r/2470e028-9b05-2013-7198-1fdad071d999@I-love.SAKURA.ne.jp [1]
Link: https://syzkaller.appspot.com/bug?extid=2f20b523930c32c160cc [2]
Reported-by: syzbot <syzbot+2f20b523930c32c160cc@syzkaller.appspotmail.com>
> > @@ -832,6 +840,7 @@ static int p9_fd_open(struct p9_client *client, int rfd,
> > int wfd)
> >
> > client->trans = ts;
> > client->status = Connected;
> > + spin_lock_init(&ts->conn.req_lock);
>
> Are you sure this is the right place for spin_lock_init()? Not rather in
> p9_conn_create()?
Good point, 'ts->conn' (named... m over there for some reason...) is
mostly initialized in p9_conn_create; it makes much more sense to move
it there despite being slightly further away from the allocation.
It's a bit of a pain to check as the code is spread over many paths (fd,
unix, tcp) but it looks equivalent to me:
- p9_fd_open is only called from p9_fd_create which immediately calls
p9_conn_create
- below p9_socket_open itself immediately calls p9_conn_create
I've moved the init and updated my next branch after very basic check
https://github.com/martinetd/linux/commit/e5cfd99e9ea6c13b3f0134585f269c509247ac0e:
----
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 5b4807411281..d407f31bb49d 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -591,6 +591,7 @@ static void p9_conn_create(struct p9_client *client)
INIT_LIST_HEAD(&m->mux_list);
m->client = client;
+ spin_lock_init(&m->req_lock);
INIT_LIST_HEAD(&m->req_list);
INIT_LIST_HEAD(&m->unsent_req_list);
INIT_WORK(&m->rq, p9_read_work);
@@ -840,7 +841,6 @@ static int p9_fd_open(struct p9_client *client, int rfd, int wfd)
client->trans = ts;
client->status = Connected;
- spin_lock_init(&ts->conn.req_lock);
return 0;
@@ -875,7 +875,6 @@ static int p9_socket_open(struct p9_client *client, struct socket *csocket)
p->wr = p->rd = file;
client->trans = p;
client->status = Connected;
- spin_lock_init(&p->conn.req_lock);
p->rd->f_flags |= O_NONBLOCK;
----
> The rest LGTM.
Thank you for the look :)
--
Dominique
next prev parent reply other threads:[~2022-10-07 1:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 22:24 [syzbot] inconsistent lock state in p9_req_put syzbot
2022-09-04 6:09 ` [PATCH] net/9p: use a dedicated spinlock for modifying IDR Tetsuo Handa
2022-09-04 6:36 ` Dominique Martinet
2022-09-04 7:06 ` [PATCH v2] " Tetsuo Handa
2022-09-04 7:55 ` Dominique Martinet
2022-09-04 10:02 ` Tetsuo Handa
2022-09-04 10:52 ` Dominique Martinet
2022-09-04 10:58 ` Tetsuo Handa
2022-09-04 7:17 ` [PATCH] " Tetsuo Handa
2022-09-04 11:29 ` [PATCH] net/9p: use a dedicated spinlock for trans_fd Dominique Martinet
2022-09-04 13:03 ` Tetsuo Handa
2022-10-06 13:16 ` Christian Schoenebeck
2022-10-07 1:05 ` Dominique Martinet [this message]
2022-10-07 9:29 ` Christian Schoenebeck
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=Yz97YyDlV8tOr82t@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzbot+2f20b523930c32c160cc@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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.