From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BD933AD530; Wed, 10 Jun 2026 23:50:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781135457; cv=none; b=samSJ/r2/GLWxVwJ3RAnRVssZQlHVrXEfK1PWJrcEk+2I9rLovs9BUboh19ojoF7nVhzl+2qWQ0I9pVE+sXA3pPb4yCrrrblMO2ljXVYsPmuwEDF87vX8v89uG32AqjA1SAWpDXbFjnDcaJ5wxZfhzBwVQdVV0H5Qytha4oP9h0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781135457; c=relaxed/simple; bh=VCPr7vNvhwuT/yFe1XKZ6Qgugjig7kQLgSPsezMk/UY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IF3Adq7TIvTACAGehmwTdVwkbWYgsgf9pzNBbKcqj/ZHH2yGM1te86t+k9uggPrQ+UDgXvAwNy8xkVEa5HhzKc1FuRAsfFBhdhF1kqXvaHtzU2/q82q/elYSlQzI2qD1AW0PJjwTDfn0Xh/PAfT/bdiO1IKSv6+eiose4oZqUY0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LgGCi5Wm; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LgGCi5Wm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB00D1F00893; Wed, 10 Jun 2026 23:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781135455; bh=Bs6lNz+jJWV9xj+ISloEfiMNZ8rp01tNUsy4Sa60C90=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LgGCi5WmWS8TksM65LNLqsVYlH30veeq+QBsKlq/kbUGRM7tq+F2Z3l0MNYouX3od jCn/XG7Oc7oyPe4xRqGgFypvKSObhGbeG1Vv5ydm55rO+7RZ+SwBfeeuiyLwNut6k5 Ta+gA21JfeZUdZwc+V/uilghwZhASIKMEDtbAZU/uyIFoKCaqz+4abVV06Q00c8Gg/ wJpvm/dwIY3Dm2HJ+wycd0bx8gOKqeGgkYWWPftXkHsHzTfKSVk+5m6f+FcaqeTjcs BMiUPSqEtJEcGA5hGBthLAG5sCWYolIUrtKET702Y7PcxO4zcoGn1TDHYulsuwxdqJ +ozQhyCEcb5Yg== Date: Wed, 10 Jun 2026 16:50:53 -0700 From: Jakub Kicinski To: Mark Bloch Cc: Eric Dumazet , Paolo Abeni , Andrew Lunn , "David S. Miller" , Jonathan Corbet , Shuah Khan , Jiri Pirko , Simon Horman , Sunil Goutham , Linu Cherian , Geetha sowjanya , hariprasad , Subbaraya Sundeep , Bharat Bhushan , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Ethan Nelson-Moore , , , Subject: Re: [PATCH net-next V3 2/7] netdevsim: Register devlink after device init Message-ID: <20260610165053.7c91f331@kernel.org> In-Reply-To: <20260605181030.3486619-3-mbloch@nvidia.com> References: <20260605181030.3486619-1-mbloch@nvidia.com> <20260605181030.3486619-3-mbloch@nvidia.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 5 Jun 2026 21:10:25 +0300 Mark Bloch wrote: > devl_register() makes the devlink instance visible to userspace. A later > patch also makes registration the point where devlink core may call > eswitch_mode_set() to apply a boot-time default eswitch mode. > > Move netdevsim registration after all objects (resources, params, regions, > traps, debugfs etc) are initialized, and after the initial eswitch mode is > set to legacy. > > Move devl_unregister() to the beginning of nsim_drv_remove(), before those > devlink objects are torn down. This keeps devlink register/unregister as > the notification barrier and makes the later object teardown paths run > after devlink is no longer registered, so they do not emit their own > netlink DEL notifications. This is going backwards. At some point someone from nVidia thought that we can order our way out of locking, so mlx5 is likely ordered this way, but this must not be required, or in any way normalized. We (syzbot) quickly discovered that it doesn't cover all corner cases. devl_lock() is exposed specifically to allow the driver to finish whatever init it needs without letting user space invoke callbacks, yet. Almost (?) all driver callbacks hold devl_lock(), so maybe the devlink instance is "visible" to user space but that should not matter.