linux-kernel - Re: genirq: Ensure we locate the passed IRQ in irq_alloc

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: <20110604095138.GA708@opensource.wolfsonmicro.com>
Date:	Sat, 4 Jun 2011 10:51:39 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Milton Miller <miltonm@....com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: genirq: Ensure we locate the passed IRQ in irq_alloc_descs()

On Fri, Jun 03, 2011 at 07:23:24PM -0500, Milton Miller wrote:
> On Fri, 3 Jun 2011 about 16:06:36 +0100, Mark Brown wrote:

> > I need either a specific IRQ or an allocated one.  This is just a very
> > standard driver with an interrupt controller 

> I don't know that I'd call an interrupt controller a standard driver
> today, but agree we are heading towards that.

Pretty much any modern ARM system will have a PMIC with an interrupt
controller in it.

> > The driver assumes it's going to get a contiguous range, it'd be a lot
> > of bookkeeping for no gain to have to cope with them being splattered
> > all over the place.

> The irq domain concept addresses mapping, but a simple fully allocated
> block will be one of the options.  Having 60 irqdesc might be 
> pushing the limit for some platforms but that can be addressed later
> when irq domains are upstream.

I'm not really sure what an IRQ domain is (the patch series you pointed
at before does rather appear to assume one knows already) but given that
we're allocating from within a 32 bit type it seems like we should be
using a few orders of magnitude more interrupts in a system than we do
presently before this becomes much of an issue.

> > If the user cares they can just pick a number for the base; if they're
> > going to pick a number they may as well pick the actual number.

> I'd argue the user is the wrong level to make this decision.  However,
> saying the platform decides is valid, and the excerpt you had earlier
> implied you were getting the irq argument from platform data, not the
> user (eg via a module parameter)..

It's platform data.  Having interrupt numbers specified as module
parameters strikes me as insane - the particular integers we map
individual interrupts onto are very much an implementation decision of
the kernel.

> I should point out that several archtectures currently allocate irqs
> in a architecture layer before calling the irq allocator asking for
> the exact irq they choose on what they thought was free.  Among these
> are x86 and powerpc.   Not calling the architecture layer will causein
> all future allocations by other drivers using the architecture layer
> to fail..

That sounds like we should join the two IRQ allocators up with each
other.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/