linux-kernel - Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory

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]

Date:	Mon, 14 Sep 2015 10:37:19 +0100
From:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:	Tomasz Nowicki <tomasz.nowicki@...aro.org>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Yijing Wang <wangyijing@...wei.com>,
	Will Deacon <Will.Deacon@....com>,
	Arnd Bergmann <arnd@...db.de>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	"msalter@...hat.com" <msalter@...hat.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>
Subject: Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka
 ECAM) and ACPI code out of arch/x86/ directory

On Fri, Sep 11, 2015 at 01:35:36PM +0100, Tomasz Nowicki wrote:
> On 11.09.2015 13:20, Lorenzo Pieralisi wrote:

[...]

> >>> With that in place using raw_pci_write/read or the generic accessors
> >>> becomes almost identical, with code requiring the pci_bus to be
> >>> created using the generic accessors and ACPICA using the raw version.
> >>>
> >>> I might be missing something, so apologies if that's the case.
> >>>
> >>
> >> Actually, I think you showed me the right direction :) Here are some
> >> conclusions/comments/concerns. Please correct me if I am wrong:
> >>
> >> 1. We need raw_pci_write/read accessors (based on ECAM) for ARM64 too
> >> but only up to the point where buses are enumerated. From that point on,
> >> we should reuse generic accessors from access.c file, right?
> >
> > Well, I still have not figured out whether on arm64 the raw accessors
> > required by ACPICA make sense.
> >
> > So either arm64 relies on the generic MCFG based raw read and writes
> > or we define the global raw read and writes as empty (ie x86 overrides
> > them anyway).
> >
> > I will get back to you on this.
> >
> >> 2. For ARM64 ACPI PCI, we can use generic accessors right away, .map_bus
> >> would call common code part (pci_dev_base()). The only thing that worry
> >> me is fact that MCFG regions are RCU list so it needs rcu_read_lock()
> >> for the .map_bus (mcfg lookup) *and* read/write operation.
> >
> > Do you mean the address look-up and the mmio operation should be carried
> > out atomically right ?
> Yes.

We can wrap the calls pci_generic_read/write() within a function and
add rcu_read_lock()/unlock() around them, eg:

int pci_generic_config_read_rcu()
{
	rcu_read_lock();
	pci_generic_config_read(...);
	rcu_read_unlock();
}

Honestly it seems the RCU API is needed just because config space
can be also accessed by raw_ accessors in ACPICA code, that's the only
reason I see to protect the config structs against config space
removal (basically config entries are removed only when the host
bridge is released if I read the code correctly, and the only way
this can happen concurrently is having ACPICA code reusing the
same config space but accessing it with no pci_bus struct attached
to it, by just using the (segment, bus, dev, fn) tuple).

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