linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Revert "mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page}"
@ 2014-01-23 16:27 malc
  2014-01-23 22:49 ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: malc @ 2014-01-23 16:27 UTC (permalink / raw)
  To: linux-mm; +Cc: linux-kernel

Sep 17 00:00:00 2001
From: Vladimir Murzin <murzin.v@gmail.com>
Date: Thu, 23 Jan 2014 14:54:20 +0400
Subject: [PATCH] Revert "mm/vmalloc: interchage the implementation of
 vmalloc_to_{pfn,page}"

This reverts commit ece86e222db48d04bda218a2be70e384518bb08c.

Despite being claimed that patch doesn't introduce any functional
changes in fact it does.

The "no page" path behaves different now. Originally, vmalloc_to_page
might return NULL under some conditions, with new implementation it returns
pfn_to_page(0) which is not the same as NULL.

Simple test shows the difference.

test.c

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/vmalloc.h>
#include <linux/mm.h>

int __init myi(void)
{
	struct page *p;
	void *v;

	v = vmalloc(PAGE_SIZE);
	/* trigger the "no page" path in vmalloc_to_page*/
	vfree(v);

	p = vmalloc_to_page(v);

	pr_err("expected val = NULL, returned val = %p", p);

	return -EBUSY;
}

void __exit mye(void)
{

}
module_init(myi)
module_exit(mye)

Before interchange:
expected val = NULL, returned val =   (null)

After interchange:
expected val = NULL, returned val = c7ebe000

Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Cc: Jianyu Zhan <nasa4836@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
---

I'm a bit surprised to see this patch merged because I've already pointed [1]
at difference in behaviour introduced by the patch.

If I've lost the point here or misunderstand the patch or abuse vmalloc_to_*
interface I'd be grateful if someone let me know.

[1] https://lkml.org/lkml/2013/12/1/76

Thanks
Vladimir


 mm/vmalloc.c |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index e4f0db2..0fdf968 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -220,12 +220,12 @@ int is_vmalloc_or_module_addr(const void *x)
 }
 
 /*
- * Walk a vmap address to the physical pfn it maps to.
+ * Walk a vmap address to the struct page it maps.
  */
-unsigned long vmalloc_to_pfn(const void *vmalloc_addr)
+struct page *vmalloc_to_page(const void *vmalloc_addr)
 {
 	unsigned long addr = (unsigned long) vmalloc_addr;
-	unsigned long pfn = 0;
+	struct page *page = NULL;
 	pgd_t *pgd = pgd_offset_k(addr);
 
 	/*
@@ -244,23 +244,23 @@ unsigned long vmalloc_to_pfn(const void *vmalloc_addr)
 				ptep = pte_offset_map(pmd, addr);
 				pte = *ptep;
 				if (pte_present(pte))
-					pfn = pte_pfn(pte);
+					page = pte_page(pte);
 				pte_unmap(ptep);
 			}
 		}
 	}
-	return pfn;
+	return page;
 }
-EXPORT_SYMBOL(vmalloc_to_pfn);
+EXPORT_SYMBOL(vmalloc_to_page);
 
 /*
- * Map a vmalloc()-space virtual address to the struct page.
+ * Map a vmalloc()-space virtual address to the physical page frame number.
  */
-struct page *vmalloc_to_page(const void *vmalloc_addr)
+unsigned long vmalloc_to_pfn(const void *vmalloc_addr)
 {
-	return pfn_to_page(vmalloc_to_pfn(vmalloc_addr));
+	return page_to_pfn(vmalloc_to_page(vmalloc_addr));
 }
-EXPORT_SYMBOL(vmalloc_to_page);
+EXPORT_SYMBOL(vmalloc_to_pfn);
 
 
 /*** Global kva allocator ***/
-- 
1.7.10.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Revert "mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page}"
  2014-01-23 16:27 [PATCH] Revert "mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page}" malc
@ 2014-01-23 22:49 ` Andrew Morton
  2014-01-24  6:54   ` Vladimir Murzin
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2014-01-23 22:49 UTC (permalink / raw)
  To: malc; +Cc: linux-mm, linux-kernel, Jianyu Zhan

On Thu, 23 Jan 2014 20:27:29 +0400 (MSK) malc <av1474@comtv.ru> wrote:

> Sep 17 00:00:00 2001
> From: Vladimir Murzin <murzin.v@gmail.com>
> Date: Thu, 23 Jan 2014 14:54:20 +0400
> Subject: [PATCH] Revert "mm/vmalloc: interchage the implementation of
>  vmalloc_to_{pfn,page}"
> 
> This reverts commit ece86e222db48d04bda218a2be70e384518bb08c.
> 
> Despite being claimed that patch doesn't introduce any functional
> changes in fact it does.
> 
> The "no page" path behaves different now. Originally, vmalloc_to_page
> might return NULL under some conditions, with new implementation it returns
> pfn_to_page(0) which is not the same as NULL.
> 
> Simple test shows the difference.
> 
> test.c
> 
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/vmalloc.h>
> #include <linux/mm.h>
> 
> int __init myi(void)
> {
> 	struct page *p;
> 	void *v;
> 
> 	v = vmalloc(PAGE_SIZE);
> 	/* trigger the "no page" path in vmalloc_to_page*/
> 	vfree(v);
> 
> 	p = vmalloc_to_page(v);
> 
> 	pr_err("expected val = NULL, returned val = %p", p);
> 
> 	return -EBUSY;
> }
> 
> void __exit mye(void)
> {
> 
> }
> module_init(myi)
> module_exit(mye)
> 
> Before interchange:
> expected val = NULL, returned val =   (null)
> 
> After interchange:
> expected val = NULL, returned val = c7ebe000
> 

hm, yes, I suppose that's bad.

Rather than reverting the patch we could fix up vmalloc_to_pfn() and/or
vmalloc_to_page() to handle this situation.  Did you try that?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Revert "mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page}"
  2014-01-23 22:49 ` Andrew Morton
@ 2014-01-24  6:54   ` Vladimir Murzin
  0 siblings, 0 replies; 3+ messages in thread
From: Vladimir Murzin @ 2014-01-24  6:54 UTC (permalink / raw)
  To: Andrew Morton; +Cc: malc, linux-mm, LKML, Jianyu Zhan

Hi Andrew

On Fri, Jan 24, 2014 at 2:49 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 23 Jan 2014 20:27:29 +0400 (MSK) malc <av1474@comtv.ru> wrote:
>
>> Sep 17 00:00:00 2001
>> From: Vladimir Murzin <murzin.v@gmail.com>
>> Date: Thu, 23 Jan 2014 14:54:20 +0400
>> Subject: [PATCH] Revert "mm/vmalloc: interchage the implementation of
>>  vmalloc_to_{pfn,page}"
>>
>> This reverts commit ece86e222db48d04bda218a2be70e384518bb08c.
>>
>> Despite being claimed that patch doesn't introduce any functional
>> changes in fact it does.
>>
>> The "no page" path behaves different now. Originally, vmalloc_to_page
>> might return NULL under some conditions, with new implementation it returns
>> pfn_to_page(0) which is not the same as NULL.
>>
>> Simple test shows the difference.
>>
>> test.c
>>
>> #include <linux/kernel.h>
>> #include <linux/module.h>
>> #include <linux/vmalloc.h>
>> #include <linux/mm.h>
>>
>> int __init myi(void)
>> {
>>       struct page *p;
>>       void *v;
>>
>>       v = vmalloc(PAGE_SIZE);
>>       /* trigger the "no page" path in vmalloc_to_page*/
>>       vfree(v);
>>
>>       p = vmalloc_to_page(v);
>>
>>       pr_err("expected val = NULL, returned val = %p", p);
>>
>>       return -EBUSY;
>> }
>>
>> void __exit mye(void)
>> {
>>
>> }
>> module_init(myi)
>> module_exit(mye)
>>
>> Before interchange:
>> expected val = NULL, returned val =   (null)
>>
>> After interchange:
>> expected val = NULL, returned val = c7ebe000
>>
>
> hm, yes, I suppose that's bad.
>
> Rather than reverting the patch we could fix up vmalloc_to_pfn() and/or
> vmalloc_to_page() to handle this situation.  Did you try that?
>

Personally, I didn't try; I leaved this responsibility to the author
of the patch
as a review feedback. Unfortunately, there was no any response.

Being said that original patch makes vmalloc_to_* "slightly more efficient",
I'm in doubt that with additional handling it'd still improve something. I'd be
very glad if someone point me at the benefit of the patch - just to have an
idea why we need to put extra effort here.

Thanks
Vladimir

> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-01-24  6:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-23 16:27 [PATCH] Revert "mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page}" malc
2014-01-23 22:49 ` Andrew Morton
2014-01-24  6:54   ` Vladimir Murzin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox