[PATCH net-next 2/6] software node: allow named software node to be created

[Andy Shevchenko]

On Fri, Jul 15, 2022 at 11:48:41PM +0300, Vladimir Oltean wrote:
> On Fri, Jul 15, 2022 at 11:33:40PM +0300, Andy Shevchenko wrote:
> > On Fri, Jul 15, 2022 at 11:17:15PM +0300, Vladimir Oltean wrote:
> > > On Fri, Jul 15, 2022 at 10:57:55PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Jul 15, 2022 at 05:01:32PM +0100, Russell King wrote:
> > > > > From: Vladimir Oltean <vladimir.oltean at nxp.com>
> > > > > 
> > > > > Allow a named software node to be created, which is needed for software
> > > > > nodes for a fixed-link specification for DSA.
> > > > 
> > > > In general I have no objection, but what's worrying me is a possibility to
> > > > collide in namespace. With the current code the name is generated based on
> > > > unique IDs, how can we make this one more robust?
> > > 
> > > Could you be more clear about the exact concern?
> > 
> > Each software node can be created with a name. The hierarchy should be unique,
> > means that there can't be two or more nodes with the same path (like on file
> > system or more specifically here, Device Tree). Allowing to pass names we may
> > end up with the situation when it will be a path collision. Yet, the static
> > names are easier to check, because one may run `git grep ...` or coccinelle
> > script to see what's in the kernel.
> 
> So won't kobject_init_and_add() fail on namespace collision? Is it the
> problem that it's going to fail, or that it's not trivial to statically
> determine whether it'll fail?
> 
> Sorry, but I don't see something actionable about this.

I'm talking about validation before a runtime. But if you think that is fine,
let's fail it at runtime, okay, and consume more backtraces in the future.

-- 
With Best Regards,
Andy Shevchenko