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] [day] [month] [year] [list]
Date:	Tue, 11 Feb 2014 15:38:54 +0000
From:	Dave Martin <Dave.Martin@....com>
To:	Ben Dooks <ben.dooks@...ethink.co.uk>
Cc:	linux@....linux.org.uk, jonathan.austin@....com, nico@...aro.org,
	marc.zyngier@....com, catalin.marinas@....com,
	u.kleine-koenig@...gutronix.de, will.deacon@....com,
	linux-kernel@...r.kernel.org, vgupta@...opsys.com,
	Fabrice GASNIER <fabrice.gasnier@...com>, sboyd@...eaurora.org,
	linux-arm-kernel@...ts.infradead.org, maxime.coquelin@...com
Subject: Re: [RFC PATCH] ARM: Add imprecise abort enable/disable macro

On Mon, Feb 10, 2014 at 04:38:09PM +0000, Ben Dooks wrote:
> On 10/02/14 15:21, Dave Martin wrote:

[...]

> >Does PCI have any way of finding out which parts of the configuration
> >space are there before you are forced to go poking around in invalid
> >address space?
> >
> >I'm guessing there may not be, otherwise this convsersation might not
> >be happening ... but I don't know too much about PCI.
> 
> IIRC for configuration accesses you have to wait for the PCIe core
> to get a response from the other end. The systems I've seen either
> poll for completion or hold the transaction until the pcie core has
> finished working.

So presumably if the other end isn't there, then it's up to the PCIe
implementation to decide how to signal that back to the CPU, or are
things more constrained than that?

I sill don't understand whether the failing probe is triggered directly
from the PCI common code in the kernel or whether it comes from the
specific bus driver.  If the latter, hacks for working round this at
least won't touch the common code, which is the preferable outcome.

Cheers
---Dave
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ