linux-kernel - Re: [REGRESSION] Re: [PATCH v2 2/3] of: property: Improve finding the supplier of a remote-endpoint property

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] [day] [month] [year] [list]

Date: Fri, 1 Mar 2024 10:59:17 +0100
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Rob Herring <robh+dt@...nel.org>
Cc: Saravana Kannan <saravanak@...gle.com>, Frank Rowand
 <frowand.list@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Xu Yang <xu.yang_2@....com>, kernel-team@...roid.com,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Hervé Codina <herve.codina@...tlin.com>, Geert Uytterhoeven
 <geert@...ux-m68k.org>
Subject: Re: [REGRESSION] Re: [PATCH v2 2/3] of: property: Improve finding
 the supplier of a remote-endpoint property

Hello Rob,

On Thu, 29 Feb 2024 16:10:38 -0600
Rob Herring <robh+dt@...nel.org> wrote:
[...]
> > > > > It's just this one of the 3 patches that needs reverting?  
> >
> > Just this patch. I reverted only this and the issue disappeared.
> >  
> > > > I sent a fix. With the fix, it's just exposing a bug elsewhere.  
> >
> > Exactly, this patch has two issues and only the easy one has a fix [0]
> > currently as far as I know.
> >  
> > > You say apply the fix. Luca says revert. I say I wish I made this 6.9
> > > material. Which is it?
> > >
> > > If the overlay applying depends on out of tree code (likely as there
> > > are limited ways to apply an overlay in mainline), then I don't really
> > > care if there is still a regression.  
> >
> > Obviously, to load and unload the overlays I'm using code not yet
> > in mainline. It is using of_overlay_fdt_apply() and of_overlay_remove()
> > via a driver underdevelopment that is similar to the one Hervé and
> > Lizhi Hou are working on [1][2].
> >
> > I see the point that "we are not breaking existing use cases as no code
> > is (un)loading overlays except unittest", sure.
> >
> > As I see it, we have a feature in the kernel that is not used, but it
> > will be, eventually: there are use cases, development is progressing and
> > patches are being sent actively. My opinion is that we should not
> > put additional known obstacles that will make it even harder than it
> > already is.  
> 
> Well, I don't care to do extra work of applying things and then have
> to turn right around fix or revert them. It happens enough as-is with
> just mainline. And no one wants to step up and fix the problems with
> overlays, but are fine just carrying their out of tree patches. What's
> one more. This is the 2nd case of overlay problems with out of tree
> users *today*! Some days I'm tempted to just remove overlay support
> altogether given the only way to apply them is unittest.

Thanks for taking time to understand the situation.

Just to clarify my position: together with Hervé we are not just
carrying out of tree code, we are actively developing code that uses
overlay load/unload at runtime and we will send it to mainline as soon
as it is ready.

As part of this process, Hervé has already sent patches to fix various
problems that happen when overlays are loaded and especially unloaded:
https://lore.kernel.org/all/20240229105204.720717-1-herve.codina@bootlin.com/
https://lore.kernel.org/all/20240227113426.253232-1-herve.codina@bootlin.com/
https://lore.kernel.org/all/20240220133950.138452-1-herve.codina@bootlin.com/
https://lore.kernel.org/all/20240220111044.133776-1-herve.codina@bootlin.com/

Best regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com