Commit:     f97b8954953ba8e692dbb92d99e26b721f7068cd
Parent:     b8415ec34fd63c6260497b2f8aaf3ce7a61eaa8a
Author:     Jeremy Fitzhardinge <[EMAIL PROTECTED]>
AuthorDate: Wed Nov 28 16:22:11 2007 -0800
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Thu Nov 29 09:24:55 2007 -0800

    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 <[EMAIL PROTECTED]> 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 
       no benefit in preventing modules from using standard interfaces.  And it 
       reasonable to allow a graphics driver to create its own mappings if it 
    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 <[EMAIL PROTECTED]>
    Cc: Tobias Powalowski <[EMAIL PROTECTED]>
    Cc: Christoph Hellwig <[EMAIL PROTECTED]>
    Cc: Takashi Iwai <[EMAIL PROTECTED]>
    Cc: Zachary Amsden <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
 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 6a80d67..f500079 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    (pv_cpu_ops);
+EXPORT_SYMBOL    (pv_mmu_ops);
 EXPORT_SYMBOL    (pv_irq_ops);
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to