Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp268162pxb; Mon, 8 Nov 2021 13:19:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQzI1lDkdV2VDthhIsNOONgLV5oYuUfHkFv/SoUMnL/aHZY+V+fpgd0XmgWzfhMDSE9f8G X-Received: by 2002:a17:907:86a6:: with SMTP id qa38mr2762815ejc.286.1636406389276; Mon, 08 Nov 2021 13:19:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636406389; cv=none; d=google.com; s=arc-20160816; b=ejX1Kbexg85Upp+NoDIyfW06DchDo3gRJfkANPlyr2ozsAS5G4YvdIqDVo4yDDlk2z MMccZKZ410QiPr93ty1SW4P5VhkFNjbLdD5nDsFFwBg9/MdbBA9beTnSkkqSba5Atlc3 XN8SE3oHE6YPbNI+QN/XsLJJteJDc8W90WtLxNc5lQqWFX6ngDNXaOUf3wWqLDQ+XrkP Mwx7YRg4ZCsJWOovK6Ll2BdclilxHLf/+qTVWb/0RY5cfMcDugTUhf6WdTpNxcMRxy5y OeQlFdFtMYw6drId06fhxIVnu1Z3iluPm3Vvw3pOdmO0rVsL091P7D500g46QWnT3fw9 Jcpw== 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=LD+zpqDYmHKdFmvm/8/VErCeXLkD3kmILeqUJSuBUx8=; b=nbgx6BkglPusdbnKgJBN+9sxExVSBfIplnEFQjqUzCDdvE9fHFu3j3p0+jEN1Ukldl HlLJqgK1CycU9gYea691Amrh0mH1ts2cRn0bzfgjiGb4xSZr5W0DASvAJSvZj7ewm9eO 5dN9HNu7ybxvlWftxniQKzOnh4uImkpC0zFeA7Z0nWVFA8aew33Dlmf9F2D5pC2iv9ax gLttj7S4Yoe36THWNuMMdgt4Mke51I3pLQbbN8QKOUJgRHpxURSCBUJsQGl5FFx4FJHl e8Lteg1I2IuDq5wgHcJm6M+NyYRm+mNu15Of8C9BEXJcW/qZhaoxYFQScof5sZmUEn53 NlGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZCLj7zfW; 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 n1si10271212ejy.152.2021.11.08.13.19.21; Mon, 08 Nov 2021 13:19:49 -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=ZCLj7zfW; 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 S241189AbhKHQMF (ORCPT + 99 others); Mon, 8 Nov 2021 11:12:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:56556 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236099AbhKHQME (ORCPT ); Mon, 8 Nov 2021 11:12:04 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id D052761038; Mon, 8 Nov 2021 16:09:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636387760; bh=7CNd4po5W6zKOYXmUQ878mG5xFvVcTmoqKd54bOk1r0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZCLj7zfW+rzumbTsnoFv2Y2/ZOX2pdyesCg3TT8ruFXHBiyx0sfbVWSxiAbEBag7M rv99zogpjQq6s8Fmb4G6/r+k463yGaYR3HpACbj13x3fR5nACjA5OVUdNlWbX+443J 5aZ1KOSFwY33NFX/95Fej58yhvxt0bxzAjT+nGqBIb3UxnEjvB050HSgIJfYLwmzRO WUKoO0WYpAabuhuKK0aHL1e+NL7v2gwkEUhXb0ezJr74B+qtZZK47HSzsx394isoYM q9CjJivL+sUNLNuFEimRtQkjiW/REgF/mgKhbY9tf1rnZ0GY1dfbSWvB6iBGSGi6x+ BlbJ2DcP3du6A== Date: Mon, 8 Nov 2021 08:09:18 -0800 From: Jakub Kicinski To: Leon Romanovsky 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: <20211108080918.2214996c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <9716f9a13e217a0a163b745b6e92e02d40973d2c.1635701665.git.leonro@nvidia.com> <20211101161122.37fbb99d@kicinski-fedora-PC1C0HJN> 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 Sun, 7 Nov 2021 19:54:20 +0200 Leon Romanovsky wrote: > > > (3) should we let drivers take refs on the devlink instance? > > > > I think it's fine mainly because I don't expect it to be used by too > > many drivers other than netdevsim which is somewhat special. Looking at > > the call sites of devlink_get() in netdevsim, it is only called from > > places (debugfs and trap workqueue) that shouldn't be present in real > > drivers. > > Sorry, I'm obligated to ask. In which universe is it ok to create new > set of API that no real driver should use? I think it's common sense. We're just exporting something to make our lives easier somewhere else in the three. Do you see a way in which taking refs on devlink can help out-of-tree code? BTW we can put the symbols in a namespace or under a kconfig, to aid reviews of drivers using them if you want.