Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1341331 > unrolled thread

[PATCH 3.14 52/70] mm: fix mlock accouting

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2016-02-24 05:20 +0100
Last post2016-02-25 20:40 +0100
Articles 5 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 3.14 52/70] mm: fix mlock accouting Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-02-24 05:20 +0100
    Re: [PATCH 3.14 52/70] mm: fix mlock accouting Luis Henriques <luis.henriques@canonical.com> - 2016-02-25 02:10 +0100
      Re: [PATCH 3.14 52/70] mm: fix mlock accouting Michal Hocko <mhocko@kernel.org> - 2016-02-25 10:10 +0100
        Re: [PATCH 3.14 52/70] mm: fix mlock accouting Jiri Slaby <jslaby@suse.cz> - 2016-02-25 10:50 +0100
        Re: [PATCH 3.14 52/70] mm: fix mlock accouting Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-02-25 20:40 +0100

#1341331 — [PATCH 3.14 52/70] mm: fix mlock accouting

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-02-24 05:20 +0100
Subject[PATCH 3.14 52/70] mm: fix mlock accouting
Message-ID<r5z5D-7tx-1@gated-at.bofh.it>
3.14-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Kirill A. Shutemov <kirill.shutemov@linux.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@linux.intel.com>
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Michel Lespinasse <walken@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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 */

[toc] | [next] | [standalone]


#1342562

FromLuis Henriques <luis.henriques@canonical.com>
Date2016-02-25 02:10 +0100
Message-ID<r5SBk-4Cr-19@gated-at.bofh.it>
In reply to#1341331
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.

Cheers,
--
Luís

> ------------------
> 
> From: Kirill A. Shutemov <kirill.shutemov@linux.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@linux.intel.com>
> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Michel Lespinasse <walken@google.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]


#1343003

FromMichal Hocko <mhocko@kernel.org>
Date2016-02-25 10:10 +0100
Message-ID<r605Q-1As-17@gated-at.bofh.it>
In reply to#1342562
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@linux.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@linux.intel.com>
> > Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Michel Lespinasse <walken@google.com>
> > Acked-by: Michal Hocko <mhocko@suse.com>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1343040

FromJiri Slaby <jslaby@suse.cz>
Date2016-02-25 10:50 +0100
Message-ID<r60Iy-1NY-31@gated-at.bofh.it>
In reply to#1343003
On 02/25/2016, 10:04 AM, Michal Hocko wrote:
> 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.

Ok, dropping from 3.12 for the same reason too.

-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]


#1343433

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-02-25 20:40 +0100
Message-ID<r69Vw-9g-13@gated-at.bofh.it>
In reply to#1343003
On Thu, Feb 25, 2016 at 10:04:37AM +0100, Michal Hocko wrote:
> 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.

Ok, now dropped, thanks.

greg k-h

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web