[patch] vmalloc_to_page() backport for 2.4

[patch] vmalloc_to_page() backport for 2.4

[Gerd Knorr]

  Hi,

This is a 2.4.x backport of the new 2.5.x vmalloc_to_page() function.
I'd like to see that function in 2.4.x too because it makes driver
maintaining easier.

  Gerd

==============================[ cut here ]==============================
--- linux-2.4.19-pre3/include/linux/mm.h	Tue Mar 12 09:59:02 2002
+++ linux/include/linux/mm.h	Tue Mar 12 18:15:02 2002
@@ -670,6 +670,8 @@
 
 extern struct vm_area_struct *find_extend_vma(struct mm_struct *mm, unsigned long addr);
 
+extern struct page * vmalloc_to_page(void *addr);
+
 #endif /* __KERNEL__ */
 
 #endif
--- linux-2.4.19-pre3/kernel/ksyms.c	Tue Mar 12 10:00:44 2002
+++ linux/kernel/ksyms.c	Tue Mar 12 10:00:44 2002
@@ -108,6 +108,7 @@
 EXPORT_SYMBOL(kfree);
 EXPORT_SYMBOL(vfree);
 EXPORT_SYMBOL(__vmalloc);
+EXPORT_SYMBOL_GPL(vmalloc_to_page);
 EXPORT_SYMBOL(mem_map);
 EXPORT_SYMBOL(remap_page_range);
 EXPORT_SYMBOL(max_mapnr);
--- linux-2.4.19-pre3/mm/memory.c	Tue Mar 12 09:59:02 2002
+++ linux/mm/memory.c	Tue Mar 12 10:00:44 2002
@@ -1471,3 +1471,24 @@
 			len, write, 0, NULL, NULL);
 	return ret == len ? 0 : -1;
 }
+
+struct page * vmalloc_to_page(void * vmalloc_addr)
+{
+	unsigned long addr = (unsigned long) vmalloc_addr;
+	struct page *page = NULL;
+	pmd_t *pmd;
+	pte_t *pte;
+	pgd_t *pgd;
+	
+	pgd = pgd_offset_k(addr);
+	if (!pgd_none(*pgd)) {
+		pmd = pmd_offset(pgd, addr);
+		if (!pmd_none(*pmd)) {
+			pte = pte_offset(pmd, addr);
+			if (pte_present(*pte)) {
+				page = pte_page(*pte);
+			}
+		}
+	}
+	return page;
+}

Re: [patch] vmalloc_to_page() backport for 2.4

[Tigran Aivazian]

On Wed, 13 Mar 2002, Gerd Knorr wrote:
> +EXPORT_SYMBOL_GPL(vmalloc_to_page);

Can you (or whoever made it EXPORT_SYMBOL_GPL in 2.5) please explain what
is so "GPL" about exporting this symbol, please? I can understand when
symbols related to the internals of some subsystem are GPL-only-exported
but this does not appear to be such a case.

Regards
Tigran

Re: [patch] vmalloc_to_page() backport for 2.4

[Alan Cox]

> On Wed, 13 Mar 2002, Gerd Knorr wrote:
> > +EXPORT_SYMBOL_GPL(vmalloc_to_page);
> 
> Can you (or whoever made it EXPORT_SYMBOL_GPL in 2.5) please explain what
> is so "GPL" about exporting this symbol, please? I can understand when
> symbols related to the internals of some subsystem are GPL-only-exported
> but this does not appear to be such a case.

Its an internal helper function shared by some GPL drivers, its not something
you need to register a non free driver. As such its simply in the kernel
core rather than duplicated for the convenience of free driver authors.

Alan

Re: [patch] vmalloc_to_page() backport for 2.4

[Tigran Aivazian]

Greetings Alan,

On Wed, 13 Mar 2002, Alan Cox wrote:

> > On Wed, 13 Mar 2002, Gerd Knorr wrote:
> > > +EXPORT_SYMBOL_GPL(vmalloc_to_page);
> >
> > Can you (or whoever made it EXPORT_SYMBOL_GPL in 2.5) please explain what
> > is so "GPL" about exporting this symbol, please? I can understand when
> > symbols related to the internals of some subsystem are GPL-only-exported
> > but this does not appear to be such a case.
>
> Its an internal helper function shared by some GPL drivers, its not something
> you need to register a non free driver. As such its simply in the kernel
> core rather than duplicated for the convenience of free driver authors.

Thank you for answering my query, but one may disagree that it is an
internal helper function because it can conceivably be used by modules to
help them be independent of PAE/non-PAE kernel configuration. And, as
such, it suggests that the _GPL bit in the export clause is not justified
and should be removed. There is no reason whatsoever why Linux base kernel
should allow some useful functionality to GPL modules and disallow the
same to non-GPL ones.

In other words, your statement is absolutely correct when applied to other
EXPORT_SYMBOL_GPL symbols but, imho, is incorrect when applied to this
particular one.

I cc'd Arjan because, perhaps, he has some other technical reasons why it
is _GPL'd, in which case my query would be covered completely. (Obviously,
being unfriendly to non-GPL modules is not a valid technical reason :)

(note, that despite me writing this email as @veritas.com we don't
actually need this symbol to be _GPL but if I believe something is not
right I feel it is my duty to say so -- maybe it helps someone else in the
future, if not directly ourselves now)

Regards,
Tigran

Re: [patch] vmalloc_to_page() backport for 2.4

[Tigran Aivazian]

On Thu, 14 Mar 2002, Tigran Aivazian wrote:
> (note, that despite me writing this email as @veritas.com we don't
> actually need this symbol to be _GPL but if I believe something is not

me switching "yes" and "no" again. I meant "we don't need this to be
_without_ _GPL", i.e. we are happy either way. It just doesn't seem right,
that is all.

Re: [patch] vmalloc_to_page() backport for 2.4

[David Woodhouse]

tigran@veritas.com said:
> And, as such, it suggests that the _GPL bit in the export clause is
> not justified and should be removed. There is no reason whatsoever why
> Linux base kernel should allow some useful functionality to GPL
> modules and disallow the same to non-GPL ones.

You offer no reason why the routine in question _should_ be exported for use
by binary-only modules. EXPORT_SYMBOL_GPL() was invented to allow authors of
code to make their intentions clear; if you disagree with the decision in
this case then either take it up in private with the author of this code, or
switch to BSD, which doesn't suffer from this pesky GPL-thingy.

--
dwmw2

Re: [patch] vmalloc_to_page() backport for 2.4

[Alan Cox]

> help them be independent of PAE/non-PAE kernel configuration. And, as
> such, it suggests that the _GPL bit in the export clause is not justified
> and should be removed. There is no reason whatsoever why Linux base kernel
> should allow some useful functionality to GPL modules and disallow the
> same to non-GPL ones.

I disagree. The code in question is GPL code from a GPL driver or three that
was used internally in those drivers. It is now available for those drivers
to share. If you aren't writing a GPL module you can go write your own 
version of it, just like people have always had to before. 

Similarly the PAE/non-PAE thing is a red herring. Given that even basic
data types change size on pae no module is going to be magically pae/non-pae
clean if its binary only.

Alan

Re: [patch] vmalloc_to_page() backport for 2.4

[Hugh Dickins]

On Thu, 14 Mar 2002, Alan Cox wrote:
> 
> Similarly the PAE/non-PAE thing is a red herring. Given that even basic
> data types change size on pae no module is going to be magically pae/non-pae
> clean if its binary only.

Few modules take an interest in ptes, that's as it should be, and so
few modules build to different binaries with CONFIX_X86_PAE off or on
(modulo module versions).  I love vmalloc_to_page because it takes pte
dependence out of a group of modules which really had no interest in
ptes in the first place.  Less false grep hits when searching the tree!

Hugh

Re: [patch] vmalloc_to_page() backport for 2.4

[Arjan van de Ven]

On Thu, Mar 14, 2002 at 02:46:39PM +0000, Hugh Dickins wrote:
> On Thu, 14 Mar 2002, Alan Cox wrote:
> > 
> > Similarly the PAE/non-PAE thing is a red herring. Given that even basic
> > data types change size on pae no module is going to be magically pae/non-pae
> > clean if its binary only.
> 
> Few modules take an interest in ptes, that's as it should be, and so
> few modules build to different binaries with CONFIX_X86_PAE off or on
> (modulo module versions).

Well dma_addr_t and some others also change size..... struct page also
changes quite a bit

Re: [patch] vmalloc_to_page() backport for 2.4

[Hugh Dickins]

On Tue, 19 Mar 2002, Arjan van de Ven wrote:
> On Thu, Mar 14, 2002 at 02:46:39PM +0000, Hugh Dickins wrote:
> > 
> > Few modules take an interest in ptes, that's as it should be, and so
> > few modules build to different binaries with CONFIG_X86_PAE off or on
> > (modulo module versions).
> 
> Well dma_addr_t and some others also change size..... struct page also
> changes quite a bit

I believe it's CONFIG_HIGHMEM you're thinking of there: dma_addr_t
and struct page do depend on CONFIG_NOHIGHMEM/CONFIG_HIGHMEM in recent
kernels, but not on CONFIG_HIGHMEM4G/CONFIG_HIGHMEM64G(CONFIG_X86_PAE).

I don't know why it's CONFIG_HIGHMEM rather than CONFIG_HIGHMEM64G
that decides the u64-ness dma_addr_t.  There is a dmaaddr_high_t
which behaves more expectedly, but it's not so widely used.

Hugh