linux-kernel - Re: linux-next: Tree for Nov 1 (xen

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: <alpine.DEB.2.02.1311041800540.26077@kaball.uk.xensource.com>
Date:	Mon, 4 Nov 2013 18:20:42 +0000
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Randy Dunlap <rdunlap@...radead.org>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	<linux-next@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<xen-devel@...ts.xenproject.org>
Subject: Re: linux-next: Tree for Nov 1 (xen_swiotllb)

On Fri, 1 Nov 2013, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 01, 2013 at 11:16:26AM -0700, Randy Dunlap wrote:
> > On 11/01/13 01:11, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Changes since 20131031:
> > > 
> > > The squashfs tree gained a build failure so I used the version from
> > > next-20131031.
> > > 
> > > The block tree gained conflicts against the f2fs, aio-direct and Linus'
> > > trees and a build failure and generated several warnings so I used the
> > > version from next-20131031.
> > > 
> > > The dt-rh tree gained a conflict against the powerpc tree.
> > > 
> > > The kvm-ppc tree gained a conflict against the powerpc tree.
> > > 
> > > The leds tree gained a conflict against the powerpc tree.
> > > 
> > > The tty tree lost its build failure.
> > 
> > 
> > on x86_64, when CONFIG_PCI is not enabled:
> > 
> > arch/x86/built-in.o: In function `pci_xen_swiotlb_init_late':
> > (.text+0x102cc): undefined reference to `pci_request_acs'
> > arch/x86/built-in.o: In function `pci_xen_swiotlb_init':
> > (.init.text+0x3f6c): undefined reference to `pci_request_acs'
> 
> Stefano,
> 
> Please fix that. I think it is commit 83862ccfc0a03212fde43b4ac29c28381828768b
> Author: Stefano Stabellini <stefano.stabellini@...citrix.com>
> Date:   Thu Oct 10 13:40:44 2013 +0000
> 
>     xen/arm,arm64: enable SWIOTLB_XEN
> 
> that is causing this. Is it safe to add:
> 
>        depends on PCI
> 
> back on it?
 
On ARM it is possible to use the swiotlb without PCI support.
Ideally we wouldn't even build arch/x86/xen/pci-swiotlb-xen.c if
CONFIG_PCI was missing. However other core x86 kernel stuff seem to have
similar issues, for example arch/x86/kernel/pci-swiotlb.c build with or
without CONFIG_PCI and references pci_xen_swiotlb_detect.
I think that the right solution would be to completely disentangle
CONFIG_PCI from swiotlb related stuff, but for the moment I went for the
easy fix:


commit 1e6d541cc26683d0f347e1cedfee1bc57e3f8875
Author: Stefano Stabellini <stefano.stabellini@...citrix.com>
Date:   Mon Nov 4 18:11:54 2013 +0000

    pci-swiotlb-xen: call pci_request_acs only ifdef CONFIG_PCI
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@...citrix.com>

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 9695704..0e98e5d 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -75,8 +75,10 @@ void __init pci_xen_swiotlb_init(void)
 		xen_swiotlb_init(1, true /* early */);
 		dma_ops = &xen_swiotlb_dma_ops;
 
+#ifdef CONFIG_PCI
 		/* Make sure ACS will be enabled */
 		pci_request_acs();
+#endif
 	}
 }
 
@@ -92,8 +94,10 @@ int pci_xen_swiotlb_init_late(void)
 		return rc;
 
 	dma_ops = &xen_swiotlb_dma_ops;
+#ifdef CONFIG_PCI
 	/* Make sure ACS will be enabled */
 	pci_request_acs();
+#endif
 
 	return 0;
 }
--
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/