https://bugzilla.novell.com/show_bug.cgi?id=341801 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ro@novell.com, aritger@nvidia.com AssignedTo|bnc-team-screening@forge.provo.novell.com |rohui@nvidia.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341801#c1 --- Comment #1 from Ruediger Oertel 2007-11-15 06:56:07 MST --- the first place in nv.c triggering the use of the symbol "pv_cpu_ops" seems to be around line 1220 in nv.c: pmd = NV_PMD_OFFSET(address, pgd); next one is somewhere in nvidia_init_module, but more further down. BTW: there is a bug in the configure script trying to detect the signature of the function kmem_cache_create. since the wrong number of args only triggers a compiler warning and not an error, the wrong test code succeeds in compilation and the fix there does not help. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341801#c4 --- Comment #4 from Takashi Iwai 2007-11-16 07:14:04 MST --- Well, a trivial but very hackish fix is to undefine CONFIG_PARAVIRT in the driver source code before including kernel headers. Of course, this doesn't guarantee that the resultant driver will ever work properly, but, hey, better than nothing right now. A patch is attached below, which I'm current using now. It includes the fix for i386 build-fix too. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341801#c6 --- Comment #6 from Stefan Dirsch 2007-11-16 08:25:39 MST --- Thanks a lot, Takashi! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341801#c8 --- Comment #8 from Stefan Dirsch 2007-11-16 11:34:52 MST ---

Is it possible to change the export licensing on pv_cpu_ops and pv_mmu_ops? You mean in the SUSE kernel? Not sure if this is possible if it has been changed upstream. Probably not.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341801 User ro@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=341801#c11 --- Comment #11 from Ruediger Oertel 2007-12-12 17:10:19 MST --- looks like the symbol is no longer marked as GPL only: # zgrep "EXPORT_SYMBOL.*pv_mmu_ops" /mirror/kernel/v2.6/testing/patch-2.6.24-rc?.gz /mirror/kernel/v2.6/testing/patch-2.6.24-rc1.gz:+EXPORT_SYMBOL_GPL(pv_mmu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc2.gz:+EXPORT_SYMBOL_GPL(pv_mmu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc3.gz:+EXPORT_SYMBOL_GPL(pv_mmu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc4.gz:+EXPORT_SYMBOL (pv_mmu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc5.gz:+EXPORT_SYMBOL (pv_mmu_ops); # zgrep "EXPORT_SYMBOL.*pv_cpu_ops" /mirror/kernel/v2.6/testing/patch-2.6.24-rc?.gz /mirror/kernel/v2.6/testing/patch-2.6.24-rc1.gz:+EXPORT_SYMBOL_GPL(pv_cpu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc2.gz:+EXPORT_SYMBOL_GPL(pv_cpu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc3.gz:+EXPORT_SYMBOL_GPL(pv_cpu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc4.gz:+EXPORT_SYMBOL (pv_cpu_ops); /mirror/kernel/v2.6/testing/patch-2.6.24-rc5.gz:+EXPORT_SYMBOL (pv_cpu_ops); -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341801 User sndirsch@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=341801#c13 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #13 from Stefan Dirsch 2007-12-12 22:47:58 MST --- http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.24-rc4 commit f97b8954953ba8e692dbb92d99e26b721f7068cd Author: Jeremy Fitzhardinge Date: Wed Nov 28 16:22:11 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 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 Cc: Tobias Powalowski Cc: Christoph Hellwig Cc: Takashi Iwai Cc: Zachary Amsden Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.