lkml.org 
[lkml]   [2016]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup: close FOLL MAP_PRIVATE race"
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

\
 
 \ /
  Last update: 2016-10-21 18:54    [W:0.769 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site