Received: by 10.192.165.156 with SMTP id m28csp1727227imm; Wed, 18 Apr 2018 14:54:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+vD7fbn/RLsfpI98VLY9zGCSAo1dVibPUdhOYrFBNm1jIl8xCBeW+Yh/SGci1/cJyj+7O9 X-Received: by 2002:a17:902:6986:: with SMTP id l6-v6mr3560180plk.209.1524088481311; Wed, 18 Apr 2018 14:54:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524088481; cv=none; d=google.com; s=arc-20160816; b=t8SKmWYUDHaMm40Nqy9V3K/JEK9nHuFc48taNjGm5v91hOwH5/nsRIaRlevg3gdx5J KgflEjX0og2HjPEJyCnP9FlHjb/nxo98OEj8oFjifXMuZD30JfQVeoFy4klYGm4nf3em F/DXMGBlB8omIhaXrWgHJ53xvt76ks+KHx3q1wQXLYmVi5B6FlXUnE5zPdXUZ+lQxJv1 jSogn/UBqkxd22ipKWjdqTeAffYDgil7GuFQ1y+8JlZO+HRlf142SgO21IALr2li7kDH 4SlmG9s4VYcpq+nVxBL+SbqJSm1QM1YRvdm/59VN6WcFpwTiNtwKZeTh1rrTLTjigsCF mdag== 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:date:from:arc-authentication-results; bh=+eEclzzJtwMtkKcvqJkBHpSBaTR5cbgt2cDjLpchEpw=; b=W9Ws3gsaFfu5Yye1e/5vKohd6K2x3Kil7y5OAD3fEl23ZZ6Js4u5ey3vNzkzDFVNl9 NYflfHLSLe21lsqG9e2rEBcOBIOl72Z5oB+OMyCW3XoM90bvCfCPliePLgYH4cdVmfsV n+9ge/R5Sp4cenLZIhvShJNCf2x85yKLyS4rNLpEy4TSCXDjAgoi/yGDTHP6wlx2Dtiu ZCqCwRVZ8PBDrW4dHH/jGT3KS61id+eHFm6ftctnZSxMmjuTp9hEREK1TOncRZin5s4v kDjjablnjZIn9rSdvb+K4wKwBFrF9Js6+o/7VInmPQW0MSZB22ZafFaFuIvYVc63leKW 8zJg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k12si1778106pgc.182.2018.04.18.14.54.27; Wed, 18 Apr 2018 14:54:41 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752810AbeDRVww (ORCPT + 99 others); Wed, 18 Apr 2018 17:52:52 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:40501 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752739AbeDRVwv (ORCPT ); Wed, 18 Apr 2018 17:52:51 -0400 Received: from mail-wr0-f198.google.com ([209.85.128.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1f8v0U-0001ld-6W for linux-kernel@vger.kernel.org; Wed, 18 Apr 2018 21:52:50 +0000 Received: by mail-wr0-f198.google.com with SMTP id u56-v6so2960347wrf.18 for ; Wed, 18 Apr 2018 14:52:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+eEclzzJtwMtkKcvqJkBHpSBaTR5cbgt2cDjLpchEpw=; b=dyirxKxXUCL9hf7D7HrmC5erAjqjyzRLFTtaU5rHTgFXUrvs+N24tGES26ve2b7FNR Y8v0W7Z3UqVZhAOhax76XgOhAjVQJ01+URtQY2Yh3aKDZKcCaFHfyw/LDnbr961GSGh1 zIvh46bYKpk8YYLBpGlxMCM/qx8O1Oh0D+b/hNh3NHtAT+9ANcYsZy3rXYMLXDQeUOvR p0lDKBGDhBJVW/kJ4lC5+vP9baEcjRnbIypVspW0UMLBnLWUlc07mFlknylOG912HJAS lVkUt/kJ3/lUifcJ1B/o/VIdjtXfe9B2X6n80ehivysWorccOaT0uApMMJbUE1jeMP1x lePQ== X-Gm-Message-State: ALQs6tCeMbh0vnXxWmCslBpcWbXLt0ItICYNZXk69QGYcNjpJVa0h8sZ zgwRJBwJ+zlTUufv+epxwnNYtM9QOLrX+DX7PLhp6Bo0mdQber0kmS+CKMJz5wcsE6JZe59M8vB PJ2HUQki5P8JrGdFbhyB6KAxVQE0xLtv4B0vtWHDfIA== X-Received: by 10.28.12.141 with SMTP id 135mr2666900wmm.99.1524088369553; Wed, 18 Apr 2018 14:52:49 -0700 (PDT) X-Received: by 10.28.12.141 with SMTP id 135mr2666894wmm.99.1524088369181; Wed, 18 Apr 2018 14:52:49 -0700 (PDT) Received: from gmail.com ([2a02:8070:8895:9700:8dd8:24eb:1ac1:f629]) by smtp.gmail.com with ESMTPSA id r200sm4480051wmb.39.2018.04.18.14.52.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Apr 2018 14:52:48 -0700 (PDT) From: Christian Brauner X-Google-Original-From: Christian Brauner Date: Wed, 18 Apr 2018 23:52:47 +0200 To: "Eric W. Biederman" Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, avagin@virtuozzo.com, ktkhai@virtuozzo.com, serge@hallyn.com, gregkh@linuxfoundation.org Subject: Re: [PATCH net-next 2/2] netns: isolate seqnums to use per-netns locks Message-ID: <20180418215246.GA24000@gmail.com> References: <20180418152106.18519-1-christian.brauner@ubuntu.com> <20180418152106.18519-3-christian.brauner@ubuntu.com> <874lk8wj1j.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <874lk8wj1j.fsf@xmission.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 18, 2018 at 11:55:52AM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > Now that it's possible to have a different set of uevents in different > > network namespaces, per-network namespace uevent sequence numbers are > > introduced. This increases performance as locking is now restricted to the > > network namespace affected by the uevent rather than locking > > everything. > > Numbers please. I personally expect that the netlink mc_list issues > will swamp any benefit you get from this. I wouldn't see how this would be the case. The gist of this is: Everytime you send a uevent into a network namespace *not* owned by init_user_ns you currently *have* to take mutex_lock(uevent_sock_list) effectively blocking the host from processing uevents even though - the uevent you're receiving might be totally different from the uevent that you're sending - the uevent socket of the non-init_user_ns owned network namespace isn't even recorded in the list. The other argument is that we now have properly isolated network namespaces wrt to uevents such that each netns can have its own set of uevents. This can either happen by a sufficiently privileged userspace process sending it uevents that are only dedicated to that specific netns. Or - and this *has been true for a long time* - because network devices are *properly namespaced*. Meaning a uevent for that network device is *tied to a network namespace*. For both cases the uevent sequence numbering will be absolutely misleading. For example, whenever you create e.g. a new veth device in a new network namespace it shouldn't be accounted against the initial network namespace but *only* against the network namespace that has that device added to it. Thanks! Christian