All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Murzin <murzin.v@gmail.com>
To: Jianyu Zhan <nasa4836@gmail.com>
Cc: akpm@linux-foundation.org, iamjoonsoo.kim@lge.com,
	zhangyanfei@cn.fujitsu.com, rientjes@google.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH]mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page}
Date: Sun, 1 Dec 2013 19:23:55 +0100	[thread overview]
Message-ID: <20131201182349.GA1847@hp530> (raw)
In-Reply-To: <20131128181114.GA5154@lcx>

On Fri, Nov 29, 2013 at 02:11:14AM +0800, Jianyu Zhan wrote:
> 
> Hi, Vladimir,
> 
> On Fri, Nov 29, 2013 at 1:41 AM, Vladimir Murzin <murzin.v@gmail.com> wrote:
> >
> > Any numbers for efficiency?
> >
> 
> For the original implementation, vmalloc_to_pfn() wraps the vmalloc_to_page(),
> which means
> 
>      pfn   ------>         struct page      ------>    pfn
>       |                                                          |
>   vmalloc_to_page()                             vmalloc_to_pfn()
> 
> So this patch interchange the implementation, do the dirty page table
> walking code in vmalloc_to_pfn(), and then vmalloc_to_page() uses it, the graph
> now becomes
> 
>      pfn            ------>         struct page        
>        |                                     |
>   vmalloc_to_pfn()         vmalloc_to_page()
> 
> 
> >>  /*
> >> - * Walk a vmap address to the struct page it maps.
> >> + * Walk a vmap address to the physical pfn it maps to.
> >>   */
> >> -struct page *vmalloc_to_page(const void *vmalloc_addr)
> >> +unsigned long vmalloc_to_pfn(const void *vmalloc_addr)
> >>  {
> >>       unsigned long addr = (unsigned long) vmalloc_addr;
> >> -     struct page *page = NULL;
> >> +     unsigned long pfn;
> >
> > uninitialized pfn will lead to a bug.
> >
> 
> Why? The coding pratice has mandates we use it after we initialize it,
> And if we initialize it , to what value will it promise no bug?

Unless you initialize it conditionally. I bet gcc warned you about this ;)

> It is unlikely a rubbish initial value will creep in.
> 
> 
> >>       /*
> >> @@ -244,23 +244,23 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
> >>                               ptep = pte_offset_map(pmd, addr);
> >>                               pte = *ptep;
> >>                               if (pte_present(pte))
> >> -                                     page = pte_page(pte);
> >> +                                     pfn = pte_page(pte);
> >
> > page_to_pfn is missed here.
> >
> > Have you ever tested there is no functional changes?
> 
> Oh, gods. My fault. It did has no functional changes.
> 
> I just sent the incorrect patch...
> 
> it should be  
>  -   page = pte_page(pte);
>  +  pfn = pte_pfn(pte);;
> 
> Here is the resent patch:
> 

I think it is incorrect too. Originally, vmalloc_to_page might return NULL
under some conditions. With your implementation it will return pfn_to_page(0)
which is not the same as NULL.

Vladimir

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

  reply	other threads:[~2013-12-01 18:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28 18:11 [PATCH]mm/vmalloc: interchage the implementation of vmalloc_to_{pfn,page} Jianyu Zhan
2013-12-01 18:23 ` Vladimir Murzin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-11-28 16:29 Jianyu Zhan
2013-11-28 16:29 ` Jianyu Zhan
2013-11-28 17:41 ` Vladimir Murzin
2013-11-28 17:41   ` Vladimir Murzin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131201182349.GA1847@hp530 \
    --to=murzin.v@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nasa4836@gmail.com \
    --cc=rientjes@google.com \
    --cc=zhangyanfei@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.