[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1160757260.26091.115.camel@localhost.localdomain>
Date: Fri, 13 Oct 2006 12:34:20 -0400
From: Adam Belay <abelay@....EDU>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Arjan van de Ven <arjan@...radead.org>,
Alan Stern <stern@...land.harvard.edu>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Greg KH <greg@...ah.com>, linux-pci@...ey.karlin.mff.cuni.cz,
Linux-pm mailing list <linux-pm@...ts.osdl.org>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] Bug in PCI core
On Fri, 2006-10-13 at 17:06 +0100, Alan Cox wrote:
> Ar Gwe, 2006-10-13 am 17:29 +0200, ysgrifennodd Arjan van de Ven:
> > > And then you can fix the applications it breaks, like the X server which
> > > does actually want to know where all the devices are located in PCI
> > > space.
> > >
> >
> > .. but which could equally well mmap the resource from sysfs ;)
>
> That doesn't help deal with the location and PCI control side of things
> X has to perform and deal with. You also forgot to attach the tested
> patch set for the X server and other affected apps.
>
> The cached stuff was put in place precisely because stuff broke
>
I agree this needs to be fixed. However, as I previously mentioned,
this isn't the right place to attack the problem. Remember, this wasn't
originally a kernel regression. Rather it's a workaround for a known
X/lspci/whatever bug. It's not the kernel's job to babysit userspace.
If a userspace app that has the proper permissions decides to take a
course of action that could potentially crash the system, then it has a
right to do so. There are probably dozens of vectors for these sorts of
problems (e.g. mmap as Arjan has mentioned) so why stop at the pci
config sysfs interface?
In this specific case, the workaround for this userspace bug actually
makes it impossible for programs that are implemented correctly (i.e.
understand that PCI configuration space can be inaccessible under
certain conditions) from working optimally because the kernel gives
inaccurate PCI config data rather than reporting the reality of the
situation. I'd much rather give correct code the advantage then work
around buggy software that really needs to be fixed directly.
Finally, it's worth noting that this issue is really a corner-case, and
in most systems it's extremely rare that even incorrect userspace apps
would have any issue.
Thanks,
Adam
-
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/
Powered by blists - more mailing lists