linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ajay Kaher <akaher@vmware.com>
To: Vlastimil Babka <vbabka@suse.cz>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jann Horn <jannh@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	"stable@kernel.org" <stable@kernel.org>,
	Srivatsa Bhat <srivatsab@vmware.com>,
	"srivatsa@csail.mit.edu" <srivatsa@csail.mit.edu>,
	Vasavi Sirnapalli <vsirnapalli@vmware.com>
Subject: Re: [PATCH STABLE 4.4 5/8] mm: prevent get_user_pages() from overflowing page refcount
Date: Tue, 3 Dec 2019 12:25:24 +0000	[thread overview]
Message-ID: <519D18AF-DD01-4107-96D2-D8E33058B2CB@vmware.com> (raw)
In-Reply-To: <20191108093814.16032-6-vbabka@suse.cz>



On 08/11/19, 3:08 PM, "Vlastimil Babka" <vbabka@suse.cz> wrote:

> From: Linus Torvalds <torvalds@linux-foundation.org>
> 
> commit 8fde12ca79aff9b5ba951fce1a2641901b8d8e64 upstream.
>    
> [ 4.4 backport: there's get_page_foll(), so add try_get_page()-like checks
>                 in there, enabled by a new parameter, which is false where
>                 upstream patch doesn't replace get_page() with try_get_page()
>                 (the THP and hugetlb callers).

Could we have try_get_page_foll(), as in:
https://lore.kernel.org/stable/1570581863-12090-3-git-send-email-akaher@vmware.com/

+ Code will be in sync as we have try_get_page()
+ No need to add extra argument to try_get_page()
+ No need to modify the callers of try_get_page()

>		In gup_pte_range(), we don't expect tail pages, so just check
>                 page ref count instead of try_get_compound_head()

Technically it's fine. If you want to keep the code of stable versions in sync
with latest versions then this could be done in following ways (without any
modification in upstream patch for gup_pte_range()):

Apply 7aef4172c7957d7e65fc172be4c99becaef855d4 before applying
8fde12ca79aff9b5ba951fce1a2641901b8d8e64, as done here:
https://lore.kernel.org/stable/1570581863-12090-4-git-send-email-akaher@vmware.com/

> 		Also patch arch-specific variants of gup.c for x86 and s390,
> 		leaving mips, sh, sparc alone				      ]
> 
    
> ---
>  arch/s390/mm/gup.c |  6 ++++--
>  arch/x86/mm/gup.c  |  9 ++++++++-
>  mm/gup.c           | 39 +++++++++++++++++++++++++++++++--------
>  mm/huge_memory.c   |  2 +-
>  mm/hugetlb.c       | 18 ++++++++++++++++--
>  mm/internal.h      | 12 +++++++++---
>  6 files changed, 69 insertions(+), 17 deletions(-)
>    
> #ifdef __HAVE_ARCH_PTE_SPECIAL
>  static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
>  			 int write, struct page **pages, int *nr)
> @@ -1083,6 +1103,9 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
>  		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
> 		page = pte_page(pte);
>  
> +		if (WARN_ON_ONCE(page_ref_count(page) < 0))
> +			goto pte_unmap;
> +
>  		if (!page_cache_get_speculative(page))
>  			goto pte_unmap;


 
> diff --git a/mm/internal.h b/mm/internal.h
> index a6639c72780a..b52041969d06 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -93,23 +93,29 @@ static inline void __get_page_tail_foll(struct page *page,
>   * follow_page() and it must be called while holding the proper PT
>   * lock while the pte (or pmd_trans_huge) is still mapping the page.
>   */
> -static inline void get_page_foll(struct page *page)
> +static inline bool get_page_foll(struct page *page, bool check)
>  {
> -	if (unlikely(PageTail(page)))
> +	if (unlikely(PageTail(page))) {
>  		/*
>  		 * This is safe only because
>  		 * __split_huge_page_refcount() can't run under
>  		 * get_page_foll() because we hold the proper PT lock.
>  		 */
> +		if (check && WARN_ON_ONCE(
> +				page_ref_count(compound_head(page)) <= 0))
> +			return false;
>  		__get_page_tail_foll(page, true);
> -	else {
> +	} else {
>  		/*
>  		 * Getting a normal page or the head of a compound page
>  		 * requires to already have an elevated page->_count.
>  		 */
>  		VM_BUG_ON_PAGE(page_ref_zero_or_close_to_overflow(page), page);
> +		if (check && WARN_ON_ONCE(page_ref_count(page) <= 0))
> +			return false;
>  		atomic_inc(&page->_count);
>  	}
> +	return true;
>  }
    
    


  reply	other threads:[~2019-12-03 12:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08  9:38 [PATCH STABLE 4.4 0/8] page refcount overflow backports Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 1/8] mm, gup: remove broken VM_BUG_ON_PAGE compound check for hugepages Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 2/8] mm, gup: ensure real head page is ref-counted when using hugepages Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 3/8] mm: make page ref count overflow check tighter and more explicit Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 4/8] mm: add 'try_get_page()' helper function Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 5/8] mm: prevent get_user_pages() from overflowing page refcount Vlastimil Babka
2019-12-03 12:25   ` Ajay Kaher [this message]
2019-12-03 12:57     ` Vlastimil Babka
2019-12-06  4:15       ` Ajay Kaher
2019-12-06 14:32         ` Vlastimil Babka
2019-12-09  8:54           ` Ajay Kaher
2019-12-09  9:10             ` Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 6/8] pipe: add pipe_buf_get() helper Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 7/8] fs: prevent page refcount overflow in pipe_buf_get Vlastimil Babka
2019-11-08  9:38 ` [PATCH STABLE 4.4 8/8] x86, mm, gup: prevent get_page() race with munmap in paravirt guest Vlastimil Babka

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=519D18AF-DD01-4107-96D2-D8E33058B2CB@vmware.com \
    --to=akaher@vmware.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=srivatsa@csail.mit.edu \
    --cc=srivatsab@vmware.com \
    --cc=stable@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=vsirnapalli@vmware.com \
    --cc=willy@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).