linux-kernel - Re: [PATCH] restore libata build on frv

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, 26 Sep 2006 18:25:28 +0100
From:	David Howells <dhowells@...hat.com>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	Jeff Garzik <jgarzik@...ox.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Howells <dhowells@...hat.com>,
	Al Viro <viro@....linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] restore libata build on frv 

Linus Torvalds <torvalds@...l.org> wrote:

> Zero _is_ an appropriate choice, dammit!
> ...
> and then, if your actual _hardware_ things that the bit-pattern with all 
> bits clear is a valid irq that can be used for normal devices,

PCI, for example.  According to the spec, 0x00 is valid in the Interrupt Line
register and 0xFF indicates unconnected or unset.

> then what you do is you add a irq number translation layer (WHICH WE NEED
> AND HAVE _ANYWAY_) and make sure that nobody sees that on a _software_
> level.

So, by your argument, if you _have_ to have an IRQ translation layer anyway,
then what's the problem with having zero as a valid IRQ and using some other
value to indicate an invalid IRQ?  As you say, you have a translation layer
anyway...

That would mean the arch maintainer could make the optimal choice for their
arch - perhaps picking 255 which would be consistent with PCI.

As far as FRV goes, I'm quite happy with 0 as being NO_IRQ, since the 0 bit in
the primary PIC registers is the master switch, not a per-level bit (there are
no source indicators unfortunately).

However, x86, x86_64, and others *do* treat IRQ 0 as being valid, and expose
it to userspace in various ways:

	warthog>cat /proc/interrupts 
		   CPU0       
	  0:  287035291    IO-APIC-edge  timer
	...

So on *that* basis, using IRQ 0 to indicate unset/invalid/etc would seem to be
bad.

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