Correct way to release get_user_pages()?

Correct way to release get_user_pages()?

[Roland Dreier]

Reading through the tree, I see that some callers of get_user_pages()
release the pages that they got via put_page(), and some callers use
page_cache_release().  Of course <linux/pagemap.h> has

	#define page_cache_release(page)      put_page(page)

so this is really not much of a difference, but I'd like to know which
is considered better style.  Any opinions?

Thanks,
  Roland

Re: Correct way to release get_user_pages()?

[Timur Tabi]

Roland Dreier wrote:

> Reading through the tree, I see that some callers of get_user_pages()
> release the pages that they got via put_page(), and some callers use
> page_cache_release().  Of course <linux/pagemap.h> has
> 
> 	#define page_cache_release(page)      put_page(page)
> 
> so this is really not much of a difference, but I'd like to know which
> is considered better style.  Any opinions?

I've defined this function.  I'm not sure if it really works, but it 
looks good.

#include <linux/pagemap.h>

void put_user_pages(int len, struct page **pages)
{
         int i;

         for (i=0; i<len; i++) {
                 if (!PageReserved(pages[i])) {
                         SetPageDirty(pages[i]);
                 }
                 page_cache_release(pages[i]);
         }
}

-- 
Timur Tabi
Staff Software Engineer
timur.tabi@ammasso.com

Re: Correct way to release get_user_pages()?

[Andrew Morton]

Timur Tabi <timur.tabi@ammasso.com> wrote:
>
>  Roland Dreier wrote:
> 
>  > Reading through the tree, I see that some callers of get_user_pages()
>  > release the pages that they got via put_page(), and some callers use
>  > page_cache_release().  Of course <linux/pagemap.h> has
>  > 
>  > 	#define page_cache_release(page)      put_page(page)
>  > 
>  > so this is really not much of a difference, but I'd like to know which
>  > is considered better style.  Any opinions?

I guess we should only use page_cache_release() if the page is known to be
pagecache.  In the case of get_user_pages() the page could of course be
anonymous in which case put_page is probably more appropriate.  It's all a
bit of a mess and if we ever do end up having PAGE_CACHE_SIZE > PAGE_SIZE,
someone will have some work to do.

I suppose put_page() would be better for now.

>  I've defined this function.  I'm not sure if it really works, but it 
>  looks good.
> 
>  #include <linux/pagemap.h>
> 
>  void put_user_pages(int len, struct page **pages)
>  {
>           int i;
> 
>           for (i=0; i<len; i++) {
>                   if (!PageReserved(pages[i])) {
>                           SetPageDirty(pages[i]);
>                   }
>                   page_cache_release(pages[i]);
>           }
>  }

no...  You should only dirty the page if it was modified, and then use
set_page_dirty() or set_page_dirty_lock().

See dio_bio_complete() for an example.

Re: Correct way to release get_user_pages()?

[Timur Tabi]

Andrew Morton wrote:

> no...  You should only dirty the page if it was modified, and then use
> set_page_dirty() or set_page_dirty_lock().

If the page was modified, then shouldn't it already be marked dirty?

Also, should I always use set_page_dirty_lock() if I haven't already 
locked the page?


-- 
Timur Tabi
Staff Software Engineer
timur.tabi@ammasso.com

Re: Correct way to release get_user_pages()?

[Andrew Morton]

Timur Tabi <timur.tabi@ammasso.com> wrote:
>
> Andrew Morton wrote:
> 
> > no...  You should only dirty the page if it was modified, and then use
> > set_page_dirty() or set_page_dirty_lock().
> 
> If the page was modified, then shouldn't it already be marked dirty?

If the page is modified by a DMA transfer or by the CPU via the kernel's
page mappings then there is no record of its having been altered.  Which is
why we must do it in software.

> Also, should I always use set_page_dirty_lock() if I haven't already 
> locked the page?

If you don't have a reference on the page's inode, yes, you should use
set_page_dirty_lock().  If the page came from get_user_pages() then surely
you don't have a ref on the inode.