vmalloc_to_page() backport for 2.4

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 ]==============================

@@ -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

@@ -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);

@@ -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;
+}

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

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

Greetings Alan,

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

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.

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

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

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

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