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 1D017C4332F for ; Mon, 12 Dec 2022 13:37:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232846AbiLLNh5 (ORCPT ); Mon, 12 Dec 2022 08:37:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232871AbiLLNh1 (ORCPT ); Mon, 12 Dec 2022 08:37:27 -0500 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67D8F5F5E for ; Mon, 12 Dec 2022 05:36:54 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id h16so3150731wrz.12 for ; Mon, 12 Dec 2022 05:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ItHz6t2ewO4AnHbrSJqvbUyq3yTnXlKp1R0Fb2eFkds=; b=N2O18U/7ySTvucEf23cqiCiMoo6yymhxiOdfsLFpMIFgk6WLdQebVN7kWzeF92iPPx qS1jbp91dpwVJU9qD7lWfOdvnyB1Z9zXgzFeQCbFVAwa8Scx0qeyPKmgO9sRQRrafypm 9bd628nG3AkihVYcVcrYySalHBoPwgESBSq+r7CHOl7nnjd165JNugNl17u+Fd0HISHI Tzf79Tl4ehrOCy36xXKEBwdVfGdLXMUjC3riORtfKG6FOQTIzvIJr7MXYF/9lrkw4d8C 5zXT6F4eEFMMsjRaPXfnA4RZsZBNDfvJbnc3GDaIyGLUbQtJG0U30JoNbigkqVmC0lpp okXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ItHz6t2ewO4AnHbrSJqvbUyq3yTnXlKp1R0Fb2eFkds=; b=YOizsM6GkhZShkU04hoLV8B5QPXEYWHcbJOjO6UbcGhCODI+Lmylj6HSITTiOI5iOZ VR9aG/LsEdo18WJLdFoYW78QO3RUwW/mDBGkqxXhwGh0jWVNVKx0/WZ4YD3Qhy0yagAZ LS1a4MRjDosm1W060BU2sNbMwqLKz6otvjkCInSapDUngXgreg9Ef/TKHK5yYwRvGpVD 9Z3hpc3eZf+I7Bw0Lc06ZoNpETZskwWekh61zGQjqCwZxIgWUlu6ayyDPJtY1XJYI175 nh6qx6HYm+ypKJNYp9BeRoG93S3npyKZblIEQViu+g6fGijuc+6q6jBuEi09YNxoVF7x biiQ== X-Gm-Message-State: ANoB5pkCKwRXDkZ1yqO9+Nm13MUKOeilu0fYgulI6WFHT21T51Lzy+ag La6MA93uCPT+Vp8dyXGMohdHPQ== X-Google-Smtp-Source: AA0mqf5ntngcCwZ7wE+zvEqGbMy3mZDegjmfiiJz2eOr5l/VJzQ14Lcfn8R1BgC9kCYQO1pZ9DbrMQ== X-Received: by 2002:a5d:4888:0:b0:232:be5c:ec7e with SMTP id g8-20020a5d4888000000b00232be5cec7emr10190798wrq.58.1670852212799; Mon, 12 Dec 2022 05:36:52 -0800 (PST) Received: from localhost (mail.chocen-mesto.cz. [85.163.43.2]) by smtp.gmail.com with ESMTPSA id z5-20020adff1c5000000b002258235bda3sm8944377wro.61.2022.12.12.05.36.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 05:36:51 -0800 (PST) Date: Mon, 12 Dec 2022 14:36:50 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: "Kubalewski, Arkadiusz" , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , "netdev@vger.kernel.org" , Vadim Fedorenko , linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, "Olech, Milena" , "Michalik, Michal" Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Message-ID: References: <20221206092705.108ded86@kernel.org> <20221207085941.3b56bc8c@kernel.org> <20221208081955.335ca36c@kernel.org> <20221208090517.643277e8@kernel.org> <20221209081942.565bc422@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221209081942.565bc422@kernel.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Fri, Dec 09, 2022 at 05:19:42PM CET, kuba@kernel.org wrote: >On Fri, 9 Dec 2022 10:29:53 +0100 Jiri Pirko wrote: >> Thu, Dec 08, 2022 at 06:05:17PM CET, kuba@kernel.org wrote: >> >On Thu, 8 Dec 2022 17:33:28 +0100 Jiri Pirko wrote: >> >> For any synce pin manipulation over dpll netlink, we can use the netns >> >> check of the linked netdev. This is the netns aware leg of the dpll, >> >> it should be checked for. >> > >> >The OCP card is an atomic clock, it does not have any networking. >> >> Sure, so why it has to be netns aware if it has nothing to do with >> networking? > >That's a larger question, IDK if broadening the scope of the discussion >will help us reach a conclusion. > >The patchset as is uses network namespaces for permissions: > >+ .flags = GENL_UNS_ADMIN_PERM, Yeah, I wonder if just GENL_ADMIN_PERM wuldn't be more suitable here... > >so that's what I'm commenting on - aligning visibility of objects with >already used permissions. > >> >> I can't imagine practically havind the whole dpll instance netns aware. >> >> Omitting the fact that it really has no meaning for non-synce pins, what >> >> would be the behaviour when for example pin 1 is in netns a, pin 2 in >> >> netns b and dpll itself in netns c? >> > >> >To be clear I don't think it's a bad idea in general, I've done >> >the same thing for my WIP PSP patches. But we already have one >> >device without netdevs, hence I thought maybe devlink. So maybe >> >we do the same thing with devlink? I mean - allow multiple devlink >> >instances to be linked and require caps on any of them? >> >> I read this 5 times, I'm lost, don't understand what you mean :/ > >Sorry I was replying to both paragraphs here, sorry. >What I thought you suggested is we scope the DPLL to whatever the >linked netdevs are scoped to? If netns has any of the netdevs attached >to the DPLL then it can see the DPLL and control it as well. Okay, that would make sense. GENL_UNS_ADMIN_PERM | GENL_UNS_ADMIN_PERM then. > >What I was saying is some DPLL have no netdevs. So we can do the same >thing with devlinks. Let the driver link the DPLL to one or more >devlink instances, and if any of the devlink instances is in current >netns then you can see the DPLL. I don't think that would be needed to pull devlink into the picture. If not netdev is linked to dpll, GENL_ADMIN_PERM would apply. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5F626C4332F for ; Mon, 12 Dec 2022 13:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=22cqYesBr0lmg1Wrq1OxpNS2yDPKROYIAWVbYUgDDEA=; b=HsDLpSN6TbXEuh kdtLUsWiLx+A73Cxkp1gpkBCVGL05upbIk67plASLz79Rt+twGBHHpTP1Ug86Ec4uPbqPrUMFjWLU mL3GsIHp7EOFHt8EhxJ9A45N9JntyMSUQKrpZpPHLg+hcAhg/7gkAzD2v6uuAlCM0PBbXUOhfnvC4 SMwWvBzqu5uF3Ep7ylNkpdGzFZFYxRgxVT/TW+lRsVlDvIP9degV73n9Guym5ZdHNW6Bom1jQiaSl tiO2P26PknW/nngejbipLcioggS0yaRZfpT1J8sz7w8a3P6girpUlIFV84WPMpbY8PEm97pcM2MZG AvKSHCJgWXuXKS0/YRCA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4izM-00GX3f-9I; Mon, 12 Dec 2022 13:37:00 +0000 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p4izI-00GWwP-HN for linux-arm-kernel@lists.infradead.org; Mon, 12 Dec 2022 13:36:59 +0000 Received: by mail-wr1-x431.google.com with SMTP id h12so12088921wrv.10 for ; Mon, 12 Dec 2022 05:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ItHz6t2ewO4AnHbrSJqvbUyq3yTnXlKp1R0Fb2eFkds=; b=N2O18U/7ySTvucEf23cqiCiMoo6yymhxiOdfsLFpMIFgk6WLdQebVN7kWzeF92iPPx qS1jbp91dpwVJU9qD7lWfOdvnyB1Z9zXgzFeQCbFVAwa8Scx0qeyPKmgO9sRQRrafypm 9bd628nG3AkihVYcVcrYySalHBoPwgESBSq+r7CHOl7nnjd165JNugNl17u+Fd0HISHI Tzf79Tl4ehrOCy36xXKEBwdVfGdLXMUjC3riORtfKG6FOQTIzvIJr7MXYF/9lrkw4d8C 5zXT6F4eEFMMsjRaPXfnA4RZsZBNDfvJbnc3GDaIyGLUbQtJG0U30JoNbigkqVmC0lpp okXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ItHz6t2ewO4AnHbrSJqvbUyq3yTnXlKp1R0Fb2eFkds=; b=KAAkH90IHhg7ZE/9ve1/tVGKjTAOOx3vbHTkDdsMiij87heIPEwar5uIZDKfjGUg/2 iMtMlUTuX9/904/H206G2X4uN28kMvOL2Q7ub8t7D8ht1QnEViDibkW65JwJVWsW6LdV yzbqaSskN6YRrDd4Pg2rj3ZHWuD/1S7JjBTSZ2Yq/L5s7Cq27xv3yKy3BowHwI2DKBRk 5PsT9zF9yi6MMSEhA1NnlzXaIeRipsHyuG5PLrnO09ig8DJoBQB+WdmX4hQ3+FAYUmoQ BTkID3Olx7HSym+bgxOchNCE5Bkk8SAOX3UYOmcqfa+mMzzZskA+1jKGKtpe40Ju3KqW I+fg== X-Gm-Message-State: ANoB5pnVlI9nYDgKEcixltcSB0eeJ63OQaAbul05Ubq99apKC6mSb/cX sVJIAMNy8QziRTfYgB0SXLtzNg== X-Google-Smtp-Source: AA0mqf5ntngcCwZ7wE+zvEqGbMy3mZDegjmfiiJz2eOr5l/VJzQ14Lcfn8R1BgC9kCYQO1pZ9DbrMQ== X-Received: by 2002:a5d:4888:0:b0:232:be5c:ec7e with SMTP id g8-20020a5d4888000000b00232be5cec7emr10190798wrq.58.1670852212799; Mon, 12 Dec 2022 05:36:52 -0800 (PST) Received: from localhost (mail.chocen-mesto.cz. [85.163.43.2]) by smtp.gmail.com with ESMTPSA id z5-20020adff1c5000000b002258235bda3sm8944377wro.61.2022.12.12.05.36.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 05:36:51 -0800 (PST) Date: Mon, 12 Dec 2022 14:36:50 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: "Kubalewski, Arkadiusz" , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , "netdev@vger.kernel.org" , Vadim Fedorenko , linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, "Olech, Milena" , "Michalik, Michal" Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Message-ID: References: <20221206092705.108ded86@kernel.org> <20221207085941.3b56bc8c@kernel.org> <20221208081955.335ca36c@kernel.org> <20221208090517.643277e8@kernel.org> <20221209081942.565bc422@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221209081942.565bc422@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221212_053656_846614_8D49CA1E X-CRM114-Status: GOOD ( 22.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Fri, Dec 09, 2022 at 05:19:42PM CET, kuba@kernel.org wrote: >On Fri, 9 Dec 2022 10:29:53 +0100 Jiri Pirko wrote: >> Thu, Dec 08, 2022 at 06:05:17PM CET, kuba@kernel.org wrote: >> >On Thu, 8 Dec 2022 17:33:28 +0100 Jiri Pirko wrote: >> >> For any synce pin manipulation over dpll netlink, we can use the netns >> >> check of the linked netdev. This is the netns aware leg of the dpll, >> >> it should be checked for. >> > >> >The OCP card is an atomic clock, it does not have any networking. >> >> Sure, so why it has to be netns aware if it has nothing to do with >> networking? > >That's a larger question, IDK if broadening the scope of the discussion >will help us reach a conclusion. > >The patchset as is uses network namespaces for permissions: > >+ .flags = GENL_UNS_ADMIN_PERM, Yeah, I wonder if just GENL_ADMIN_PERM wuldn't be more suitable here... > >so that's what I'm commenting on - aligning visibility of objects with >already used permissions. > >> >> I can't imagine practically havind the whole dpll instance netns aware. >> >> Omitting the fact that it really has no meaning for non-synce pins, what >> >> would be the behaviour when for example pin 1 is in netns a, pin 2 in >> >> netns b and dpll itself in netns c? >> > >> >To be clear I don't think it's a bad idea in general, I've done >> >the same thing for my WIP PSP patches. But we already have one >> >device without netdevs, hence I thought maybe devlink. So maybe >> >we do the same thing with devlink? I mean - allow multiple devlink >> >instances to be linked and require caps on any of them? >> >> I read this 5 times, I'm lost, don't understand what you mean :/ > >Sorry I was replying to both paragraphs here, sorry. >What I thought you suggested is we scope the DPLL to whatever the >linked netdevs are scoped to? If netns has any of the netdevs attached >to the DPLL then it can see the DPLL and control it as well. Okay, that would make sense. GENL_UNS_ADMIN_PERM | GENL_UNS_ADMIN_PERM then. > >What I was saying is some DPLL have no netdevs. So we can do the same >thing with devlinks. Let the driver link the DPLL to one or more >devlink instances, and if any of the devlink instances is in current >netns then you can see the DPLL. I don't think that would be needed to pull devlink into the picture. If not netdev is linked to dpll, GENL_ADMIN_PERM would apply. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel