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 BB6E2C3A5A7 for ; Thu, 8 Dec 2022 16:35:49 +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=lx821cI59Hbld7gba5L+RS+J31rEiZx9WqXlP0FzavA=; b=P0oTat5Gw2lUAt Z6oG8gX13xCOewCWve/En0Zk2Lis6TLYcXH2cx9qWxRpKrtexIJ6MsW5vXkZTuS/Knzfrw5a7KWx8 pAQcxlB50JWZH+ccqGnzQ7wq492arLfmTUVRpwPnKE31YdqBuTqXFu6/JEM2Mx4QHLE71YJoEmBmK cZ32LCf3dr4uJ2/AzSuM1vHNQqLasO30lUp1mDs3u33S3Y4V5kD+ENwlVOSzAGBTQ7jKcpcFgtfn5 URMT2Ij0elWrmvU/V/ADf84LoRJhO7OcW+lL+rAJxFqV3BmQAnTfHdTZZX1Vnn9z6HrgcTBzWy4hG pNiLDjFpq3XTxYAPinrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p3Jr7-005Hwb-SN; Thu, 08 Dec 2022 16:34:42 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p3Jq7-005Gp4-VJ for linux-arm-kernel@lists.infradead.org; Thu, 08 Dec 2022 16:33:44 +0000 Received: by mail-ej1-x62b.google.com with SMTP id vp12so5307613ejc.8 for ; Thu, 08 Dec 2022 08:33:32 -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=yhbNyPOuSCL+eOhWqCHG2jF3hhtQ8hMilmeaJX3NeuQ=; b=wJoMZ12ql5XRyQ6imrHkXsS0EhUG1xqSGHS9Yz6sej0c681knXUR9eOdVmR/bdlDGU dUbU52yF8DmOXekGI8+Rm9DVZwa499RaXk/KHYFgU2pYCC4wlB4SGsokhb8851cqjF98 GJWsWDOKVKtaZZ/zKhkIw4WGeweqjlnnLPKV43rE2o/nYI4ek7iqM6VjpYbRC4s7dXaV FycNX6hieyRMLrl20geKvqoIo3/xcHspRU4QjhUkTRrU72gx+NxJv3G9UFOKtw64P5O7 LzXJwPD3d0oQhnjGnG2oafAnWizXHaZgqHVPh22XieRV314ZzEWv4tstfQ8K2mUaY1Zh +yhA== 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=yhbNyPOuSCL+eOhWqCHG2jF3hhtQ8hMilmeaJX3NeuQ=; b=NjIWBa5FVzmyPuVjOwyYH6oNWHI0341DzRQ6bjBKOSJzRnw3TbAkKZvqWTuTDJBYzk yx/4D5Gj4oedepBv+RVqi01n6ZlUI3Ls1fv8OP7zaSBz9heriR8GyXrP/sVAOSiia/Vc GBn0jza+Me27Xe5l++B20w3zkrMZBGHwwkwNY8QJGUbQQFui0ruFzRh/K3+KzGxdcvMJ Z6r45rZtckMziD1lxKZ/feCtF3iM6huHlc2YRPhF3vWczhD0WK2ihwzIVNnp3i7PbQYS Y7MlZP8ET+TpU2BnncGLDkx5YzIDR6+cv719tyZm/D9l+RL8TGfiQbCCi7WH3KvlDRO7 eB1w== X-Gm-Message-State: ANoB5pkdnZGlPBF/t04duqCJLi7nN9lNFAR5sWawrDhV3Gcg/x3ba5qY epGD5bEckxsERs3tiS5UNYTloA== X-Google-Smtp-Source: AA0mqf7/4lyR1JsE7IWetTnzdSSkURvlNoAPColT8k7GHxfHvnOsazhfqx0gseI5N7B3zFN0mpbzwQ== X-Received: by 2002:a17:906:7254:b0:7b9:a74b:f0d1 with SMTP id n20-20020a170906725400b007b9a74bf0d1mr2157358ejk.38.1670517210993; Thu, 08 Dec 2022 08:33:30 -0800 (PST) Received: from localhost (host-213-179-129-39.customer.m-online.net. [213.179.129.39]) by smtp.gmail.com with ESMTPSA id zh6-20020a170906880600b007c136bb8160sm68566ejb.71.2022.12.08.08.33.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 08:33:29 -0800 (PST) Date: Thu, 8 Dec 2022 17:33:28 +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: <20221202212206.3619bd5f@kernel.org> <20221205161933.663ea611@kernel.org> <20221206092705.108ded86@kernel.org> <20221207085941.3b56bc8c@kernel.org> <20221208081955.335ca36c@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221208081955.335ca36c@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221208_083340_046977_A556E411 X-CRM114-Status: GOOD ( 15.53 ) 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 Thu, Dec 08, 2022 at 05:19:55PM CET, kuba@kernel.org wrote: >On Thu, 8 Dec 2022 09:14:32 +0100 Jiri Pirko wrote: >> >Running DPLL control in a namespace / container. >> > >> >I mean - I generally think netns is overused, but yes, it's what >> >containers use, so I think someone may want to develop their >> >timer controller SW in as a container? >> >> The netdevices to control are already in the container. Isn't that >> enough? > >For DPLL config we need to delegate the permission. >So we'd need a "is net admin in namespace X" check, no? See below. > >> >> Thinking about it a bit more, DPLL itself has no network notion. The >> >> special case is SyncE pin, which is linked to netdevice. Just a small >> >> part of dpll device. And the netdevice already has notion of netns. >> >> Isn't that enough? >> > >> >So we can't use devlink or netdev. Hm. So what do we do? >> >Make DPLLs only visible in init_net? And require init_net admin? >> >And when someone comes asking we add an explicit "move to netns" >> >command to DPLL? >> >> Well, as I wrote. The only part needed to be network namespaced are the >> netdev related pins. And netdevices have netns support. So my question >> again, why is that not enough? > >For config which goes thru rtnl, yes, but we also need a caps check for: > >+ DPLL_CMD_DEVICE_SET, >+ DPLL_CMD_PIN_SET, 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. 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? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel