linux-kernel - Re: [PATCH] genirq: allow selection of number of sparse irqs

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: <87sfmdbxvf.wl-maz@kernel.org>
Date:   Wed, 03 Aug 2022 08:16:20 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Daniel Walker <danielwa@...co.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        George Cherian <george.cherian@...vell.com>,
        sgoutham@...vell.com, "BOBBY Liu (bobbliu)" <bobbliu@...co.com>,
        xe-linux-external@...co.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] genirq: allow selection of number of sparse irqs

On Tue, 02 Aug 2022 23:37:47 +0100,
Daniel Walker <danielwa@...co.com> wrote:
> 
> On Sat, Jul 30, 2022 at 10:59:05AM +0100, Marc Zyngier wrote:
> > > 
> > > Marvell submitted a similar change, but non-selectable, about a
> > > month ago.
> > 
> > Which wasn't really acceptable either.
> > 
> > > 
> > > The limitation prevents Cisco and Marvell hardware from
> > > functioning. I don't think we're well versed enough on the generic
> > > irq system to implement what your suggesting, even if we did Thomas
> > > would not likely accept it.
> > 
> > I don't think you can speak for Thomas here. In my experience of
> > working with him, he's in general much more inclined to look at a
> > scalable, long term solution than at a point hack. Specially given
> > that we already use xarrays for MSIs.
>  
> Your welcome make the attempt yourself, if you believe in it.

The thing is, I don't need it, while you apparently do need a change
in the kernel.

> 
> > > Your suggestion is more of a long term solution vs. our short term
> > > solution.
> > 
> > Exactly. Experience shows that short term hacks are almost always a
> > bad idea and result in something that isn't maintainable.
> 
> Thomas introduced the "hack" in c1ee626 in 2011.

Yes. And it covers all the systems we care about so far. It is small,
fixed in size, and doesn't impose extra requirements on everyone else.
Your system changes the requirement, and it is the opportunity to
revisit an 11 year old decision.

> It's more of a question of if someone has the time an and/or
> inclination to make the changes your requesting.

No, it is about who has the need. You do, and nobody else does.

> Marvell and Cisco only require to increase the size and keep the
> status quo, and nothing is wrong with that.

It is pretty wrong when it adds unneeded overhead on systems that
don't require this, and doesn't scale in the face of existing
architectures (let alone future ones). Distributions ship a single
kernel image, and would obviously select the largest possible value,
just to maximise perceived compatibility requirements. My ask is that
you don't inflict this on systems that do not need it.

> 
> > > I'm not wedded to any solution, we just need to relieve
> > > the limitation so our hardware starts working. I would imagine other
> > > companies have this issue, but I don't know which ones currently.
> > 
> > This architecture has been in the wild for the best part of 10 years,
> > in Linux for 8 years, and nobody so far screamed because of this
> > perceived limitation. It would help if you described exactly what
> > breaks in your system, because just saying "give me more" is not
> > exactly helping (there are other limitations in the GICv3 ITS driver
> > that may bite you anyway).
> 
> We need more irq lines because we have a lot of devices.. I suppose it's
> possible there's some defect in the kernel which eats up or wastes irq lines,
> but I don't think so. We have devices which use a lot of irq lines.
> 
> > > I would rather to use an upstream solution verses holding the
> > > patches privately.  I would suggest if this limitation would not be
> > > overcome for 3-4 releases the short term solution should be
> > > acceptable over that time frame to be replaced by something else
> > > after that.
> > 
> > If you want to have an impact on the features being merged in the
> > upstream kernel, a good start would be to take feedback on board.
> 
> We did that.. I updated the patch from Marvell's original to allow it to be
> selectable, this was requested by someone on this list.

Well, I'm another "someone on the list" asking you to do better. You
are perfectly entitled to ignore me, and I'm just as entitled to voice
my opposition to your approach.

	M.

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