From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E71EC10F13 for ; Tue, 16 Apr 2019 18:05:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 313D02063F for ; Tue, 16 Apr 2019 18:05:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="Ru1FrKFX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730268AbfDPSFE (ORCPT ); Tue, 16 Apr 2019 14:05:04 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:39221 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728809AbfDPSFE (ORCPT ); Tue, 16 Apr 2019 14:05:04 -0400 Received: by mail-qt1-f196.google.com with SMTP id t28so24379985qte.6 for ; Tue, 16 Apr 2019 11:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=Gib1a4vlM/rKy9tbpvf/hnFM51TKKB4Sls1B+ME5XfE=; b=Ru1FrKFXaQGmCEKF0SYnQfsOTHuLSywrQaMvMTe94lvoYT+okHCioym4i0bgDCQsqd siRNxr+aUHKaiQB4c+qK7r2hbFW7fZq0JBpgWLgI2Gxnjao1lOQ7sA2ZJYQZCP7Y+y9y qpsL6fOKlrMvKp6tUg2+30LPJJyeQI82n9lK2/AyC49bbxeMlN43jgA7gkhG0lgjdS2q Mw9I1Utymw4qYHQl610eiCcWMhYrW0XXsHysqGqzLIop8VPyD5NAxNHO100CHLH/+4Qa IsoAgYV+bVRnibiRfXZhel7fQ3KFgzZocaoc4moebOJk8AShpzqhvudoceUio45eFabw LZaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=Gib1a4vlM/rKy9tbpvf/hnFM51TKKB4Sls1B+ME5XfE=; b=F0ICxqrlKskLvmv1emOX2uCucGfozEO18O6nZDh0SxxhScbMdcuUCbZZyVNJlhV0t1 lozeRZoJU+lXfCgkItwlP2EqgUBXx6CujYhb2TEMNFLOdQssrlEAhTvk3IbTcAaVUGwE g+wQ/hVpU2glHuupxNfYsGcmPcuKKSrxmgtUeSnjYGbN4Bn8Z68z0Np3JUDwBaiOhMcf hVhsBwC8GwstgcRS2WntPGaqH+isENzsHgYPEWRkcs11mljl+mZnX+OThNbxAv8HN/ic a9r5tz5L8CkwX/trz1spXMAui35criqnLvsW7xBowldKuW2Z5mRLHcMon/0Bn9jLTSSU aicw== X-Gm-Message-State: APjAAAUgnm4buZDfbKltzyXJPfufVZdxKRs6WksKxTeb9cJkAHqOnoxi 2rWc0leOYksxeQ+w3IFqriChRg== X-Google-Smtp-Source: APXvYqxTknyjWK0y58OLti6BcIfRxQghtj5sJE77tB50xvJ1HvIwrJ8WMfSS47cKcShqb7oAMve94A== X-Received: by 2002:aed:3f49:: with SMTP id q9mr69443370qtf.279.1555437903458; Tue, 16 Apr 2019 11:05:03 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id w13sm33982403qtc.26.2019.04.16.11.05.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 11:05:03 -0700 (PDT) Date: Tue, 16 Apr 2019 11:04:59 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: netdev@vger.kernel.org, davem@davemloft.net, mlxsw@mellanox.com Subject: Re: [patch net-next rfc 00/15] netdevsim: impement proper device model Message-ID: <20190416110459.35b4b674@cakuba.netronome.com> In-Reply-To: <20190416085937.GC2122@nanopsycho> References: <20190413162112.8203-1-jiri@resnulli.us> <20190415122709.45dd4b09@cakuba.netronome.com> <20190416085937.GC2122@nanopsycho> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 16 Apr 2019 10:59:37 +0200, Jiri Pirko wrote: > >> 4) netdevsim instances are created by "ip link add" which is great for > >> soft devices with no hw backend. The rtnl core allocates netdev and > >> calls into driver holding rtnl mutex. For hw-backed devices, this > >> flow is wrong as it breaks order in which things are done. > >> > >> This patchset adjust netdevsim to fix all above. > >> > >> In order to support proper devlink and devlink port instances and to be > >> able to emulate real devices, there is need to implement bus probe and > >> instantiate everything from there. User can specify device id and port > >> count to be instantianted. For example: > >> > >> echo "10 4" > /sys/bus/netdevsim/new_device > > > >I really don't like the design where ID has to be allocated by user > >space. It's a step back. > > > >I also dislike declaring ports from the start. In real drivers ports > >are never "atomically" registered, they are crated and destroyed one > > Care to define "atomically" here? It is done in a very similar way > to how it is done in mlxsw for example. Same flows. > > > >by one, and a lot of races/UAFs/bugs lie in those small periods of > >time where one netdev got unregistered, but other are still around... > > Same here. Not sure where do you see the differences. The difference is that today I can do this: create a netdevsim1 with shared dev 1 create some state associated with shared dev 1 create a netdevsim2 with shared dev 1 check if all the shared dev 1 state created for netdevsim1 is visible via netdevsim2 destroy netdevsim1 check the shared dev 1 state again If I say "give me 2 ports" from the start, that makes the testing (which is the whole point of this code) harder. > Also, I plan to implement port splitting in follow-up patchset. All > flows are there as well. Sure, let's just be clear that we won't be merging an ABI that has just a netdevsim implementation, right? I have some reservations about the "port splitting" or device slicing, which should be discussed over real code, not netdevsim.