From: Jiri Pirko <jiri@resnulli.us> To: Jakub Kicinski <kuba@kernel.org> Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>, Vadim Fedorenko <vfedorenko@novek.ru>, Jonathan Lemon <jonathan.lemon@gmail.com>, Paolo Abeni <pabeni@redhat.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Vadim Fedorenko <vadfed@fb.com>, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, "Olech, Milena" <milena.olech@intel.com>, "Michalik, Michal" <michal.michalik@intel.com> Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Date: Thu, 8 Dec 2022 17:33:28 +0100 [thread overview] Message-ID: <Y5IR2MzXfqgFXGHW@nanopsycho> (raw) In-Reply-To: <20221208081955.335ca36c@kernel.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?
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us> To: Jakub Kicinski <kuba@kernel.org> Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>, Vadim Fedorenko <vfedorenko@novek.ru>, Jonathan Lemon <jonathan.lemon@gmail.com>, Paolo Abeni <pabeni@redhat.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Vadim Fedorenko <vadfed@fb.com>, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, "Olech, Milena" <milena.olech@intel.com>, "Michalik, Michal" <michal.michalik@intel.com> Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Date: Thu, 8 Dec 2022 17:33:28 +0100 [thread overview] Message-ID: <Y5IR2MzXfqgFXGHW@nanopsycho> (raw) In-Reply-To: <20221208081955.335ca36c@kernel.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
next prev parent reply other threads:[~2022-12-08 16:33 UTC|newest] Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-29 21:37 [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-29 21:37 ` [RFC PATCH v4 1/4] dpll: add dpll_attr/dpll_pin_attr helper classes Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-29 21:37 ` [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-30 15:21 ` Jiri Pirko 2022-11-30 15:21 ` Jiri Pirko 2022-11-30 16:23 ` Jiri Pirko 2022-11-30 16:23 ` Jiri Pirko 2022-12-23 16:45 ` Kubalewski, Arkadiusz 2022-12-23 16:45 ` Kubalewski, Arkadiusz 2023-01-02 12:28 ` Jiri Pirko 2023-01-02 12:28 ` Jiri Pirko 2022-11-30 16:37 ` Jiri Pirko 2022-11-30 16:37 ` Jiri Pirko 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 12:39 ` Jiri Pirko 2022-12-02 12:39 ` Jiri Pirko 2022-12-02 14:54 ` Kubalewski, Arkadiusz 2022-12-02 14:54 ` Kubalewski, Arkadiusz 2022-12-02 16:15 ` Jiri Pirko 2022-12-02 16:15 ` Jiri Pirko [not found] ` <20221202212206.3619bd5f@kernel.org> 2022-12-05 10:32 ` Jiri Pirko 2022-12-05 10:32 ` Jiri Pirko 2022-12-06 0:19 ` Jakub Kicinski 2022-12-06 0:19 ` Jakub Kicinski 2022-12-06 8:50 ` Jiri Pirko 2022-12-06 8:50 ` Jiri Pirko 2022-12-06 17:27 ` Jakub Kicinski 2022-12-06 17:27 ` Jakub Kicinski 2022-12-07 13:10 ` Jiri Pirko 2022-12-07 13:10 ` Jiri Pirko 2022-12-07 16:59 ` Jakub Kicinski 2022-12-07 16:59 ` Jakub Kicinski 2022-12-08 8:14 ` Jiri Pirko 2022-12-08 8:14 ` Jiri Pirko 2022-12-08 16:19 ` Jakub Kicinski 2022-12-08 16:19 ` Jakub Kicinski 2022-12-08 16:33 ` Jiri Pirko [this message] 2022-12-08 16:33 ` Jiri Pirko 2022-12-08 17:05 ` Jakub Kicinski 2022-12-08 17:05 ` Jakub Kicinski 2022-12-09 9:29 ` Jiri Pirko 2022-12-09 9:29 ` Jiri Pirko 2022-12-09 16:19 ` Jakub Kicinski 2022-12-09 16:19 ` Jakub Kicinski 2022-12-12 13:36 ` Jiri Pirko 2022-12-12 13:36 ` Jiri Pirko 2022-12-13 18:08 ` Kubalewski, Arkadiusz 2022-12-13 18:08 ` Kubalewski, Arkadiusz 2022-12-14 7:32 ` Jiri Pirko 2022-12-14 7:32 ` Jiri Pirko 2022-11-29 21:37 ` [RFC PATCH v4 3/4] dpll: documentation on DPLL subsystem interface Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-12-02 12:43 ` kernel test robot 2022-12-19 9:13 ` Paolo Abeni 2022-12-19 9:13 ` Paolo Abeni 2023-01-12 13:45 ` Kubalewski, Arkadiusz 2023-01-12 13:45 ` Kubalewski, Arkadiusz 2022-11-29 21:37 ` [RFC PATCH v4 4/4] ptp_ocp: implement DPLL ops Vadim Fedorenko 2022-11-29 21:37 ` Vadim Fedorenko 2022-11-30 8:30 ` kernel test robot 2022-11-30 12:41 ` Jiri Pirko 2022-11-30 12:41 ` Jiri Pirko 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 12:48 ` Jiri Pirko 2022-12-02 12:48 ` Jiri Pirko 2022-12-02 14:39 ` Kubalewski, Arkadiusz 2022-12-02 14:39 ` Kubalewski, Arkadiusz 2022-12-02 16:20 ` Jiri Pirko 2022-12-02 16:20 ` Jiri Pirko 2022-12-08 0:35 ` Kubalewski, Arkadiusz 2022-12-08 0:35 ` Kubalewski, Arkadiusz 2022-12-08 8:19 ` Jiri Pirko 2022-12-08 8:19 ` Jiri Pirko 2022-12-07 2:33 ` Jakub Kicinski 2022-12-07 2:33 ` Jakub Kicinski 2022-12-07 13:19 ` Jiri Pirko 2022-12-07 13:19 ` Jiri Pirko [not found] ` <20221207090524.3f562eeb@kernel.org> 2022-12-08 11:22 ` Jiri Pirko 2022-12-09 0:36 ` Jakub Kicinski 2022-12-09 9:32 ` Jiri Pirko 2022-11-30 12:32 ` [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Jiri Pirko 2022-11-30 12:32 ` Jiri Pirko 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 11:27 ` Kubalewski, Arkadiusz 2022-12-02 16:12 ` Jiri Pirko 2022-12-02 16:12 ` Jiri Pirko 2022-12-07 2:47 ` Jakub Kicinski 2022-12-07 2:47 ` Jakub Kicinski 2022-12-07 14:09 ` netdev.dump 2022-12-07 14:09 ` netdev.dump 2022-12-07 23:21 ` Jakub Kicinski 2022-12-07 23:21 ` Jakub Kicinski 2022-12-08 11:28 ` Jiri Pirko 2022-12-08 11:28 ` Jiri Pirko 2022-12-09 0:39 ` Jakub Kicinski 2022-12-09 0:39 ` Jakub Kicinski 2022-12-09 0:56 ` Kubalewski, Arkadiusz 2022-12-09 0:56 ` Kubalewski, Arkadiusz 2022-12-08 18:08 ` Maciek Machnikowski 2022-12-08 18:08 ` Maciek Machnikowski 2022-12-09 11:07 ` Jiri Pirko 2022-12-09 11:07 ` Jiri Pirko 2022-12-09 14:09 ` Maciek Machnikowski 2022-12-09 14:09 ` Maciek Machnikowski 2022-12-09 16:31 ` Jakub Kicinski 2022-12-09 16:31 ` Jakub Kicinski 2022-12-09 17:11 ` Maciek Machnikowski 2022-12-09 17:11 ` Maciek Machnikowski 2022-12-12 13:58 ` Jiri Pirko 2022-12-12 13:58 ` Jiri Pirko 2023-01-09 14:43 ` Kubalewski, Arkadiusz 2023-01-09 14:43 ` Kubalewski, Arkadiusz 2023-01-09 16:30 ` Jiri Pirko 2023-01-09 16:30 ` Jiri Pirko 2023-01-10 10:54 ` Kubalewski, Arkadiusz 2023-01-10 10:54 ` Kubalewski, Arkadiusz 2023-01-10 14:28 ` Jiri Pirko 2023-01-10 14:28 ` Jiri Pirko [not found] ` <645a5bfd-0092-2f39-0ff2-3ffb27ccf8fe@machnikowski.net> 2023-01-11 14:17 ` Kubalewski, Arkadiusz 2023-01-11 14:17 ` Kubalewski, Arkadiusz 2023-01-11 14:40 ` Maciek Machnikowski 2023-01-11 14:40 ` Maciek Machnikowski 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 15:54 ` Maciek Machnikowski 2023-01-11 15:54 ` Maciek Machnikowski 2023-01-11 16:27 ` Kubalewski, Arkadiusz 2023-01-11 16:27 ` Kubalewski, Arkadiusz 2023-01-10 20:05 ` Jakub Kicinski 2023-01-10 20:05 ` Jakub Kicinski 2023-01-11 8:19 ` Jiri Pirko 2023-01-11 8:19 ` Jiri Pirko 2023-01-11 14:16 ` Kubalewski, Arkadiusz 2023-01-11 14:16 ` Kubalewski, Arkadiusz 2023-01-11 15:04 ` Jiri Pirko 2023-01-11 15:04 ` Jiri Pirko 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 15:30 ` Kubalewski, Arkadiusz 2023-01-11 16:14 ` Jiri Pirko 2023-01-11 16:14 ` Jiri Pirko 2023-01-12 12:15 ` Kubalewski, Arkadiusz 2023-01-12 12:15 ` Kubalewski, Arkadiusz 2023-01-12 14:43 ` Jiri Pirko 2023-01-12 14:43 ` Jiri Pirko 2022-12-09 0:46 ` Kubalewski, Arkadiusz 2022-12-09 0:46 ` Kubalewski, Arkadiusz 2022-12-07 14:51 ` Jiri Pirko 2022-12-07 14:51 ` Jiri Pirko [not found] ` <20221207091946.3115742f@kernel.org> 2022-12-08 12:02 ` Jiri Pirko 2022-12-08 12:02 ` Jiri Pirko 2022-12-09 0:54 ` Jakub Kicinski 2022-12-08 18:23 ` Kubalewski, Arkadiusz 2022-12-08 18:23 ` Kubalewski, Arkadiusz 2022-12-08 0:27 ` Kubalewski, Arkadiusz 2022-12-08 0:27 ` Kubalewski, Arkadiusz 2022-12-08 11:58 ` Jiri Pirko 2022-12-08 11:58 ` Jiri Pirko 2022-12-08 23:05 ` Kubalewski, Arkadiusz 2022-12-08 23:05 ` Kubalewski, Arkadiusz 2022-12-09 10:01 ` Jiri Pirko 2022-12-09 10:01 ` Jiri Pirko 2023-01-12 12:23 ` Kubalewski, Arkadiusz 2023-01-12 12:23 ` Kubalewski, Arkadiusz 2023-01-12 14:50 ` Jiri Pirko 2023-01-12 14:50 ` Jiri Pirko 2023-01-12 19:09 ` Jakub Kicinski 2023-01-12 19:09 ` Jakub Kicinski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y5IR2MzXfqgFXGHW@nanopsycho \ --to=jiri@resnulli.us \ --cc=arkadiusz.kubalewski@intel.com \ --cc=jonathan.lemon@gmail.com \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=michal.michalik@intel.com \ --cc=milena.olech@intel.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=vadfed@fb.com \ --cc=vfedorenko@novek.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.