public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <abelay@MIT.EDU>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-pci@atrey.karlin.mff.cuni.cz,
	Linux-pm mailing list <linux-pm@lists.osdl.org>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: Bug in PCI core
Date: Fri, 13 Oct 2006 12:34:20 -0400	[thread overview]
Message-ID: <1160757260.26091.115.camel@localhost.localdomain> (raw)
In-Reply-To: <1160755562.25218.60.camel@localhost.localdomain>

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

  reply	other threads:[~2006-10-13 16:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-11 20:41 Bug in PCI core Alan Stern
2006-10-13  1:01 ` [linux-pm] " Benjamin Herrenschmidt
2006-10-13  8:50   ` Adam Belay
2006-10-13  9:16     ` Benjamin Herrenschmidt
2006-10-13  9:31       ` Martin Mares
2006-10-13 12:25         ` [linux-pm] " Benjamin Herrenschmidt
2006-10-13 14:29     ` Alan Stern
2006-10-13 15:26       ` [linux-pm] " Alan Cox
2006-10-13 15:29         ` Arjan van de Ven
2006-10-13 16:06           ` Alan Cox
2006-10-13 16:34             ` Adam Belay [this message]
2006-10-13 16:36               ` Matthew Wilcox
2006-10-13 17:09               ` Alan Cox
2006-10-13 16:49                 ` Matthew Wilcox
2006-10-13 17:34                   ` Alan Cox
2006-10-13 17:13                     ` Arjan van de Ven
2006-10-13 17:57                     ` Alan Stern
2006-10-13 19:18                       ` [linux-pm] " Matthew Wilcox
2006-10-13 20:59                         ` Alan Stern
2006-10-13 19:30                     ` Adam Belay
2006-10-13 23:00                     ` Benjamin Herrenschmidt
2006-10-14  2:33                       ` Alan Stern
2006-10-14  3:04                         ` [linux-pm] " Roland Dreier
2006-10-14  3:07                         ` Matthew Wilcox
2006-10-14  3:19                         ` Bill Randle
2006-10-14  5:47                         ` Greg KH
2006-10-13 17:01                 ` Adam Belay
2006-10-13 16:40           ` Adam Belay
2006-10-13 20:48       ` [linux-pm] " Pavel Machek
2006-10-14  5:34 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1160757260.26091.115.camel@localhost.localdomain \
    --to=abelay@mit.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-pm@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox