[PATCH] Fix __vmalloc(), etc on MIPS for non-GPL modules

[PATCH] Fix __vmalloc(), etc on MIPS for non-GPL modules

[Anton Altaparmakov]

Hi,

The commit 351336929ccf222ae38ff0cb7a8dd5fd5c6236a0 which can be seen 
here:

http://kerneltrap.org/mailarchive/git-commits-head/2008/4/28/1639134

Breaks all non-GPL modules that use __vmalloc() or any of the vmap(), 
vm_map_ram(), etc functions on MIPS architecture.

All those functions are EXPORT_SYMBOL() so are meant to be allowed to be 
used by non-GPL kernel modules.  These calls all take page protection as 
an argument which is normally a constant like PAGE_KERNEL.

This commit causes all protection constants like PAGE_KERNEL to not be 
constants and instead to contain the GPL-only symbol 
_page_cachable_default.

This means that all calls to __vmalloc(), vmap(), etc, cause non-GPL 
modules to fail to link with the complaint that they are trying to use the 
GPL-only symbol _page_cachable_default...

I therefore propose that the EXPORT_SYMBOL_GPL(_page_cachable_default) is 
changed to EXPORT_SYMBOL(_page_cachable_default) to re-instate the 
ability for non-GPL modules to call __vmalloc(), vmap(), vm_map_ram(), 
and such like.

Here is a patch that does this.  If you approve, please apply it.

Thanks a lot in advance for your consideration.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

---
[PATCH] Fix __vmalloc(), vmap(), vm_map_ram(), etc on MIPS for non-GPL modules.

Commit 351336929ccf222ae38ff0cb7a8dd5fd5c6236a0 broke these functions for 
non-GPL modules by causing the page protection constants not to be 
constants any more and instead to include a GPL-only symbol and as these 
functions take a page protection argument this causes them to not be 
callable from non-GPL modules any more even though the functions are 
EXPORT_SYMBOL().

Signed-off-by: Anton Altaparmakov <aia21@cantab.net>

diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index be8627b..12af739 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -133,7 +133,7 @@ void __update_cache(struct vm_area_struct *vma, 
unsigned lon
 }
 
 unsigned long _page_cachable_default;
-EXPORT_SYMBOL_GPL(_page_cachable_default);
+EXPORT_SYMBOL(_page_cachable_default);
 
 static inline void setup_protection_map(void)
 {

Re: [PATCH] Fix __vmalloc(), etc on MIPS for non-GPL modules

[Ralf Baechle]

On Thu, Mar 25, 2010 at 08:48:12PM +0000, Anton Altaparmakov wrote:

> The commit 351336929ccf222ae38ff0cb7a8dd5fd5c6236a0 which can be seen 
> here:

Which was in 2.6.26 ...

> I therefore propose that the EXPORT_SYMBOL_GPL(_page_cachable_default) is 
> changed to EXPORT_SYMBOL(_page_cachable_default) to re-instate the 
> ability for non-GPL modules to call __vmalloc(), vmap(), vm_map_ram(), 
> and such like.
> 
> Here is a patch that does this.  If you approve, please apply it.

I approve - but applying would be easier if this patch had not been
linewrapped ...

Applied to master and -stable.  Thanks!

  Ralf

Re: [PATCH] Fix __vmalloc(), etc on MIPS for non-GPL modules

[Anton Altaparmakov]

Hi Ralf,

On 26 Mar 2010, at 14:52, Ralf Baechle wrote:
> On Thu, Mar 25, 2010 at 08:48:12PM +0000, Anton Altaparmakov wrote:
>> The commit 351336929ccf222ae38ff0cb7a8dd5fd5c6236a0 which can be seen 
>> here:
> 
> Which was in 2.6.26 ...

Yes.  (-:

Embedded companies tend to use very old kernels.  Usually 2.6.10-2.6.18 range.  This is the fist time someone using MIPS architecture came up with a 2.6.27 kernel and linking failed hence my patch.  I only personally test compilation across all kernels (2.6.10-latest) on x86 so I miss things like that happening...

>> I therefore propose that the EXPORT_SYMBOL_GPL(_page_cachable_default) is 
>> changed to EXPORT_SYMBOL(_page_cachable_default) to re-instate the 
>> ability for non-GPL modules to call __vmalloc(), vmap(), vm_map_ram(), 
>> and such like.
>> 
>> Here is a patch that does this.  If you approve, please apply it.
> 
> I approve - but applying would be easier if this patch had not been
> linewrapped ...

Sorry about that!!!  I sent the patch using Pine and thought I was safe on that front but I probably did something wrong.  )))-:

> Applied to master and -stable.  Thanks!

Great, thanks!

Best regards,

	Anton

>  Ralf

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/