netdev - Re: [PATCH net-next 7/9] devlink: allow registering parameters after the instance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y8BmgpxAuqJKe8Pc@unreal>
Date:   Thu, 12 Jan 2023 21:58:58 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jacob Keller <jacob.e.keller@...el.com>,
        Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net,
        netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com
Subject: Re: [PATCH net-next 7/9] devlink: allow registering parameters after
 the instance

On Thu, Jan 12, 2023 at 03:59:53PM +0100, Jiri Pirko wrote:
> Thu, Jan 12, 2023 at 08:07:43AM CET, leon@...nel.org wrote:
> >On Wed, Jan 11, 2023 at 01:29:03PM -0800, Jacob Keller wrote:
> >> 
> >> 
> >> On 1/11/2023 8:45 AM, Jakub Kicinski wrote:
> >> > On Wed, 11 Jan 2023 10:32:13 +0100 Jiri Pirko wrote:
> >> >>>> I'm confused. You want to register objects after instance register?  
> >> >>>
> >> >>> +1, I think it's an anti-pattern.  
> >> >>
> >> >> Could you elaborate a bit please?
> >> > 
> >> > Mixing registering sub-objects before and after the instance is a bit
> >> > of an anti-pattern. Easy to introduce bugs during reload and reset /
> >> > error recovery. I thought that's what you were saying as well.
> >> 
> >> I was thinking of a case where an object is dynamic and might get added
> >> based on events occurring after the devlink was registered.
> >> 
> >> But the more I think about it the less that makes sense. What events
> >> would cause a whole subobject to be registerd which we wouldn't already
> >> know about during initialization of devlink?
> >> 
> >> We do need some dynamic support because situations like "add port" will
> >> add a port and then the ports subresources after the main devlink, but I
> >> think that is already supported well and we'd add the port sub-resources
> >> at the same time as the port.
> >> 
> >> But thinking more on this, there isn't really another good example since
> >> we'd register things like health reporters, regions, resources, etc all
> >> during initialization. Each of these sub objects may have dynamic
> >> portions (ex: region captures, health events, etc) but the need for the
> >> object should be known about during init time if its supported by the
> >> device driver.
> >
> >As a user, I don't want to see any late dynamic object addition which is
> >not triggered by me explicitly. As it doesn't make any sense to add
> >various delays per-vendor/kernel in configuration scripts just because
> >not everything is ready. Users need predictability, lazy addition of
> >objects adds chaos instead.
> >
> >Agree with Jakub, it is anti-pattern.
> 
> Yeah, but, we have reload. And during reload, instance is still
> registered yet the subobject disappear and reappear. So that would be
> inconsistent with the init/fini flow.
> 
> Perhaps during reload we should emulate complete fini/init notification
> flow to the user?

"reload" is triggered by me explicitly and I will get success/fail result
at the end. There is no much meaning in subobject notifications during
that operation.

Thanks