On 5/8/06, Dave Airlie <[email protected]> wrote:
>
> So as a result of this every interrupt service routine should now
> include pci_enable(). If you don't include this and someone from user
> space disables the hardware you're going to GPF. fbdev is already
> forced to take defensive measures like this since X will randomly
> disable it's hardware while it has an ISR active.
Jon please stop spouting crap at least, every ISR doesn't need pci_enable,
as it doesn't need it now, you are NOT listening, adding the enable bit
DOES NOT change things, if someone runs setpci from userspace now they can
do this, ROOT CAN CRASH YOUR MACHINE, FILM AT 11.
Do what you want, this has gone on too long. There are simple schemes
that can fix these holes but nobody seems to want to use them. Just
because something was broken in the past doesn't justify a new API to
continue supporting the breakage in the future. I am amazed at the
amount energy being expended to support this flawed API when
alternatives are available.
If you enable the rom at the moment you can crash things, some devices
don't have enough address decoders to decode a bar and the ROM, so me
enabling ROM decoding as your original patch did, can cause system
lockups,
why is this different, why didn't you write the ROM code patch properly
then and we woulnd't have to to hear about it now...
This is a known part of the PCI spec, it is not a bug. There is a ROM
API that the driver for the offending hardware should call to disable
(or copy) the ROM attribute. If the driver is missing the ROM disable
call that is a bug. I don't know what hardware has the address decoder
problem so I can't fix the drivers. This is documented in the header
file and has been posted to LKML. This hardware is uncommon, but If
you do identify hardware that is missing the address decoder please
inform me and the driver maintainer and we will add a call to disable
the ROM attribute.
As far as I know only a single person has hit this and they didn't
tell me the PCI ID of the problem hardware. I suspect the problem
hardware is an older Adaptec RAID controller.
--
Jon Smirl
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
