[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40f15366-6027-ec7a-e151-bcc108855cb8@I-love.SAKURA.ne.jp>
Date: Sun, 4 Sep 2022 16:17:37 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Eric Van Hensbergen <ericvh@...il.com>,
Latchesar Ionkov <lucho@...kov.net>,
Christian Schoenebeck <linux_oss@...debyte.com>,
syzbot <syzbot+2f20b523930c32c160cc@...kaller.appspotmail.com>,
v9fs-developer@...ts.sourceforge.net,
syzkaller-bugs@...glegroups.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net/9p: use a dedicated spinlock for modifying IDR
On 2022/09/04 15:36, Dominique Martinet wrote:
> We have an idr per client though so this is needlessly adding contention
> between multiple 9p mounts.
>
> That probably doesn't matter too much in the general case,
I thought this is not a hot operation where contention matters.
> but adding a
> different lock per connection is cheap so let's do it the other way
> around: could you add a lock to the p9_conn struct in net/9p/trans_fd.c
> and replace c->lock by it there?
Not impossible, but may not be cheap for lockdep.
> That should have identical effect as other transports don't use client's
> .lock ; and the locking in trans_fd.c is to protect req's status and
> trans_fd's own lists which is orthogonal to client's lock that protects
> tag allocations. I agree it should work in theory.
>
> (If you don't have time to do this this patch has been helpful enough and
> I can do it eventually)
Sent as https://lkml.kernel.org/r/68540a56-6a5f-87e9-3c21-49c58758bfaf@I-love.SAKURA.ne.jp .
By the way, I think credit for the patch on https://syzkaller.appspot.com/bug?extid=50f7e8d06c3768dd97f3 goes to Hillf Danton...
Powered by blists - more mailing lists