Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp598007pxh; Tue, 9 Nov 2021 15:56:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJz0FX4OjpzDh1iAodybH7itVUIF4105o0H5JS1lseg+AOFkhStp0bwVB3qveJPjlSY27eVB X-Received: by 2002:a05:6638:3711:: with SMTP id k17mr4267797jav.72.1636502206179; Tue, 09 Nov 2021 15:56:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636502206; cv=none; d=google.com; s=arc-20160816; b=KAttwgMwZlRig1iFfhqJ4RcISfiYGCv93YVwwJz8UARnNTNDGQOVTtbNs/BewRQHV+ HwSVf0FwRSJ9Gtw0bHPGAvg89wObEyDMrsurWNaTp6rsp3D2Bhya0hW26vSfisKpUxEF pLZOoMMWhi9lJbhBlwF4CE0laicDhQL77tYxbW6b7u3rrwHzHCKYjqtbtQeEuykz8XYt ZAvQ+t8zkvLAWNdz5ApUHCoNSfS8w8xsxKaHXEQyVTSMYT77HlDaonAEpNOiOSyFixBx PtuQyScoSvio8IMskCzbDLAYph1aQG0JKUbCgNzDiNYlcngB4VG34kW7/8K76FUBW29V hqEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=LJ/12XJiox2wVjLAYn7FgJBoYA2lzGkbJ8FFfWaIXNY=; b=SjQV7fF0K7xiajRKoNuCVB6EpIYiuK90UTq6SiaPbPL53tR30sbR6O0VByBXVdnLqW bFTp7cTsKoksiG8luoi0/PlnN2NkkxPIr6Csqi2eQEMNloVO/cMfEDKuFkLrGVlXayU2 fNpFtnGaOYyUnQ0TDTTRyQMJXBZSWa2nKosaz/QXxP9/n+av28mcKxdXJysQ7893PLx0 8+FiO0RWt9qzHpXsAsjgAgxn2B+JNj5mRpo0KsC/9eNpg1gjmGYH292JjV1qzc2xfdxG YykG/3LGZQfwRHUy7PDfPxu1+9Zwmac5KQjtHp3cFGKM3DxOdggMi4VcwS0YXacxXQaA 5eQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IbPaYlwR; 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 b69si27948175jab.32.2021.11.09.15.56.29; Tue, 09 Nov 2021 15:56:46 -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=IbPaYlwR; 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 S238496AbhKIOdU (ORCPT + 97 others); Tue, 9 Nov 2021 09:33:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:55054 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238529AbhKIOdH (ORCPT ); Tue, 9 Nov 2021 09:33:07 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A838561105; Tue, 9 Nov 2021 14:30:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636468221; bh=9q1zcmzhKjwOsZPueYjISh0s622YSPmbrecA4DQ7LZ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IbPaYlwR/ZR/cXg16DmyV5/ffuOjcpQxsBVJ8ZtxSXvcsZh5I2AJsOHhw6MOqRbHe XLdCrPif9emkLsYzseab3busZDmhY/ha/0e6GrKU+iezgUyhwR33hLEGQ5LMo63g7J iHTaq7gmNY1iFCBH7OT0hfFv/NLu5p2arQlivzZ6AcoNy7bv8UTE5c/wIZMmSBRK2p 2uKZZfs0QSZS6tKOaZfJkfFnRseJfRwiVmLNjmojaWcCu5IQAmVf4RGfGWRaY6C5+L g3RIjv5LyhLeISFU9373FRB5ipaVK6QHd/ravvNZLrDMUaakOL+vAtUnNQWx8621Jk I6smsov4YVTGw== Date: Tue, 9 Nov 2021 16:30:16 +0200 From: Leon Romanovsky To: Jakub Kicinski Cc: Ido Schimmel , Jiri Pirko , "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: 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> <20211109061729.32f20616@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211109061729.32f20616@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 09, 2021 at 06:17:29AM -0800, Jakub Kicinski wrote: > On Tue, 9 Nov 2021 16:12:33 +0200 Leon Romanovsky wrote: > > > You'd need to tell me more about what the notifier is used for (I see > > > RoCE in the call trace). I don't understand why you need to re-register > > > a global (i.e. not per netns) notifier when devlink is switching name > > > spaces. > > > > RDMA subsystem supports two net namespace aware scenarios. > > > > We need global netdev_notifier for shared mode. This is legacy mode where > > we listen to all namespaces. We must support this mode otherwise we break > > whole RDMA world. > > > > See commit below: > > de641d74fb00 ("Revert "RDMA/mlx5: Fix devlink deadlock on net namespace deletion"") > > But why re-reg? To take advantage of clean event replay? > > IIUC the problem is that the un-reg is called from the reload_down path. This is how devlink reload was explained to me by Jiri. It suppose to unload and load whole driver again. In our case, it unloads mlx5_core, which destroys all ULPs (VDPA, RDMA, e.t.c) and these ULPs are not aware of devlink at all. Especially they are not aware of the reason of devlink reload. This is why I asked you. It is not related to devlink locking directly, but indirectly I didn't want to work on anything related to locking without making sure that devlink.c is correct. Thanks