From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB02AC00140 for ; Fri, 5 Aug 2022 19:58:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237622AbiHET6t (ORCPT ); Fri, 5 Aug 2022 15:58:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230437AbiHET6s (ORCPT ); Fri, 5 Aug 2022 15:58:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA0051E3C6 for ; Fri, 5 Aug 2022 12:58:47 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6F471B829E8 for ; Fri, 5 Aug 2022 19:58:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3C79C433D6; Fri, 5 Aug 2022 19:58:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659729525; bh=8GyTfo/xig9mMK2sKTW8FsWYFOVMiw67n94LpVCBjRs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jG8oY9LSLcUy9L6TocfNNZqv4RUqjwNBHo8CycP03P/M3sUUcl8Ng6iuQO+k8ZlvI byndK1IMUSs4xrEiIZVfvtmJWoHK93AGEteqOu7EDgomhmXzT6VZb76tcH8tegi2E2 IweOKcfvFFa32Z5QN6TYASE1PXwZa3VPyUh0+tVagaOMFHNI5QZwccQ3Lp3KHQ+t1D jZeX+SEh7uO1wIKMi6OdOi2Vt1NDGLzlpU8tIy0kW4+Q48efkD7xX45RMOAMYCdhug RRS1eFTYhImnvPC1GoCMldhgvXbM8wn+jAIq3eBAyVEkodZhjlPIkFMseoPHbLdk3J ww27E0+sUHncw== Date: Fri, 5 Aug 2022 12:58:43 -0700 From: Jakub Kicinski To: "Keller, Jacob E" Cc: Jiri Pirko , "netdev@vger.kernel.org" , "davem@davemloft.net" , "idosch@nvidia.com" , "petrm@nvidia.com" , "pabeni@redhat.com" , "edumazet@google.com" , "mlxsw@nvidia.com" , "saeedm@nvidia.com" , "tariqt@nvidia.com" , "leon@kernel.org" , "moshe@nvidia.com" Subject: Re: [patch net-next 2/4] net: devlink: convert reload command to take implicit devlink->lock Message-ID: <20220805125843.540fbc9c@kernel.org> In-Reply-To: References: <20220729071038.983101-1-jiri@resnulli.us> <20220729071038.983101-3-jiri@resnulli.us> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 5 Aug 2022 16:21:16 +0000 Keller, Jacob E wrote: > > Convert reload command to behave the same way as the rest of the > > commands and let if be called with devlink->lock held. Remove the > > temporary devl_lock taking from drivers. As the DEVLINK_NL_FLAG_NO_LOCK > > flag is no longer used, remove it alongside. > > > > Signed-off-by: Jiri Pirko > > Wasn't reload avoiding the lock done so that drivers could perform other devlink operations during reload? Or is that no longer a problem with the recent refactors done to move devlink initialization and such earlier so that its now safe? Drivers have control over the lock now, they can take the lock themselves (devl_lock()) and call the "I'm already holding the lock" functions. So the expectation is that shared paths used by probe and reload will always run under the lock.