From: Dominique Martinet <asmadeus@codewreck.org>
To: jiangyiwen <jiangyiwen@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Eric Van Hensbergen <ericvh@gmail.com>,
Ron Minnich <rminnich@sandia.gov>,
Latchesar Ionkov <lucho@ionkov.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
v9fs-developer@lists.sourceforge.net
Subject: Re: [V9fs-developer] [PATCH] net/9p: Fix a deadlock case in the virtio transport
Date: Sat, 14 Jul 2018 11:05:02 +0200 [thread overview]
Message-ID: <20180714090502.GA16186@nautica> (raw)
In-Reply-To: <5B49B8CF.40709@huawei.com>
jiangyiwen wrote on Sat, Jul 14, 2018:
> When client has multiple threads that issue io requests all the
> time, and the server has a very good performance, it may cause
> cpu is running in the irq context for a long time because it can
> check virtqueue has buf in the *while* loop.
>
> So we should keep chan->lock in the whole loop.
Hmm, this is generally bad practice to hold a spin lock for long.
In general, spin locks are meant to protect data, not code.
I'd want some numbers to decide on this one, even if I think this
particular case is safe (e.g. this cannot dead-lock)
> Signed-off-by: Yiwen Jiang <jiangyiwen@huawei.com>
> ---
> net/9p/trans_virtio.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 05006cb..9b0f5f2 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -148,20 +148,18 @@ static void req_done(struct virtqueue *vq)
>
> p9_debug(P9_DEBUG_TRANS, ": request done\n");
>
> + spin_lock_irqsave(&chan->lock, flags);
> while (1) {
> - spin_lock_irqsave(&chan->lock, flags);
> req = virtqueue_get_buf(chan->vq, &len);
> - if (req == NULL) {
> - spin_unlock_irqrestore(&chan->lock, flags);
> + if (req == NULL)
> break;
> - }
> chan->ring_bufs_avail = 1;
> - spin_unlock_irqrestore(&chan->lock, flags);
> /* Wakeup if anyone waiting for VirtIO ring space. */
> wake_up(chan->vc_wq);
In particular, the wake up here echoes to wait events that will
immediately try to grab the lock, and will needlessly spin on it until
this thread is done.
If we do go this way I'd want setting chan->ring_bufs_avail to be done
just before unlocking and the wakeup to be done just after unlocking out
of the loop iff we processed at least one iteration here.
That should also save you precious cpu cycles while under lock :)
--
Dominique Martinet
next prev parent reply other threads:[~2018-07-14 9:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-14 8:48 [V9fs-developer] [PATCH] net/9p: Fix a deadlock case in the virtio transport jiangyiwen
2018-07-14 9:05 ` Dominique Martinet [this message]
2018-07-14 11:12 ` jiangyiwen
2018-07-14 12:47 ` Dominique Martinet
2018-07-16 1:55 ` jiangyiwen
2018-07-16 13:38 ` Dominique Martinet
2018-07-17 1:12 ` jiangyiwen
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=20180714090502.GA16186@nautica \
--to=asmadeus@codewreck.org \
--cc=akpm@linux-foundation.org \
--cc=ericvh@gmail.com \
--cc=jiangyiwen@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=rminnich@sandia.gov \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox