linux-kernel - Re: [PATCH] tracing: Expose CPU physical addresses (resource values) for PCI devices

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: <20160617175901.7bd90d14@gandalf.local.home>
Date:	Fri, 17 Jun 2016 17:59:01 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	linux-pci@...r.kernel.org, karol herbst <karolherbst@...il.com>,
	linux-kernel@...r.kernel.org, Pekka Paalanen <ppaalanen@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	Ben Skeggs <bskeggs@...hat.com>,
	Yinghai Lu <yinghai@...nel.org>, koriakin@...4.net,
	linuxppc-dev@...abs.org
Subject: Re: [PATCH] tracing: Expose CPU physical addresses (resource
 values) for PCI devices


Sorry for the late reply, this patch got pushed down in my INBOX.

Could I get someone from PPC to review this patch, just to be safe?

Thanks!

-- Steve



On Wed, 11 May 2016 14:06:57 -0500
Bjorn Helgaas <bhelgaas@...gle.com> wrote:

> Previously, mmio_print_pcidev() put "user" addresses in the trace buffer.
> On most architectures, these are the same as CPU physical addresses, but on
> microblaze, mips, powerpc, and sparc, they may be something else, typically
> a raw BAR value (a bus address as opposed to a CPU address).
> 
> Always expose the CPU physical address to avoid this arch-dependent
> behavior.
> 
> This change should have no user-visible effect because this file currently
> depends on CONFIG_HAVE_MMIOTRACE_SUPPORT, which is only defined for x86,
> and pci_resource_to_user() is a no-op on x86.
> 
> Signed-off-by: Bjorn Helgaas <bhelgaas@...gle.com>
> ---
>  kernel/trace/trace_mmiotrace.c |   10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
> index 68f376c..cd7480d 100644
> --- a/kernel/trace/trace_mmiotrace.c
> +++ b/kernel/trace/trace_mmiotrace.c
> @@ -68,19 +68,15 @@ static void mmio_print_pcidev(struct trace_seq *s, const struct pci_dev *dev)
>  	trace_seq_printf(s, "PCIDEV %02x%02x %04x%04x %x",
>  			 dev->bus->number, dev->devfn,
>  			 dev->vendor, dev->device, dev->irq);
> -	/*
> -	 * XXX: is pci_resource_to_user() appropriate, since we are
> -	 * supposed to interpret the __ioremap() phys_addr argument based on
> -	 * these printed values?
> -	 */
>  	for (i = 0; i < 7; i++) {
> -		pci_resource_to_user(dev, i, &dev->resource[i], &start, &end);
> +		start = dev->resource[i].start;
>  		trace_seq_printf(s, " %llx",
>  			(unsigned long long)(start |
>  			(dev->resource[i].flags & PCI_REGION_FLAG_MASK)));
>  	}
>  	for (i = 0; i < 7; i++) {
> -		pci_resource_to_user(dev, i, &dev->resource[i], &start, &end);
> +		start = dev->resource[i].start;
> +		end = dev->resource[i].end;
>  		trace_seq_printf(s, " %llx",
>  			dev->resource[i].start < dev->resource[i].end ?
>  			(unsigned long long)(end - start) + 1 : 0);