Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp607050pxh; Tue, 9 Nov 2021 16:05:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJzwgj+SI9HctlfxV1Xtex04DzZVRqciuO/2CztOew+U14snPLiNzgmShz04d3S7T8WG4VLJ X-Received: by 2002:a05:6e02:1d02:: with SMTP id i2mr8454778ila.182.1636502740864; Tue, 09 Nov 2021 16:05:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636502740; cv=none; d=google.com; s=arc-20160816; b=OQnG0EWuXz+o1lWU06qhA2WD2CeiLZePfYGLX2OXnNWxSYD4c3K/HJP881gOn+odLS yzlXD8EtRx5lf4vbQZghMqTuMbrAeQeaUr83PTUA9+kFnBmBZ5pz9bUxI0oGvJAewYmy Zhtqxuk0rAxGD2voOIZI6efTe6RTfNhaTiUu79um5g88AxBvBBtvTVx/t4tC5zDV+GoW f6nHAb8lhm9+Tpkfj31ikQBB1PWkZfTX/PU491afqfpX2jIVjn/9WvYP1SUu44mCyFo+ TjxkI7k3OQymGMenCdKNGfw2wNn2Cplv6BSOXJw62q2/dookDNpbBONlf2sguowohnH3 uLPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=IuIxfosb66D2BAMrrAgzQzUorLl11dPwpIFE2JBIcqQ=; b=h4GvUwaiDnZnAyRZnA6CJVfOWbOGh829fRqX6IliXjR5OHRDz4kLpqDK+NvYfLARBy 22NAKUpi20qneFZVVFXE6lGwIiXrclU4UmV0+v7YaJh/1BZCxzbHqDx9Vl4dOSoO5DcF RCHio6fRq0JNWhpdJNYHQ1VIeGd3IVr5/2uC5QGLN5zYpkQ3/gpcNAydRz1IBv8pLZlm 8w6x7PcguWTavr+TS3zp5RF5xQI5qdrpeVHqbjtDN0xxZrBHR34HU7215cZvfFVVTow/ R3grNi4krDbpb7JlcxRNpjCc9b0OfdogkwVqUkJXIfrjPpqBT5fzGzWGG1eWSzxMz6+j CSxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SP9EdDjW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f1si14036237jaq.26.2021.11.09.16.05.27; Tue, 09 Nov 2021 16:05:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SP9EdDjW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239717AbhKIQ3j (ORCPT + 97 others); Tue, 9 Nov 2021 11:29:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:52798 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238397AbhKIQ3i (ORCPT ); Tue, 9 Nov 2021 11:29:38 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0D4D261251; Tue, 9 Nov 2021 16:26:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636475212; bh=SJd+CBR3hNdsEqv2/U4F2PEdGBxSNKt2Ee8Bu7IryJ8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SP9EdDjWkaoWtryXQxnAXLmrXpdzt5RSZu1RQZi8Ss78+Li6rDfqhDMaKqmNV9ZBV 8eGYuVymP8ejDsC10J/MDIsZpA84QsU1ZexaNrZ4JpJ7nRn5i7mR35ImQaB5eLqWyr sx5wlo8NvhKiyBm8WX8zmIpIWJAVZLWsBG+6358y7PbtzcL/PTOzoLM+C/a7WM3nf1 DpiHxr1JhIVj+blMNy5Dkx5RtXK+VXRo3nOnnMlQjDW6MU343ShYdoz3q7HPPWUSt7 sWob6X0Hh2U3dXmn6ivzeGtn2pOixXbnvrHO98SrEPBEMG8kO2nIljEg1RzXIcUVCb DR8ao8I9k7iOg== Date: Tue, 9 Nov 2021 08:26:48 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: Jason Gunthorpe , Leon Romanovsky , Ido Schimmel , "David S . Miller" , Jiri Pirko , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, edwin.peer@broadcom.com Subject: Re: [PATCH net-next] devlink: Require devlink lock during device reload Message-ID: <20211109082648.73092dfb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20211108080918.2214996c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20211108101646.0a4e5ca4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20211108104608.378c106e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20211108153126.1f3a8fe8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20211109144358.GA1824154@nvidia.com> <20211109070702.17364ec7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 9 Nov 2021 17:15:24 +0100 Jiri Pirko wrote: > Tue, Nov 09, 2021 at 04:07:02PM CET, kuba@kernel.org wrote: > >On Tue, 9 Nov 2021 10:43:58 -0400 Jason Gunthorpe wrote: > >> This becomes all entangled in the aux device stuff we did before. > > > >So entangled in fact that neither of you is willing to elucidate > >the exact need ;) > > > >> devlink reload is defined, for reasons unrelated to netns, to do a > >> complete restart of the aux devices below the devlink. This happens > >> necessarily during actual reconfiguration operations, for instance. > >> > >> So we have a situation, which seems like bad design, where reload is > >> also triggered by net namespace change that has nothing to do with > >> reconfiguring. > > > >Agreed, it is somewhat uncomfortable that the same callback achieves > >two things. As clear as the need for reload-for-reset is (reconfig, > >recovery etc.) I'm not as clear on reload for netns. > > > >The main use case for reload for netns is placing a VF in a namespace, > >for a container to use. Is that right? I've not seen use cases > >requiring the PF to be moved, are there any? > > > >devlink now lives in a networking namespace yet it spans such > >namespaces (thru global notifiers). I think we need to define what it > >means for devlink to live in a namespace. Is it just about the > >configuration / notification channel? Or do we expect proper isolation? > > > >Jiri? > > Well honestly the primary motivation was to be able to run smoothly with > syzkaller for which the "configuration / notification channel" is > enough. Hm. And syzkaller runs in a namespace? > By "proper isolation" you mean what exactly? For the devlink instance and all subordinate objects to be entirely contained to the namespace within which devlink resides, unless explicitly liked up with or delegated to another namespace.