[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160225090437.GB17573@dhcp22.suse.cz>
Date: Thu, 25 Feb 2016 10:04:37 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Luis Henriques <luis.henriques@...onical.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Michel Lespinasse <walken@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 3.14 52/70] mm: fix mlock accouting
On Thu 25-02-16 01:02:59, Luis Henriques wrote:
> On Tue, Feb 23, 2016 at 07:34:01PM -0800, Greg Kroah-Hartman wrote:
> > 3.14-stable review patch. If anyone has any objections, please let me know.
> >
>
> I'm not sure this should be queued for the 3.14 kernel. It is tagged
> for 4.4+ and since in this kernel version __mod_zone_page_state()
> doesn't actually cast nr_pages to long, this patch doesn't seem to be
> required.
Yes, 6cdb18ad98a4 hasn't been backported to 3.14 stable tree. I guess
the 3.14 confusion came from Fixes: ff6a6da60b89 which is true in theory
but wasn't a real problem back then.
> Cheers,
> --
> Luís
>
> > ------------------
> >
> > From: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> >
> > commit 7162a1e87b3e380133dadc7909081bb70d0a7041 upstream.
> >
> > Tetsuo Handa reported underflow of NR_MLOCK on munlock.
> >
> > Testcase:
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <sys/mman.h>
> >
> > #define BASE ((void *)0x400000000000)
> > #define SIZE (1UL << 21)
> >
> > int main(int argc, char *argv[])
> > {
> > void *addr;
> >
> > system("grep Mlocked /proc/meminfo");
> > addr = mmap(BASE, SIZE, PROT_READ | PROT_WRITE,
> > MAP_ANONYMOUS | MAP_PRIVATE | MAP_LOCKED | MAP_FIXED,
> > -1, 0);
> > if (addr == MAP_FAILED)
> > printf("mmap() failed\n"), exit(1);
> > munmap(addr, SIZE);
> > system("grep Mlocked /proc/meminfo");
> > return 0;
> > }
> >
> > It happens on munlock_vma_page() due to unfortunate choice of nr_pages
> > data type:
> >
> > __mod_zone_page_state(zone, NR_MLOCK, -nr_pages);
> >
> > For unsigned int nr_pages, implicitly casted to long in
> > __mod_zone_page_state(), it becomes something around UINT_MAX.
> >
> > munlock_vma_page() usually called for THP as small pages go though
> > pagevec.
> >
> > Let's make nr_pages signed int.
> >
> > Similar fixes in 6cdb18ad98a4 ("mm/vmstat: fix overflow in
> > mod_zone_page_state()") used `long' type, but `int' here is OK for a
> > count of the number of sub-pages in a huge page.
> >
> > Fixes: ff6a6da60b89 ("mm: accelerate munlock() treatment of THP pages")
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> > Reported-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> > Tested-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> > Cc: Michel Lespinasse <walken@...gle.com>
> > Acked-by: Michal Hocko <mhocko@...e.com>
> > Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >
> > ---
> > mm/mlock.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/mm/mlock.c
> > +++ b/mm/mlock.c
> > @@ -172,7 +172,7 @@ static void __munlock_isolation_failed(s
> > */
> > unsigned int munlock_vma_page(struct page *page)
> > {
> > - unsigned int nr_pages;
> > + int nr_pages;
> > struct zone *zone = page_zone(page);
> >
> > /* For try_to_munlock() and to serialize with page migration */
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe stable" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists