Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp2169317ybp; Thu, 10 Oct 2019 03:23:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJ+edMeGlM0lMiqzc3JYNCuKBetLR6uSY4G3kZa5CcvOmtL5Kpp1+BKsjR7ahTm+Pfj0AV X-Received: by 2002:a17:906:af8e:: with SMTP id mj14mr7571072ejb.45.1570703005532; Thu, 10 Oct 2019 03:23:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570703005; cv=none; d=google.com; s=arc-20160816; b=et4/znaEttIX4eNXdGaMbiZ4s//Yvie5Li40Gdv35XE4Qa7gL0jb5X0ZyjrR4aeQjX s7O7Wj4A5A1iTD9BZlVUllu0Z8ghyRH8s7DITWxje9kRe2spnEvgnlC110KIzlxKc4YO SxYxZfJRm0Mc0xqNKdq8/jyjsHqSdcyzE0qOUQrWk15KGIDlXZGaRXC+W+jKolxcOHFy glX3JbRUG/Xqcoen0d5gZRxWzL8dv+DQimwUH7qWN3nnQSf5mkvYIcMMRyZ6zx4CvMEp m3F9OGLhqK1viL1jGT59l9stAa3yEx6vEFgvyHaBsCzIN7nOeWa/ewjq0sqSH/vhx3IN c4qw== 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; bh=nb6JBg5r6DpZzwmWeyaMwF9pS+0LGfH/ypRzlPwlI0g=; b=fa6NLShyM2fjXNw1D6cucsrUqIRMksnNDvDQdXsr2F0ilatEFm4qOtlR7sfC+WeonG FWbudO2/6JHtcLUmD5iODx8y18F68meV33OFvQyDMpGsX4nCD3QeUUhoxblOs09ieYiW W96UEPj2yr2Kim1yUhgTbEAZTkISnOEVEA1y7NG8E+Gl4tUmbt4v860FeAUb3T0hJ5DF SU9pLluPQmZuhFx2C3IwDMPc3dIN4Pon2Ln0vKFbr8SF5/Jf6mmsWy89hhe56BI+66Cj I46dSW2iIhq1y9xLtlurbki+HR3KUzv0iEqRN9SJn3dyV3xuk3teqmnv101gb3Gcp91O tcfw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g50si3220299edb.47.2019.10.10.03.22.46; Thu, 10 Oct 2019 03:23:25 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726359AbfJJKTe (ORCPT + 99 others); Thu, 10 Oct 2019 06:19:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49710 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725840AbfJJKTe (ORCPT ); Thu, 10 Oct 2019 06:19:34 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 68BBC30655F9; Thu, 10 Oct 2019 10:19:32 +0000 (UTC) Received: from bistromath.localdomain (unknown [10.36.118.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B4CF960BF4; Thu, 10 Oct 2019 10:19:26 +0000 (UTC) Date: Thu, 10 Oct 2019 12:19:25 +0200 From: Sabrina Dubroca To: Taehee Yoo Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, jakub.kicinski@netronome.com, johannes@sipsolutions.net, j.vosburgh@gmail.com, vfalico@gmail.com, andy@greyhouse.net, jiri@resnulli.us, roopa@cumulusnetworks.com, saeedm@mellanox.com, manishc@marvell.com, rahulv@marvell.com, kys@microsoft.com, haiyangz@microsoft.com, stephen@networkplumber.org, sashal@kernel.org, hare@suse.de, varun@chelsio.com, ubraun@linux.ibm.com, kgraul@linux.ibm.com, jay.vosburgh@canonical.com, schuffelen@google.com, bjorn@mork.no Subject: Re: [PATCH net v4 01/12] net: core: limit nested device depth Message-ID: <20191010101925.GA93190@bistromath.localdomain> References: <20190928164843.31800-1-ap420073@gmail.com> <20190928164843.31800-2-ap420073@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190928164843.31800-2-ap420073@gmail.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Thu, 10 Oct 2019 10:19:33 +0000 (UTC) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 2019-09-28, 16:48:32 +0000, Taehee Yoo wrote: > @@ -6790,23 +6878,45 @@ int netdev_walk_all_lower_dev(struct net_device *dev, > void *data), > void *data) > { > - struct net_device *ldev; > - struct list_head *iter; > - int ret; > + struct net_device *ldev, *next, *now, *dev_stack[MAX_NEST_DEV + 1]; > + struct list_head *niter, *iter, *iter_stack[MAX_NEST_DEV + 1]; > + int ret, cur = 0; > > - for (iter = &dev->adj_list.lower, > - ldev = netdev_next_lower_dev(dev, &iter); > - ldev; > - ldev = netdev_next_lower_dev(dev, &iter)) { > - /* first is the lower device itself */ > - ret = fn(ldev, data); > - if (ret) > - return ret; > + now = dev; > + iter = &dev->adj_list.lower; > > - /* then look at all of its lower devices */ > - ret = netdev_walk_all_lower_dev(ldev, fn, data); > - if (ret) > - return ret; > + while (1) { > + if (now != dev) { > + ret = fn(now, data); > + if (ret) > + return ret; > + } > + > + next = NULL; > + while (1) { > + ldev = netdev_next_lower_dev(now, &iter); > + if (!ldev) > + break; > + > + if (!next) { > + next = ldev; > + niter = &ldev->adj_list.lower; > + } else { > + dev_stack[cur] = ldev; > + iter_stack[cur++] = &ldev->adj_list.lower; > + break; > + } > + } > + > + if (!next) { > + if (!cur) > + return 0; Hmm, I don't think this condition is correct. If we have this topology: bridge0 / | \ / | \ / | \ dummy0 vlan1 vlan2 | \ dummy1 dummy2 We end up with the expected lower/upper levels for all devices: | device | upper | lower | |---------+-------+-------| | dummy0 | 2 | 1 | | dummy1 | 3 | 1 | | dummy2 | 3 | 1 | | vlan1 | 2 | 2 | | vlan2 | 2 | 2 | | bridge0 | 1 | 3 | If we then add macvlan0 on top of bridge0: macvlan0 | | bridge0 / | \ / | \ / | \ dummy0 vlan1 vlan2 | \ dummy1 dummy2 we can observe that __netdev_update_upper_level is only called for some of the devices under bridge0. I added a perf probe: # perf probe -a '__netdev_update_upper_level dev->name:string' which gets hit for bridge0 (called directly by __netdev_upper_dev_link) and then dummy0, vlan1, dummy1. It is never called for vlan2 and dummy2. After this, we have the following levels (*): | device | upper | lower | |----------+-------+-------| | dummy0 | 3 | 1 | | dummy1 | 4 | 1 | | dummy2 | 3 | 1 | | vlan1 | 3 | 2 | | vlan2 | 2 | 2 | | bridge0 | 2 | 3 | | macvlan0 | 1 | 4 | For dummy0, dummy1, vlan1, the upper level has increased by 1, as expected. For dummy2 and vlan2, it's still the same, which is wrong. (*) observed easily by adding another probe: # perf probe -a 'dev_get_stats dev->name:string dev->upper_level dev->lower_level' and running "ip link" Or you can just add prints and recompile, of course :) > + next = dev_stack[--cur]; > + niter = iter_stack[cur]; > + } > + > + now = next; > + iter = niter; > } > > return 0; -- Sabrina