Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp6799741imm; Tue, 24 Jul 2018 03:20:54 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcRctdsgntxSdqp3O8IIoy5qJBccSqx6PwoaOdrvMRMUr2v4lfkrDYfVzulFqYYfGpiH1/d X-Received: by 2002:a63:bf08:: with SMTP id v8-v6mr15402408pgf.3.1532427654489; Tue, 24 Jul 2018 03:20:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532427654; cv=none; d=google.com; s=arc-20160816; b=CpOT1QET3zOQL9q9QoBcbECy8uIR4c2Dbo9GL7IaBtbBow3p/pyHUQfXVNMciu6xoU qbigwq9mujgRETg/Fr4XeiPsN5Dukpyj73vPXdrqsE8+hguG/X/BFq13V1YWPYX5/ns+ LumkM/WF0YG0/2LD3f70v7FrTGEsZdQfXpJoxCYDhUafKnaaMsuOxZAzUiP2aLLSWIBp VQdRlaQOgWCFQzkn+U7U3UyQrIGhJTrIWmPNE2CvZZXG7nV7/RIvHhTTRCeYv0awQsBk EBkeAOshB7jcDSNsgf1pdkBeh/SlS1Y27GovtzS+NUycsT4S1+KJ+cp4rkag69YPd/5j 3Xig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=sRNR7Ek/KYl4e8pHlL1iAgZjG04KHnHeAdBkXgRq/Hc=; b=vTToDODQULSYTldBTOhawewJWlQxB5kw0CksJiCtq3omFms6Xil7w/xXGBpQBBwVuW ed1jYspVuaXs7SpjW8Z8WsXBtulTVdtL9KNQuSfwB97SRiLw57gXSJft7LyqkW/7HCcd Jae9QKJVE1pMl/ghhGYuwTBrEZ5Z6yiZy7DP5xRTSUoVZu+4tv3vEcWnFlCWigXyYK6w tHcLAdH2qkpG4OV3Ssq+2Jv79Xn4tnZoUYRFLUXJJknBsMTNPyTw6SevE60MtCIhOJmK hyBYfKwNDQewwgpTp2ZCcB5UnEGbVkQUbTucdAO4tbLAsR+kPqPeZ7016i/FoI3hwiAE 4jTA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i61-v6si10355505plb.138.2018.07.24.03.20.39; Tue, 24 Jul 2018 03:20:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388364AbeGXLZe (ORCPT + 99 others); Tue, 24 Jul 2018 07:25:34 -0400 Received: from nautica.notk.org ([91.121.71.147]:53338 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388251AbeGXLZe (ORCPT ); Tue, 24 Jul 2018 07:25:34 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id CE764C009; Tue, 24 Jul 2018 12:19:47 +0200 (CEST) Date: Tue, 24 Jul 2018 12:19:32 +0200 From: Dominique Martinet To: Tomas Bortoli Cc: jiangyiwen , davem@davemloft.net, v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com Subject: Re: [PATCH] net/p9/trans_fd.c: fix double list_del() Message-ID: <20180724101932.GA17454@nautica> References: <20180723121902.20201-1-tomasbortoli@gmail.com> <5B568374.9010507@huawei.com> <844e4101-6980-82dd-6f02-0a7193ed438c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <844e4101-6980-82dd-6f02-0a7193ed438c@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tomas Bortoli wrote on Tue, Jul 24, 2018: > >> @@ -228,6 +226,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err) > >> req->t_err = err; > >> p9_client_cb(m->client, req, REQ_STATUS_ERROR); > >> } > >> + spin_unlock(&m->client->lock); > > > > If you want to expand the ranges of client->lock, the cancel_list will not > > be necessary, you can optimize this code. > > > > Unfortunately, not. Moving the spin_lock() before the for makes the > crash appear again. This because the calls to list_move() in the for > before delete all the elements from req->req_list, so the list is empty, > another call to list_del() would trigger a double del. > That's why we hold the lock to update the status of all those requests.. > otherwise we have again the race with p9_fd_cancel(). What (I think) he meant is that since you're holding the lock all the way, you don't need to transfer all the items to a temporary list to loop on it immediately afterwards, but you could call the client cb directly. I'm personally not a fan of this approach as that would duplicate the code, even if the loop isn't big... This code is only called at disconnect time so I think using the extra list doesn't hurt anyone; but as usual do what you feel is better; I don't mind much either way. -- Dominique Martinet