linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Tomas Bortoli <tomasbortoli@gmail.com>
Cc: ericvh@gmail.com, rminnich@sandia.gov, lucho@ionkov.net,
	jiangyiwen@huawei.com, davem@davemloft.net,
	v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, syzkaller@googlegroups.com
Subject: Re: [PATCH] net/9p/trans_fd.c: fix double list_del() and race in access
Date: Mon, 23 Jul 2018 05:02:51 +0200	[thread overview]
Message-ID: <20180723030251.GB24608@nautica> (raw)
In-Reply-To: <20180720132801.22749-1-tomasbortoli@gmail.com>

Tomas Bortoli wrote on Fri, Jul 20, 2018:
> This patch uses list_del_init() instead of list_del() to eliminate
> "req_list". This to prevent double list_del()'s calls to the same list
> from provoking a GPF. Furthermore, this patch fixes an access to
> "req_list" that was made without getting the relative lock.

Please see comment about locking.

As for list_del to list_del_init, it feels a little wrong to me, but I
don't have a better idea so let's go with that.
Do you know what happened to trigger this? one thread running
p9_conn_cancel then the other thread doing p9_fd_cancel ?

> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
> ---
> 
>  net/9p/trans_fd.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index a64b01c56e30..131bb1f059e6 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -223,7 +223,9 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
>  
>  	list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
>  		p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
> -		list_del(&req->req_list);
> +		spin_lock_irqsave(&m->client->lock, flags);
> +		list_del_init(&req->req_list);
> +		spin_unlock_irqrestore(&m->client->lock, flags);

Just locking around one item if you're afraid it might change won't be
enough - list_for_each_entry_safe is only "safe" from removing the
current element from the list yourself, not from other threads messing
with it, so you'd need to lock around the whole loop if that's what
you're protecting against.

(Also, since I've taken the other patchs to change spin locks on
client->lock to spin_lock instead of spin_lock_irqsave, please use that
function for new locking of that variable - in general just basing your
patchs off linux-next's master branch is a good idea.)

>  		if (!req->t_err)
>  			req->t_err = err;
>  		p9_client_cb(m->client, req, REQ_STATUS_ERROR);
> @@ -369,7 +371,7 @@ static void p9_read_work(struct work_struct *work)
>  		spin_lock(&m->client->lock);
>  		if (m->req->status != REQ_STATUS_ERROR)
>  			status = REQ_STATUS_RCVD;
> -		list_del(&m->req->req_list);
> +		list_del_init(&m->req->req_list);
>  		spin_unlock(&m->client->lock);
>  		p9_client_cb(m->client, m->req, status);
>  		m->rc.sdata = NULL;
> @@ -684,7 +686,7 @@ static int p9_fd_cancel(struct p9_client *client, struct p9_req_t *req)
>  	spin_lock(&client->lock);
>  
>  	if (req->status == REQ_STATUS_UNSENT) {
> -		list_del(&req->req_list);
> +		list_del_init(&req->req_list);
>  		req->status = REQ_STATUS_FLSHD;
>  		ret = 0;
>  	}
> @@ -701,7 +703,7 @@ static int p9_fd_cancelled(struct p9_client *client, struct p9_req_t *req)
>  	 * remove it from the list.
>  	 */
>  	spin_lock(&client->lock);
> -	list_del(&req->req_list);
> +	list_del_init(&req->req_list);
>  	spin_unlock(&client->lock);
>  
>  	return 0;

  parent reply	other threads:[~2018-07-23  3:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20 13:28 [PATCH] net/9p/trans_fd.c: fix double list_del() and race in access Tomas Bortoli
2018-07-23  2:24 ` jiangyiwen
2018-07-23  3:02 ` Dominique Martinet [this message]
2018-07-23 11:46   ` Tomas Bortoli

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=20180723030251.GB24608@nautica \
    --to=asmadeus@codewreck.org \
    --cc=davem@davemloft.net \
    --cc=ericvh@gmail.com \
    --cc=jiangyiwen@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=netdev@vger.kernel.org \
    --cc=rminnich@sandia.gov \
    --cc=syzkaller@googlegroups.com \
    --cc=tomasbortoli@gmail.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 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).