Re: [PATCH 1/1] pci: Block config access during BIST (resend)
From: Alan Cox (alan_at_lxorguk.ukuu.org.uk)
Date: 01/13/05
- Previous message: Linus Torvalds: "Re: thoughts on kernel security issues"
- In reply to: Brian King: "Re: [PATCH 1/1] pci: Block config access during BIST (resend)"
- Next in thread: Alan Cox: "Re: [PATCH 1/1] pci: Block config access during BIST (resend)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: brking@us.ibm.com Date: Thu, 13 Jan 2005 15:36:11 +0000
On Maw, 2005-01-11 at 22:17, Brian King wrote:
> Andi Kleen wrote:
> We can certainly go either way. I decided to go the way I did simply
> because that was what was suggested.
The error case breaks X11. The cached approach of Ben's would probably
hide that nicely although it might cause some random crashes during
powerdown. Its hard to fix in user space because X has no idea how to
tell what is going on portably in the 'it broke' case other than spin
trying to for a while. The kernel knows what is up and can make an
intelligent decision - if the device doesn't come back from bist or we
need to mark devices as "very gone away" then maybe a second flag so we
have two user checked flags
In BIST - wait
Dead - error
> cycles and may even deadlock the system. This usage would require the
> ability to block userspace for an indefinite period of time and also
> make use of the config space caching code that is in my patch.
What if the user space you block holds a resource that is preventing
power down completing ? I can see how the kernel side stuff needs to be
more robust (bad news btw.. over 99% of pci config calls in the kernel
don't check the return according to a quick grep count. Good news is
they are almost all reads so caching ought to work for the main config
space stuff at least)
Caching doesn't however work for the cases like IRQ handlers but that
seems not to be problematic as the only "other device" stuff people
should be sticking their noses in except for bridge fixup stuff is
things like the BAR registers.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Linus Torvalds: "Re: thoughts on kernel security issues"
- In reply to: Brian King: "Re: [PATCH 1/1] pci: Block config access during BIST (resend)"
- Next in thread: Alan Cox: "Re: [PATCH 1/1] pci: Block config access during BIST (resend)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
