All of lore.kernel.org
 help / color / mirror / Atom feed
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Peter Feiner <pfeiner@google.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	"khlebnikov@yandex-team.ru" <khlebnikov@yandex-team.ru>,
	"a.ryabinin@samsung.com" <a.ryabinin@samsung.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"gorcunov@openvz.org" <gorcunov@openvz.org>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>
Subject: Re: FAILED: patch "[PATCH] proc/pagemap: walk page tables under pte lock" failed to apply to 3.10-stable tree
Date: Sun, 26 Apr 2015 12:53:11 +0200	[thread overview]
Message-ID: <20150426105311.GC5003@kroah.com> (raw)
In-Reply-To: <54F49B56.5040705@google.com>

On Mon, Mar 02, 2015 at 09:18:14AM -0800, Peter Feiner wrote:
> 
> On 03/01/2015 10:28 PM, Naoya Horiguchi wrote:
> >On Sat, Feb 28, 2015 at 02:45:34PM -0800, gregkh@linuxfoundation.org wrote:
> >>The patch below does not apply to the 3.10-stable tree.
> >>If someone wants it applied there, or to any other stable or longterm
> >>tree, then please email the backport, including the original git commit
> >>id to <stable@vger.kernel.org>.
> >Basically a major reason of the conflict is the lack of the following patch:
> >
> >   commit 81d0fa623c5b8dbd5279d9713094b0f9b0a00fb4
> >   Author: Peter Feiner <pfeiner@google.com>
> >   Date:   Thu Oct 9 15:28:32 2014 -0700
> >       mm: softdirty: unmapped addresses between VMAs are clean
> >
> >but unlike for v3.14, v3.10 doesn't have soft_dirty or split pmd lock, so
> >we need some manual resolution to apply 81d0fa623c5b and 05fbf357d941 on
> >top of v3.10.70.
> >
> >I think the resolution might be mainly cosmetic, but I'm not 100% sure that
> >the altered patches (attached) introduce no unstablity.
> >
> >Peter, Konstantin, could you check attached ones and find out whether these
> >patches work fine on v3.10.70?  Or if there is any good reason to skip this
> >backporting safely, that's fine.
> Sorry about sending this patch twice to some of you!
> 
> Naoya, I think those patches look fine. However, since 3.10 doesn't have
> softdirty, the backport of 81d0fa623c5b amounts to a bunch of cruft. I
> recommend applying a modified version of 05fbf357d941 on its own in order to
> keep the stable diff small.
> 
> Signed-off-by: Peter Feiner <pfeiner@google.com>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 65fc60a..fad881b 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -903,7 +903,8 @@ static int pagemap_pte_range(pmd_t *pmd, unsigned long
> addr, unsigned long end,
>  {
>      struct vm_area_struct *vma;
>      struct pagemapread *pm = walk->private;
> -    pte_t *pte;
> +    spinlock_t *ptl;
> +    pte_t *pte, *orig_pte;
>      int err = 0;
>      pagemap_entry_t pme = make_pme(PM_NOT_PRESENT);
> 
> @@ -926,7 +927,9 @@ static int pagemap_pte_range(pmd_t *pmd, unsigned long
> addr, unsigned long end,
> 
>      if (pmd_trans_unstable(pmd))
>          return 0;
> -    for (; addr != end; addr += PAGE_SIZE) {
> +
> +    orig_pte = pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
> +    for (; addr != end; addr += PAGE_SIZE, pte++) {
> 
>          /* check to see if we've left 'vma' behind
>           * and need a new, higher one */
> @@ -939,15 +942,13 @@ static int pagemap_pte_range(pmd_t *pmd, unsigned long
> addr, unsigned long end,
>           * and that it isn't a huge page vma */
>          if (vma && (vma->vm_start <= addr) &&
>              !is_vm_hugetlb_page(vma)) {
> -            pte = pte_offset_map(pmd, addr);
>              pte_to_pagemap_entry(&pme, vma, addr, *pte);
> -            /* unmap before userspace copy */
> -            pte_unmap(pte);
>          }
>          err = add_to_pagemap(addr, &pme, pm);
>          if (err)
> -            return err;
> +            break;
>      }
> +    pte_unmap_unlock(orig_pte, ptl);
> 
>      cond_resched();


Naoya, can you resend these in a format that I can apply them in, after
you are able to test them, if you want them in the older kernel
releases.

thanks,

greg k-h

           reply	other threads:[~2015-04-26 10:53 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <54F49B56.5040705@google.com>]

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=20150426105311.GC5003@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=a.ryabinin@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=gorcunov@openvz.org \
    --cc=khlebnikov@yandex-team.ru \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=pfeiner@google.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 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.