Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1360844imm; Thu, 12 Jul 2018 00:02:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdy0GzyubkDdn9aZr0fMqn6KolufmyMrqZVHgXP/ktwoU6Fbn5Q1d8h5oq9+s8jXVh4+gAK X-Received: by 2002:a62:3687:: with SMTP id d129-v6mr1078341pfa.137.1531378950704; Thu, 12 Jul 2018 00:02:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531378950; cv=none; d=google.com; s=arc-20160816; b=dKD/NBP9v+EeZOb2It77YFKhWe1Wm2o2DpbcpZ9OOSOMiszoa1w/Ls3bm0dxIQcFeC y2WmGDnC3RBUTIbXlVZWKMJvNL978KlhGYzEbZhuxJl2Z3bGzp9bkIqGw3ByON9+ZIWO W0SGf/4mh7PArJzz/aBwnEAZjjQ9vWjKAdZFxGPuqies7gIPHCQ4MOE2snpd0I5pgU7w FAfr22taLCCtZNT0xtRX4lQk+guSxa5L1c/5+5FoDraQbTeRChVO4ZObyWpZVwEdKSAe LQgQ9rTHKqOEs0fJickboOm/XMr731A7cdRFidelfBsZTYL5nkzo72+jAF9P5wGe2AxP ReOA== 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=O4FElwvc/10w/VZZSEDBRW1tLmdl6BKs4XUvpGNmgGY=; b=jGxJHHtguKah1M0jba4XsfCtlW1IdIUke/v05ZEAtJiDTEYdzemFxRcFZzXaDOf16l zvqIyxeFVcOgoR/xp6y2Oh5QCXwnjedgvg6Cffktyvk0ZiJtJ1Mnv6EfBP6mzg67RhxO 9D46FxADnTNBwJ8VDtm87plbbNjR0/1S7o8888whWjBTXrAN1q9TkpEyxuC6J+C00qt2 uQus1ZeGUZY0is1vBPqgeSiuBH0XTOtG59i6ACq9Nva5BC0Jqc4GwteUQ0gLKm/DZsQH zO4C1F62ZgwltfL19IW+sdSrDsWJkGFfzZQKBE00jkATisHUwRatAbll6Zp2jmgG6Q8N cj4A== 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 t85-v6si22414245pfj.231.2018.07.12.00.02.14; Thu, 12 Jul 2018 00:02:30 -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 S1726562AbeGLHJv (ORCPT + 99 others); Thu, 12 Jul 2018 03:09:51 -0400 Received: from nautica.notk.org ([91.121.71.147]:37391 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725789AbeGLHJv (ORCPT ); Thu, 12 Jul 2018 03:09:51 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 3C547C009; Thu, 12 Jul 2018 09:01:37 +0200 (CEST) Date: Thu, 12 Jul 2018 09:01:22 +0200 From: Dominique Martinet To: piaojun Cc: "akpm@linux-foundation.org" , ericvh@gmail.com, rminnich@sandia.gov, lucho@ionkov.net, v9fs-developer@lists.sourceforge.net, Linux Kernel Mailing List Subject: Re: [V9fs-developer] [PATCH] net/9p/client.c: fix misuse of spin_lock_irqsave for p9_client lock Message-ID: <20180712070122.GB7639@nautica> References: <5B46F5AD.50200@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5B46F5AD.50200@huawei.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 piaojun wrote on Thu, Jul 12, 2018: > In p9_read_work(), we use spin_lock for client->lock, but misuse > spin_lock_irqsave for it in p9_fid_create(). As p9_client lock won't be > locked in irq context, so spin_lock is enough. And that will improve the > performance. Agreed on principle, see remark below > Signed-off-by: Jun Piao > --- > net/9p/client.c | 17 +++++++---------- > net/9p/trans_fd.c | 7 +++---- > 2 files changed, 10 insertions(+), 14 deletions(-) > > diff --git a/net/9p/client.c b/net/9p/client.c > index 8bc8b3e..b05cbfc 100644 > --- a/net/9p/client.c > +++ b/net/9p/client.c > @@ -260,7 +260,6 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize) > static struct p9_req_t * > p9_tag_alloc(struct p9_client *c, u16 tag, unsigned int max_size) > { > - unsigned long flags; > int row, col; > struct p9_req_t *req; > int alloc_msize = min(c->msize, max_size); > @@ -270,7 +269,7 @@ static struct p9_fcall *p9_fcall_alloc(int alloc_msize) > tag++; > > if (tag >= c->max_tag) { > - spin_lock_irqsave(&c->lock, flags); > + spin_lock(&c->lock); This code doesn't exist anymore with Matthew's idr rework, could you submit that patch based on top of my 9p-next branch? (unless you really want Andrew to take this for the next 4.18-rc, but I'm not convinced this qualifies) Please see my "Current 9P patches - test branch" for details: https://sourceforge.net/p/v9fs/mailman/message/36365359/ -- Dominique Martinet