linux-kernel - Re: [PATCH] pcmcia: irq probe can be done without risking an IRQ storm

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: <1177614391.25960.38.camel@localhost.localdomain>
Date:	Thu, 26 Apr 2007 21:06:31 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] pcmcia: irq probe can be done without risking an IRQ
	storm

On Thu, 2007-04-26 at 19:31 +0200, Thomas Gleixner wrote:
> > >  #ifdef CONFIG_PCMCIA_PROBE
> > > +	if (!(req->Attributes & IRQ_HANDLE_PRESENT))
> > > +		type |= IRQ_NOAUTOEN;
> > > +
> > >  	if (s->irq.AssignedIRQ != 0) {
> > >  		/* If the interrupt is already assigned, it must be the same */
> > >  		irq = s->irq.AssignedIRQ;
> > 
> > alpha:
> > 
> > drivers/pcmcia/pcmcia_resource.c: In function 'pcmcia_request_irq':
> > drivers/pcmcia/pcmcia_resource.c:816: error: 'IRQ_NOAUTOEN' undeclared (first use in this function)
> > drivers/pcmcia/pcmcia_resource.c:816: error: (Each undeclared identifier is reported only once
> > drivers/pcmcia/pcmcia_resource.c:816: error: for each function it appears in.)
> > 
> > Problem is, IRQ_NOAUTOEN is a generic-irq thing, so architectures which
> > don't use generic-irqs break.  And it's defined in linux/irq.h which
> > (stupidly) cannot be included in generic code.
> 
> Hrmpf. We need a IRQF_NOAUTOEN, which can be handed to reqeust_irq().
> 
> I cook a patch.

Not that simple. For non shared interrupts it is straight forward, but
for shared ones we have to decide, whether we 

A) reject the request
B) disable the interrupt and rely on the caller, that it reenables it
C) ignore it

sorted by ugliness order :)

A) is definitely the most safe bet, but B) might work as well.

	tglx


-
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/