Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5352155ybp; Tue, 8 Oct 2019 01:14:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqwRRaIZwr4FSprck2Y28sUqVu4KJQUONYTHTQzi8Ltp1uY6GuQ8vTRkRJZDSpF/DRbZYsPz X-Received: by 2002:a50:e616:: with SMTP id y22mr32582259edm.253.1570522460644; Tue, 08 Oct 2019 01:14:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570522460; cv=none; d=google.com; s=arc-20160816; b=nNJT5Fmy7uNVp0gz9+Wu4sOfvHzdtF1UBdeL+z7WTv/a5uW/gqRTRR8yxhvAZCcU7M NHYVSkpcaDa9602nL5nLH0z3ziJ+hQ+U91+p2E9gi5upnyyDQrgoAfkj+z++zblOw8uD akPlU+qgct0O4vuWMy0eYuXpM9l0CicSxSXeYzu1JEKHqOKVsloB6O/GM1mUAs2F0X6Z y2buxAvA9kQjn8OPstkRRwRLHS4qqg5Mmo5Xk1abzbX1mFQWwVrPSGj/7Wqwo0jqTRdm BaDl7jiaoIUmoZOHOsAD3ljmLLMUlvR0b4CniYkGX49XjKMIBi2crx7X5TtTNquBHZS3 Hq8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LRw2nUwXDpX/s9reIbhkN0rYHhrGthC9PtGcXI5QI30=; b=s036klZi9P9Yj1erxGnqtUJ9KcXOsL6WnNAB6xqiJp2rPRzWspKQ2CvDM6h6cdjkuI L/qKwYfHrBBTZ+1dB/GvFLLRGCLNJJMVvjW/2iUMY+zX2ULHrc57q3xQQEs9IeVk5yAW ujCr8Tf9RXDeACoGK18IT38KzcqmN/qcnWPjGPRQ2ot4GbSltcFnKaicpaAwBOm2UvLR MfH1xl95DBdzDz0tY+6otKJTpKNzcDJ14TNaFBADbDKzBXTUuMjQwTYrp1O+wDEOSSpD lgro3i+ESZdB6VnqldJ6poorJiezHVYyYC2Njg0mo/Utgn80aLzbg26hnJyEMEmS+lo8 YMGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tFcsSOCG; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v7si9223701edr.125.2019.10.08.01.13.55; Tue, 08 Oct 2019 01:14:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tFcsSOCG; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730506AbfJHINg (ORCPT + 99 others); Tue, 8 Oct 2019 04:13:36 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:32813 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730309AbfJHINg (ORCPT ); Tue, 8 Oct 2019 04:13:36 -0400 Received: by mail-lf1-f65.google.com with SMTP id y127so11273645lfc.0; Tue, 08 Oct 2019 01:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LRw2nUwXDpX/s9reIbhkN0rYHhrGthC9PtGcXI5QI30=; b=tFcsSOCGp9hyWVQnJOvF/8gyV5y4Eo7v0lg4cj3BZugrr6w3/4lEZJYSFPxoIcBJlq PwudanwBLOH/9XnmkUOi+f3olI0PbcO27yupyh2vuhbazLgPInKR9bWMzttfhmDP5+WF 8fKPkDiFnKewoc9SVs4YZy4r2lu966cqAiculSRdjAARpO9BYDg8nAgSAO+flx/DCTMd bgtm0Z3x1I3fiFn9vZ58YwdXWMBjmC/Io48qdNOd9Cot9zBbRIp/5r/36gOZCpwtA3qT nzSTDe6ADQMIpdAwCEsQETpOIq+wr4ynOwrn+Z4hdW/jdKucNANS1NDUKp/20EIENded 4haw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LRw2nUwXDpX/s9reIbhkN0rYHhrGthC9PtGcXI5QI30=; b=WponLL7ywPPBUije8NNFrBR8Y9xZ08IPkKVK6Tsiz6d4d3rUT2NpiBOFiyxVamjl9U L6C95m4JCOOgkM4KoVnVFAplsjVVzIIRNQaQseJKOTnVZKiBkXCwcMmrXR5sR7vOd29P QjMnT3/o4uWSdyBke1DZqs/io+vQ1+/ErDoCtiXKu+nhteWgbCKQJDGXc2wjPXIt1tqc BGIFjt01ZW7q52VuZ0ct7oeMJHOOJrkxYT6tsOTOhQ2nM7IVigqrOZo53ieTQ6aR32Cj 36tcZIcZVLy3/1Evj8E5f8lQxEXST4HJNEMf+OwDTkLiRMR9qv9wuXV9sIKlAse4Fz2f Th+Q== X-Gm-Message-State: APjAAAUdJTJGIZuw9092E1QKWfLfwRb3HP8weG6CCd2TMnWoNkXT1qvI VnKH6x/Z5zIAJEIXqTh3mg71drPFP6NxNxI3rRY= X-Received: by 2002:a19:2207:: with SMTP id i7mr19618360lfi.185.1570522414136; Tue, 08 Oct 2019 01:13:34 -0700 (PDT) MIME-Version: 1.0 References: <20190928164843.31800-1-ap420073@gmail.com> <20190928164843.31800-8-ap420073@gmail.com> <33adc57c243dccc1dcb478113166fa01add3d49a.camel@sipsolutions.net> <72bc9727d0943c56403eac03b6de69c00b0f53f6.camel@sipsolutions.net> In-Reply-To: From: Taehee Yoo Date: Tue, 8 Oct 2019 17:13:22 +0900 Message-ID: Subject: Re: [PATCH net v4 07/12] macvlan: use dynamic lockdep key instead of subclass To: Johannes Berg Cc: David Miller , Netdev , linux-wireless@vger.kernel.org, Jakub Kicinski , j.vosburgh@gmail.com, vfalico@gmail.com, Andy Gospodarek , =?UTF-8?B?SmnFmcOtIFDDrXJrbw==?= , Sabrina Dubroca , Roopa Prabhu , saeedm@mellanox.com, manishc@marvell.com, rahulv@marvell.com, kys@microsoft.com, haiyangz@microsoft.com, Stephen Hemminger , sashal@kernel.org, hare@suse.de, varun@chelsio.com, ubraun@linux.ibm.com, kgraul@linux.ibm.com, Jay Vosburgh , Cody Schuffelen , bjorn@mork.no Content-Type: text/plain; charset="UTF-8" Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 7 Oct 2019 at 20:41, Johannes Berg wrote: > Hi Johannes, > On Sat, 2019-10-05 at 18:13 +0900, Taehee Yoo wrote: > > > > If we place lockdep keys into "struct net_device", this macro would be a > > little bit modified and reused. And driver code shape will not be huge > > changed. I think this way is better than this v4 way. > > So I will try it. > > What I was thinking was that if we can do this for every VLAN netdev, > why shouldn't we do it for *every* netdev unconditionally? Some code > could perhaps even be simplified if this was just a general part of > netdev allocation. > Your opinion makes sense. I think there is no critical reason that every netdev shouldn't have own lockdep keys. By comparison, the benefits are obvious. > > > But it seems to me the whole nesting also has to be applied here? > > > > > > __dev_xmit_skb: > > > * qdisc_run_begin() > > > * sch_direct_xmit() > > > * HARD_TX_LOCK(dev, txq, smp_processor_id()); > > > * dev_hard_start_xmit() // say this is VLAN > > > * dev_queue_xmit() // on real_dev > > > * __dev_xmit_skb // recursion on another netdev > > > > > > Now if you have VLAN-in-VLAN the whole thing will recurse right? > > > > > > > I have checked on this routine. > > Only xmit_lock(HARD_TX_LOCK) could be nested. other > > qdisc locks(runinng, busylock) will not be nested. > > OK, I still didn't check it too closely I guess, or got confused which > lock I should look at. > > > This patch already > > handles the _xmit_lock key. so I think there is no problem. > > Right > > > But I would like to place four lockdep keys(busylock, address, > > running, _xmit_lock) into "struct net_device" because of code complexity. > > > > Let me know if I misunderstood anything. > > Nothing to misunderstand - I was just asking/wondering why the qdisc > locks were not treated the same way. > I'm always thankful for your detailed and careful reviews. > johannes > Thank you, Taehee Yoo