Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp5590592ybn; Sun, 29 Sep 2019 01:32:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMFUErQrkOI/Pq9IU+Ox/0q6bJYdSglRgkZFICo02cbFtnwOm7I8dK8tl+msm5VjdS46Kf X-Received: by 2002:a50:8961:: with SMTP id f30mr13176932edf.144.1569745946760; Sun, 29 Sep 2019 01:32:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569745946; cv=none; d=google.com; s=arc-20160816; b=B7ROOoPPQXq0VhVFbu23eyk8sCuMUm+9Gbe9fLfeKDRyrHniaCkXxaAIsvRfFcpijK ZynzH1CHm0g+FjhPDuW/emzUaNXH/i5Yne7rZvbRMoAcsImRQVlIWGl/gJZafCrRxE1C ZeCSgQGshpGd6+qErwHY36jUWU5aVfh14wa59i1QHvb3qk6QtQEb7WYG7Q+zVATJ80jy 41OwpBcJLKIFQ1n4udxoln2jF3GD4FxVLKnAycAQKh125JdNWJD0ol8MZ7up8scVsuQh dF9m562W7t2wXvZjOw5RZ6zXfVGxxDnaaUbQEi7uYOS9+Hcp7Mp1AXR7JZn1FFlHg6iG n4Zw== 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=Kdg/X1gRFWrRcjXeopdKgWFJCbdlHG/7tw/5ynKD8NM=; b=NCCi17cSsyCWrCfbMHCDxJW0kqpIjFxQZwm/+fEgrp9oCED2soCmL5tbVJPA/77Rdl jq6ot+Mitgvo2PeKgHOtmCCreiab7Jifd3P16tsQIhcSl8QA8S8XNbGnfqCiHkgreM83 /fpwOs+KEczM+7cIPUgbvPnwZRLgcwMm0NBYpoQUPvhlvXt1sw+G4dQD2H1IKypVy4gc e0c1BFIULRRUz7Cbl7Xmhn1dzEQUq44BvXfAjeMLWj3xc+D0cuxaJb4bd5s5ZukaVxiE WQ0oIoEoLWnpwa+UvER8T30BHYtdb4XTk5Ax53q0/Og6EiJOy+855SreC5oSCaSU9OVC vPsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KBpWBZhA; 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 x45si4829088edd.388.2019.09.29.01.31.45; Sun, 29 Sep 2019 01:32:26 -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=KBpWBZhA; 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 S1726198AbfI2Ib3 (ORCPT + 99 others); Sun, 29 Sep 2019 04:31:29 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:35299 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbfI2Ib3 (ORCPT ); Sun, 29 Sep 2019 04:31:29 -0400 Received: by mail-lj1-f193.google.com with SMTP id m7so6386148lji.2; Sun, 29 Sep 2019 01:31:27 -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=Kdg/X1gRFWrRcjXeopdKgWFJCbdlHG/7tw/5ynKD8NM=; b=KBpWBZhA1HI60TphaSFN6NGXpCo5zpNdI/H7EbzP/LwfDtiT2s60gNgxvzvugOmmc1 rDcWLBhA4qRzeIB/UYr1/GrwgBfjcu/i5jWoHVowEDHUWEnCT2ZXgwzI2QuT/8ps1WBP N6FF3sIgdpHxsZu/heA4MRrhKuzXsIK5AMld4kBiBTP52FG+tKRzuWTcs600ICS5juJ3 hjngsvQLw15YDCiU9SGpxM1+xAeyqfhppKOEvoiuFJZtaNrNCdREpt/nybHbyASFPmPF bSuRzoOxulQ0jSx8/8Q6j0miQt1LpXNsfHwCxuoua1TxAkNPKCuDNc7vzI36F7xejfgS 2UCg== 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=Kdg/X1gRFWrRcjXeopdKgWFJCbdlHG/7tw/5ynKD8NM=; b=UAMI+4adBEKIWZobJY0+Js/tGKEPHn1rYAZYhU/hxrTFoBfid7ejdC7iifLiu6D/1M Apa4p5IvBzL5icFySr640J+OjKHbBFVpf7pqL9lIIJAjSB4sgayTmN5bnbNaBanAkAaq /POJuh5681boEInH8tO/cRdY4HoM/VROwVEgS8HNmMaLh6/HTsWNxt5+UKc1uOzKnSEd 863OrvzusIa9Dj0uvwWkl30307aFTmmsjh4gBgXzSnOoE920bre9UhxQUwxsaB2L9lQu snUskq6JSdTxQmD3rWO+o5qVJOmwMw5GiC3YDjx6ndP+euxE7PCjkcv+Kh5mst9DQCbV jOcQ== X-Gm-Message-State: APjAAAX8ozosFYjr0kbl+gVu2UwzrooiEdB9M325qeOmkX25O92TVhVM XJtineTraZps63eYthH2+GTkDZsc2WrDzEP8Lc4= X-Received: by 2002:a2e:8616:: with SMTP id a22mr2921297lji.6.1569745886863; Sun, 29 Sep 2019 01:31:26 -0700 (PDT) MIME-Version: 1.0 References: <20190928164843.31800-1-ap420073@gmail.com> <2e836018c7ea299037d732e5138ca395bd1ae50f.camel@sipsolutions.net> In-Reply-To: <2e836018c7ea299037d732e5138ca395bd1ae50f.camel@sipsolutions.net> From: Taehee Yoo Date: Sun, 29 Sep 2019 17:31:15 +0900 Message-ID: Subject: Re: [PATCH net v4 00/12] net: fix nested device bugs 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==?= , sd@queasysnail.net, 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 Sun, 29 Sep 2019 at 04:20, Johannes Berg wrote: > > > > VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI and VXLAN. > > But I couldn't test all interface types so there could be more device > > types which have similar problems. > > Did you test virt_wifi? I don't see how it *doesn't* have the nesting > problem, and you didn't change it? > > No, I see. You're limiting the nesting generally now in patch 1, and the > others are just lockdep fixups (I guess it's surprising virt_wifi > doesn't do this at all?). virt_wifi case is a little bit different case. I add the last patch that is to fix refcnt leaks in the virt_wifi module. The way to fix this is to add notifier routine. The notifier routine could delete lower device before deleting virt_wifi device. If virt_wifi devices are nested, notifier would work recursively. At that time, it would make stack memory overflow. Actually, before this patch, virt_wifi doesn't have the same problem. So, I will update a comment in a v5 patch. > > FWIW I don't think virt_wifi really benefits at all from stacking, so we > could just do something like > > --- a/drivers/net/wireless/virt_wifi.c > +++ b/drivers/net/wireless/virt_wifi.c > @@ -508,6 +508,9 @@ static int virt_wifi_newlink(struct net *src_net, struct net_device *dev, > else if (dev->mtu > priv->lowerdev->mtu) > return -EINVAL; > > + if (priv->lowerdev->ieee80211_ptr) > + return -EINVAL; > + > err = netdev_rx_handler_register(priv->lowerdev, virt_wifi_rx_handler, > priv); > if (err) { > Many other devices use this way to avoid wrong nesting configuration. And I think it's a good way. But we should think about the below configuration. vlan5 | virt_wifi4 | vlan3 | virt_wifi2 | vlan1 | dummy0 That code wouldn't avoid this configuration. And all devices couldn't avoid this config. I have been considering this case, but I couldn't make a decision yet. Maybe common netdev function is needed to find the same device type in their graph. > > > IMHO, but of course generally limiting the stack depth is needed anyway > and solves the problem well enough for virt_wifi. > > This is a little bit different question for you. I found another bug in virt_wifi after my last patch. Please test below commands ip link add dummy0 type dummy ip link add vw1 link dummy0 type virt_wifi ip link add vw2 link vw1 type virt_wifi modprobe -rv virt_wifi Then, you can see the warning messages. If SET_NETDEV_DEV() is deleted in the virt_wifi_newlink(), you can avoid that warning message. But I'm not sure about it's safe to remove that. I would really appreciate it if you let me know about that. > johannes >