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]
Date:   Tue, 16 May 2023 11:06:29 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Rich Felker <dalias@...c.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] irqchip/jcore-aic: Fix missing allocation of IRQ descriptors

On Thu, 11 May 2023 10:03:01 +0100,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de> wrote:
> 
> On Thu, 2023-05-11 at 09:47 +0100, Marc Zyngier wrote:
> > On Thu, 11 May 2023 08:22:20 +0100,
> > John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de> wrote:
> > > 
> > > Hi Jason!
> > 
> > ???
> 
> Sorry, I was confused by this:
> 
> > > > [- Jason]
> > > > 
> > > > It really begs the question: how has it ever been working before?
> > > 
> > > Users already used a locally patched kernel to work around this problem.
> > 
> > You're not answering my question. Does it mean JCore never worked
> > upstream?
> 
> It did still work which is why the previously suggested change was to make a
> failing call to irq_alloc_descs() non-fatal. The boards still booted
> up.

I don't get it. Either the descriptors are already allocated, and you
don't need this call, or they were never allocated and this never
worked. Which one is it?

> 
> > > > Is there any plan to modernise the port and get it to allocate
> > > > irq_descs on demand, as we do on most architectures?
> > > 
> > > Yes, there are plans to modernize the port. We're first working on
> > > upstreaming all kinds of patches that have been queuing up over the
> > > time.
> > 
> > I'd rather you skip that step and focus on making it work as a modern
> > architecture. This really looks like ARM circa 2007... :-/
> 
> We have a patch-set for switching it to device tree in the pipeline.

Again: why aren't we reviewing that instead of beating a long dead
horse?

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ