diff options
author | Jeremy Fitzhardinge <jeremy@goop.org> | 2007-11-28 16:22:11 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-11-29 09:24:55 -0800 |
commit | f97b8954953ba8e692dbb92d99e26b721f7068cd (patch) | |
tree | 96edbfcd901873c7c3094f9829d2db436fba269a | |
parent | b8415ec34fd63c6260497b2f8aaf3ce7a61eaa8a (diff) | |
download | blackbird-op-linux-f97b8954953ba8e692dbb92d99e26b721f7068cd.tar.gz blackbird-op-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>
-rw-r--r-- | arch/x86/kernel/paravirt_32.c | 4 |
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); |