linux-kernel - Re: [linux-pm] Bug in PCI core

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]

Message-Id: <1160757632.26091.121.camel@localhost.localdomain>
Date:	Fri, 13 Oct 2006 12:40:31 -0400
From:	Adam Belay <abelay@....EDU>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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:29 +0200, Arjan van de Ven wrote:
> On Fri, 2006-10-13 at 16:26 +0100, Alan Cox wrote:
> > Ar Gwe, 2006-10-13 am 10:29 -0400, ysgrifennodd Alan Stern:
> > > > I'd like to propose that we have the pci config sysfs interface return
> > > > -EIO  when it's blocked (e.g. active BIST or D3cold).  This accurately
> > > > reflects the state of the device to userspace, reduces complexity, and
> > > > could potentially save some memory per PCI device instance.
> > > 
> > > Could you resubmit your old patches and include a corresponding fix for 
> > > this access problem?
> > 
> > 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 ;)
> 
> 
> also the thing this patch does is ONLY when the device is effectively
> off the bus return -EIO.
> One can argue that -EAGAIN is nicer since it's only a temporary
> condition though....
> 
> 

Yeah, perhaps -EAGAIN would be more appropriate, especially in the power
state transition and BIST cases.  An interesting possibility might be to
have the file actually block, although I'm not sure if the O_NONBLOCK
flag or polling for that matter can be supported through the
sysfs/driver-core API.

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