From: Brian Norris <briannorris@chromium.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Phil not Paul Oester <kernel@linuxace.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Willy Tarreau <w@1wt.eu>, Guenter Roeck <linux@roeck-us.net>,
Kees Cook <keescook@chromium.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup: close FOLL MAP_PRIVATE race"
Date: Fri, 21 Oct 2016 09:53:39 -0700 [thread overview]
Message-ID: <20161021165339.GA6072@localhost> (raw)
In-Reply-To: <20161021064602.GD6045@dhcp22.suse.cz>
Hi Michal,
On Fri, Oct 21, 2016 at 08:46:02AM +0200, Michal Hocko wrote:
> On Thu 20-10-16 23:39:39, Brian Norris wrote:
> > I'm not sure the best way to report this, but the Chrome OS test
> > infrastructure noticed some problems when testing the following patch
> > backported to our 3.8 kernels:
> >
> > http://www.spinics.net/lists/stable/msg147998.html
> >
> > Specifically (if you can hold your nose and stand Gerrit), this change:
> >
> > https://chromium-review.googlesource.com/#/c/401041/
To be clear to any other readers, the above link has been updated with a
new version. The version in question at the time of the original writing
(and Michal's response) is preserved at this URL:
https://chromium-review.googlesource.com/#/c/401041/2
> This is not correct. You have
> https://chromium-review.googlesource.com/#/c/401041/2/mm/memory.c
>
> f ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, page, flags)) {
> pte_unmap_unlock(ptep, ptl);
> goto no_page;
> }
>
> so you do a double unlock. See how my patch does
> + if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, page, flags)) {
> + pte_unmap_unlock(ptep, ptl);
> + return NULL;
> + }
Wow, indeed we do have a double unlock. Sorry for not reading the
backport more closely :( But thanks a bunch for the tip -- obvious in
retrospect. Will give that a go.
Also, I could have inferred that if it was so simple to crash the
system, that there *had* to simply be something wrong with our patch,
not with the patch you had (presumably tested and) posted.
Sorry for the noise, and thanks again.
Brian
prev parent reply other threads:[~2016-10-21 16:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 6:39 [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup: close FOLL MAP_PRIVATE race" Brian Norris
2016-10-21 6:46 ` Michal Hocko
2016-10-21 16:53 ` Brian Norris [this message]
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=20161021165339.GA6072@localhost \
--to=briannorris@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel@linuxace.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/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.