summaryrefslogtreecommitdiffstats
path: root/arch/x86
diff options
context:
space:
mode:
authorJeremy Fitzhardinge <jeremy@goop.org>2007-11-29 01:22:11 +0100
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-11-29 18:24:55 +0100
commitf97b8954953ba8e692dbb92d99e26b721f7068cd (patch)
tree96edbfcd901873c7c3094f9829d2db436fba269a /arch/x86
parentlguest: prevent VISWS or VOYAGER randconfigs (diff)
downloadlinux-f97b8954953ba8e692dbb92d99e26b721f7068cd.tar.xz
linux-f97b8954953ba8e692dbb92d99e26b721f7068cd.zip
x86/paravirt: revert exports to restore old behaviour
Subdividing the paravirt_ops structure caused a regression in certain non-GPL modules which try to use mmu_ops and cpu_ops. This restores the old behaviour, and makes it consistent with the non-CONFIG_PARAVIRT case. Takashi Iwai <tiwai@suse.de> adds: > I took at this problem (as I have an nvidia card on one of my > workstations), and found out that the following suffer from > EXPORT_SYMBOL_GPL changes: > > * local_disable_irq(), local_irq_save*(), etc. > * MSR-related macros like rdmsr(), wrmsr(), read_cr0(), etc. > wbinvd(), too. > * pmd_val(), pgd_val(), etc are all involved with pv_mm_ops. > pmd_large() and pmd_bad() is also indirectly involved. > __flush_tlb() and friends suffer, too. Christoph Hellwig objects to this patch on the grounds that modules shouldn't be using these operations anyway. I don't think this is a particularly good reason to reject the patch, for several reasons: 1. These operations are still available to modules when not using CONFIG_PARAVIRT, since they are implicitly exported as inline functions via the kernel headers. Exporting the same functionality as GPL-only symbols just adds a gratuitious difference between CONFIG_PARAVIRT and non-CONFIG_PARAVIRT configurations. If we really think these operations are not for module use (or non-GPL module use), then we should solve the problem in a general way. 2. It's a regression from previous kernels, which would work these modules even with CONFIG_PARAVIRT enabled. 3. The operations in question seem pretty reasonable for modules to use. The control registers/MSRs can be accessed directly anyway, so there's no benefit in preventing modules from using standard interfaces. And it seems reasonable to allow a graphics driver to create its own mappings if it wants. Therefore, I think this patch should go in for 2.6.24. If people really think that these operations should not be available to modules, then we can address that separately. Signed-off-by: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com> Cc: Tobias Powalowski <t.powa@gmx.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Takashi Iwai <tiwai@suse.de> Cc: Zachary Amsden <zach@vmware.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/x86')
-rw-r--r--arch/x86/kernel/paravirt_32.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/arch/x86/kernel/paravirt_32.c b/arch/x86/kernel/paravirt_32.c
index 6a80d67c2121..f5000799f8ef 100644
--- a/arch/x86/kernel/paravirt_32.c
+++ b/arch/x86/kernel/paravirt_32.c
@@ -465,8 +465,8 @@ struct pv_mmu_ops pv_mmu_ops = {
};
EXPORT_SYMBOL_GPL(pv_time_ops);
-EXPORT_SYMBOL_GPL(pv_cpu_ops);
-EXPORT_SYMBOL_GPL(pv_mmu_ops);
+EXPORT_SYMBOL (pv_cpu_ops);
+EXPORT_SYMBOL (pv_mmu_ops);
EXPORT_SYMBOL_GPL(pv_apic_ops);
EXPORT_SYMBOL_GPL(pv_info);
EXPORT_SYMBOL (pv_irq_ops);