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]
Message-ID: <666b2379.5d0a0220.c7eec.8b6f@mx.google.com>
Date: Thu, 13 Jun 2024 15:42:45 +0200
From: Christian Marangi <ansuelsmth@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Linus Walleij <linus.walleij@...aro.org>, Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jonathan Corbet <corbet@....net>, Marc Zyngier <maz@...nel.org>,
	"Mike Rapoport (IBM)" <rppt@...nel.org>,
	Eric DeVolder <eric.devolder@...cle.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...ainline.org>,
	John Crispin <john@...ozen.org>
Subject: Re: [PATCH v2 0/2] ARM: decompressor: support AUTO_ZRELADDR and
 appended DTB

On Thu, Jun 13, 2024 at 04:59:49PM +0100, Russell King (Oracle) wrote:
> On Thu, Jun 13, 2024 at 03:50:58PM +0200, Linus Walleij wrote:
> > On Thu, Jun 13, 2024 at 1:24 PM Christian Marangi <ansuelsmth@...il.com> wrote:
> > 
> > > Sorry for asking again... but any news for this?
> > >
> > > I have also added the 2 patch here [1] [2].
> > >
> > > Been in incoming from a long time and I have seen other patch getting
> > > accepted. Did I do something wrong in submitting the 2 patch?
> > 
> > Hm Russell must have had some concerns, Russell?
> 
> I've been snowed under for about the last six weeks - with only the
> occasional day that isn't silly. It's that kind of frustrating snowed
> under where each problem is a bit like a brick wall placed every 1m
> and you're supposed to be doing a 100m sprint race - you can't see
> the next brick wall until you've climbed over the first.
> 
> Whether I have time to read the mailing lists or not depends entirely
> on what is happening on any particular day.
> 
> > If for nothing else I think some Tested-by:s would be appreciated,
> > do we have some people who use this that can provide Tested-by
> > tags?
> 
> Yes, tested-by's would be a really good idea, because my gut feeling
> is that this change has moderate risk of causing regressions. I'm
> not talking about "it works for me on the setup it's intended for"
> I'm talking about other platforms.
> 
> I'm also wondering about distros, and what they're supposed to do
> with the config option with their "universal" kernel that's
> supposed to boot across as many platforms as possible, what they
> should set the config option to, and what impact it has when enabled
> on platforms that it isn't originally intended for.
> 
> I haven't really read much of the patch because I've been so busy,
> so I may be being overly cautious. Given that I am quite busy, I
> would appreciate a summary of the situation rather than being fed
> with lots of results! In other words, the tested-bys, and "it works
> on all the xyz platforms that we've testsed, nothing appears to have
> regressed" would be ideal.
>

The current patch are used downstream on the OpenWrt ipq806x target that
is a mix of legacy (what this affects) and non legacy targets. (old
bootloader support loading DTB from the image and older ones require it
to be appended)

I think I need some help from the community to test this.

I can also move these patches to our "generic" target on OpenWrt so that
they will be enabled by every arm target we support.

Anyway thanks for the feedback, my only concern was that I messed
submitting the patch on the tracking system. Hope community can help
with this since it's a big feature for legacy devices that was broken
from a looong time (and only solution currently is to hardcode the PHY
offset values)

-- 
	Ansuel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ