linux-kernel - Re: [PATCH 05/15] drivers/char: minor irq handler cleanups

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: <20080419060011.GA29321@bitwizard.nl>
Date:	Sat, 19 Apr 2008 08:00:11 +0200
From:	Rogier Wolff <R.E.Wolff@...Wizard.nl>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	alan@...hat.com, R.E.Wolff@...Wizard.nl,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/15] drivers/char: minor irq handler cleanups

On Fri, Apr 18, 2008 at 07:22:51PM -0400, Jeff Garzik wrote:
> This change's main purpose is to prepare for the patchset in
> jgarzik/misc-2.6.git#irq-remove, that explores removal of the
> never-used 'irq' argument in each interrupt handler.

The changes look sane, (for the drivers that I'm involved with). 

However, you're now adding a second parameter to my interrupt
routines: "polled" to replace the "never used" irq parameter. (which
/was/ used to determine wether we were called polled or not... 

On the other hand, most hardware should work if you remove the if
(!polled).

You added a "XXX Using free_irq in the interrupt is not wise!". When I
wrote that code, I didn't know about this. These lines triggered when
the level-triggered PCI interrupt stuck "active" this would mean that
NO userspace code would get executed anymore: Hard lock up. Difficult
to debug. This happend a few times during development when the code
behind the "if (!polled)": "tell the hardware we've seen the
interrupt" didn't work. On the other hand, some failures in the field
have triggered this. So I think it's wise to keep it in. Disabling the
interrupt on the card is not an option, because that's exactly what
this is supposed to catch: We're unable to make the card stop
interrupting the CPU.

Note that it also doesn't work (i.e. hard lock of the machine) if some
other driver is using the same interupt.

	Roger. 

-- 
** R.E.Wolff@...Wizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
--
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/