linux-kernel - Re: PCI: Fix boot-time hang on G31/G33 PC

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: <46FAE585.5030306@shaw.ca>
Date:	Wed, 26 Sep 2007 17:04:37 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Jesse Barnes <jesse.barnes@...el.com>
Cc:	Greg KH <greg@...ah.com>, linux-pci@...ey.karlin.mff.cuni.cz,
	Matthew Wilcox <matthew@....cx>, linux-kernel@...r.kernel.org,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Subject: Re: PCI: Fix boot-time hang on G31/G33 PC

Jesse Barnes wrote:
> On Wednesday, September 26, 2007 2:56 pm Greg KH wrote:
>> On Wed, Sep 26, 2007 at 02:55:55PM -0700, Jesse Barnes wrote:
>>> On Wednesday, September 26, 2007 2:18 pm Greg KH wrote:
>>>> Due to the issues surrounding this patch, I'm dropping it from my
>>>> repo.
>>> What issues?  Is it causing problems for people?
>> I thought this was the patch that Ivan objected to.
> 
> Yeah, Ivan objected to this, but incorrectly I think.
> 
> Ivan, your concern is about disabling things like interrupt controllers 
> and power management chips during probe right?  You're right that doing 
> that could cause problems if we get and interrupt or PMU event at just 
> the wrong time, but that could just as easily happen if decode was 
> still enabled but the BAR had a bogus address programmed (as it would 
> during probing).
> 
> Ultimately, I don't care much one way or another as long as we can get 
> the desktop platforms fixed somehow.  I think disabling decode is the 
> most correct way of doing this, but I'm open to other solutions (this 
> is the only patch I've seen though that's been tested to solve the 
> problem).

I agree, I've yet to see a single report of an actual problem that 
disabling the decode causes, nor even a theoretical problem which 
couldn't already happen due to the possibility of the device being 
accessed during BAR sizing, which just shouldn't be allowed since it 
can't work with or without this patch.

Until and unless we have something better that fixes the real and 
serious boot-time problems that we need this patch to fix, I would say 
it should stay in.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

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