2019-05-19 15:08:55 +03:00
// SPDX-License-Identifier: GPL-2.0-only
2008-07-26 06:44:36 +04:00
# include <linux/mm.h>
2006-01-08 12:01:43 +03:00
# include <linux/slab.h>
# include <linux/string.h>
2014-04-08 02:37:26 +04:00
# include <linux/compiler.h>
2011-10-16 10:01:52 +04:00
# include <linux/export.h>
2006-03-24 14:18:42 +03:00
# include <linux/err.h>
2008-07-27 02:22:28 +04:00
# include <linux/sched.h>
2017-02-08 20:51:29 +03:00
# include <linux/sched/mm.h>
2019-07-17 02:30:54 +03:00
# include <linux/sched/signal.h>
2017-02-08 20:51:37 +03:00
# include <linux/sched/task_stack.h>
2012-05-31 04:17:35 +04:00
# include <linux/security.h>
2013-02-23 04:34:35 +04:00
# include <linux/swap.h>
2013-02-23 04:34:37 +04:00
# include <linux/swapops.h>
2013-11-13 03:08:31 +04:00
# include <linux/mman.h>
# include <linux/hugetlb.h>
2014-05-06 22:02:53 +04:00
# include <linux/vmalloc.h>
2017-02-25 01:58:22 +03:00
# include <linux/userfaultfd_k.h>
2019-09-24 01:38:37 +03:00
# include <linux/elf.h>
2019-09-24 01:38:47 +03:00
# include <linux/elf-randomize.h>
# include <linux/personality.h>
2019-09-24 01:38:37 +03:00
# include <linux/random.h>
2019-09-24 01:38:47 +03:00
# include <linux/processor.h>
# include <linux/sizes.h>
# include <linux/compat.h>
2013-11-13 03:08:31 +04:00
2016-12-24 22:46:01 +03:00
# include <linux/uaccess.h>
2006-01-08 12:01:43 +03:00
mm: nommu: sort mm->mmap list properly
When I was reading nommu code, I found that it handles the vma list/tree
in an unusual way. IIUC, because there can be more than one
identical/overrapped vmas in the list/tree, it sorts the tree more
strictly and does a linear search on the tree. But it doesn't applied to
the list (i.e. the list could be constructed in a different order than
the tree so that we can't use the list when finding the first vma in that
order).
Since inserting/sorting a vma in the tree and link is done at the same
time, we can easily construct both of them in the same order. And linear
searching on the tree could be more costly than doing it on the list, it
can be converted to use the list.
Also, after the commit 297c5eee3724 ("mm: make the vma list be doubly
linked") made the list be doubly linked, there were a couple of code need
to be fixed to construct the list properly.
Patch 1/6 is a preparation. It maintains the list sorted same as the tree
and construct doubly-linked list properly. Patch 2/6 is a simple
optimization for the vma deletion. Patch 3/6 and 4/6 convert tree
traversal to list traversal and the rest are simple fixes and cleanups.
This patch:
@vma added into @mm should be sorted by start addr, end addr and VMA
struct addr in that order because we may get identical VMAs in the @mm.
However this was true only for the rbtree, not for the list.
This patch fixes this by remembering 'rb_prev' during the tree traversal
like find_vma_prepare() does and linking the @vma via __vma_link_list().
After this patch, we can iterate the whole VMAs in correct order simply by
using @mm->mmap list.
[akpm@linux-foundation.org: avoid duplicating __vma_link_list()]
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 04:11:22 +04:00
# include "internal.h"
2015-02-14 01:36:24 +03:00
/**
* kfree_const - conditionally free memory
* @ x : pointer to the memory
*
* Function calls kfree only if @ x is not in . rodata section .
*/
void kfree_const ( const void * x )
{
if ( ! is_kernel_rodata ( ( unsigned long ) x ) )
kfree ( x ) ;
}
EXPORT_SYMBOL ( kfree_const ) ;
2006-01-08 12:01:43 +03:00
/**
* kstrdup - allocate space for and copy an existing string
* @ s : the string to duplicate
* @ gfp : the GFP mask used in the kmalloc ( ) call when allocating memory
2019-03-06 02:48:42 +03:00
*
* Return : newly allocated copy of @ s or % NULL in case of error
2006-01-08 12:01:43 +03:00
*/
char * kstrdup ( const char * s , gfp_t gfp )
{
size_t len ;
char * buf ;
if ( ! s )
return NULL ;
len = strlen ( s ) + 1 ;
2006-10-04 13:15:25 +04:00
buf = kmalloc_track_caller ( len , gfp ) ;
2006-01-08 12:01:43 +03:00
if ( buf )
memcpy ( buf , s , len ) ;
return buf ;
}
EXPORT_SYMBOL ( kstrdup ) ;
2006-03-24 14:18:42 +03:00
2015-02-14 01:36:24 +03:00
/**
* kstrdup_const - conditionally duplicate an existing const string
* @ s : the string to duplicate
* @ gfp : the GFP mask used in the kmalloc ( ) call when allocating memory
*
2019-03-06 02:48:42 +03:00
* Note : Strings allocated by kstrdup_const should be freed by kfree_const .
*
* Return : source string if it is in . rodata section otherwise
* fallback to kstrdup .
2015-02-14 01:36:24 +03:00
*/
const char * kstrdup_const ( const char * s , gfp_t gfp )
{
if ( is_kernel_rodata ( ( unsigned long ) s ) )
return s ;
return kstrdup ( s , gfp ) ;
}
EXPORT_SYMBOL ( kstrdup_const ) ;
2007-07-18 05:37:02 +04:00
/**
* kstrndup - allocate space for and copy an existing string
* @ s : the string to duplicate
* @ max : read at most @ max chars from @ s
* @ gfp : the GFP mask used in the kmalloc ( ) call when allocating memory
2017-07-04 19:25:02 +03:00
*
* Note : Use kmemdup_nul ( ) instead if the size is known exactly .
2019-03-06 02:48:42 +03:00
*
* Return : newly allocated copy of @ s or % NULL in case of error
2007-07-18 05:37:02 +04:00
*/
char * kstrndup ( const char * s , size_t max , gfp_t gfp )
{
size_t len ;
char * buf ;
if ( ! s )
return NULL ;
len = strnlen ( s , max ) ;
buf = kmalloc_track_caller ( len + 1 , gfp ) ;
if ( buf ) {
memcpy ( buf , s , len ) ;
buf [ len ] = ' \0 ' ;
}
return buf ;
}
EXPORT_SYMBOL ( kstrndup ) ;
[PATCH] kmemdup: introduce
One of idiomatic ways to duplicate a region of memory is
dst = kmalloc(len, GFP_KERNEL);
if (!dst)
return -ENOMEM;
memcpy(dst, src, len);
which is neat code except a programmer needs to write size twice. Which
sometimes leads to mistakes. If len passed to kmalloc is smaller that len
passed to memcpy, it's straight overwrite-beyond-end. If len passed to
memcpy is smaller than len passed to kmalloc, it's either a) legit
behaviour ;-), or b) cloned buffer will contain garbage in second half.
Slight trolling of commit lists shows several duplications bugs
done exactly because of diverged lenghts:
Linux:
[CRYPTO]: Fix memcpy/memset args.
[PATCH] memcpy/memset fixes
OpenBSD:
kerberosV/src/lib/asn1: der_copy.c:1.4
If programmer is given only one place to play with lengths, I believe, such
mistakes could be avoided.
With kmemdup, the snippet above will be rewritten as:
dst = kmemdup(src, len, GFP_KERNEL);
if (!dst)
return -ENOMEM;
This also leads to smaller code (kzalloc effect). Quick grep shows
200+ places where kmemdup() can be used.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01 10:27:20 +04:00
/**
* kmemdup - duplicate region of memory
*
* @ src : memory region to duplicate
* @ len : memory region length
* @ gfp : GFP mask to use
2019-03-06 02:48:42 +03:00
*
* Return : newly allocated copy of @ src or % NULL in case of error
[PATCH] kmemdup: introduce
One of idiomatic ways to duplicate a region of memory is
dst = kmalloc(len, GFP_KERNEL);
if (!dst)
return -ENOMEM;
memcpy(dst, src, len);
which is neat code except a programmer needs to write size twice. Which
sometimes leads to mistakes. If len passed to kmalloc is smaller that len
passed to memcpy, it's straight overwrite-beyond-end. If len passed to
memcpy is smaller than len passed to kmalloc, it's either a) legit
behaviour ;-), or b) cloned buffer will contain garbage in second half.
Slight trolling of commit lists shows several duplications bugs
done exactly because of diverged lenghts:
Linux:
[CRYPTO]: Fix memcpy/memset args.
[PATCH] memcpy/memset fixes
OpenBSD:
kerberosV/src/lib/asn1: der_copy.c:1.4
If programmer is given only one place to play with lengths, I believe, such
mistakes could be avoided.
With kmemdup, the snippet above will be rewritten as:
dst = kmemdup(src, len, GFP_KERNEL);
if (!dst)
return -ENOMEM;
This also leads to smaller code (kzalloc effect). Quick grep shows
200+ places where kmemdup() can be used.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01 10:27:20 +04:00
*/
void * kmemdup ( const void * src , size_t len , gfp_t gfp )
{
void * p ;
2006-10-04 13:15:25 +04:00
p = kmalloc_track_caller ( len , gfp ) ;
[PATCH] kmemdup: introduce
One of idiomatic ways to duplicate a region of memory is
dst = kmalloc(len, GFP_KERNEL);
if (!dst)
return -ENOMEM;
memcpy(dst, src, len);
which is neat code except a programmer needs to write size twice. Which
sometimes leads to mistakes. If len passed to kmalloc is smaller that len
passed to memcpy, it's straight overwrite-beyond-end. If len passed to
memcpy is smaller than len passed to kmalloc, it's either a) legit
behaviour ;-), or b) cloned buffer will contain garbage in second half.
Slight trolling of commit lists shows several duplications bugs
done exactly because of diverged lenghts:
Linux:
[CRYPTO]: Fix memcpy/memset args.
[PATCH] memcpy/memset fixes
OpenBSD:
kerberosV/src/lib/asn1: der_copy.c:1.4
If programmer is given only one place to play with lengths, I believe, such
mistakes could be avoided.
With kmemdup, the snippet above will be rewritten as:
dst = kmemdup(src, len, GFP_KERNEL);
if (!dst)
return -ENOMEM;
This also leads to smaller code (kzalloc effect). Quick grep shows
200+ places where kmemdup() can be used.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01 10:27:20 +04:00
if ( p )
memcpy ( p , src , len ) ;
return p ;
}
EXPORT_SYMBOL ( kmemdup ) ;
2017-07-04 19:25:02 +03:00
/**
* kmemdup_nul - Create a NUL - terminated string from unterminated data
* @ s : The data to stringify
* @ len : The size of the data
* @ gfp : the GFP mask used in the kmalloc ( ) call when allocating memory
2019-03-06 02:48:42 +03:00
*
* Return : newly allocated copy of @ s with NUL - termination or % NULL in
* case of error
2017-07-04 19:25:02 +03:00
*/
char * kmemdup_nul ( const char * s , size_t len , gfp_t gfp )
{
char * buf ;
if ( ! s )
return NULL ;
buf = kmalloc_track_caller ( len + 1 , gfp ) ;
if ( buf ) {
memcpy ( buf , s , len ) ;
buf [ len ] = ' \0 ' ;
}
return buf ;
}
EXPORT_SYMBOL ( kmemdup_nul ) ;
2009-04-01 02:23:16 +04:00
/**
* memdup_user - duplicate memory region from user space
*
* @ src : source address in user space
* @ len : number of bytes to copy
*
2019-03-06 02:48:42 +03:00
* Return : an ERR_PTR ( ) on failure . Result is physically
2018-01-07 21:06:15 +03:00
* contiguous , to be freed by kfree ( ) .
2009-04-01 02:23:16 +04:00
*/
void * memdup_user ( const void __user * src , size_t len )
{
void * p ;
2019-02-21 09:20:42 +03:00
p = kmalloc_track_caller ( len , GFP_USER | __GFP_NOWARN ) ;
2009-04-01 02:23:16 +04:00
if ( ! p )
return ERR_PTR ( - ENOMEM ) ;
if ( copy_from_user ( p , src , len ) ) {
kfree ( p ) ;
return ERR_PTR ( - EFAULT ) ;
}
return p ;
}
EXPORT_SYMBOL ( memdup_user ) ;
2018-01-07 21:06:15 +03:00
/**
* vmemdup_user - duplicate memory region from user space
*
* @ src : source address in user space
* @ len : number of bytes to copy
*
2019-03-06 02:48:42 +03:00
* Return : an ERR_PTR ( ) on failure . Result may be not
2018-01-07 21:06:15 +03:00
* physically contiguous . Use kvfree ( ) to free .
*/
void * vmemdup_user ( const void __user * src , size_t len )
{
void * p ;
p = kvmalloc ( len , GFP_USER ) ;
if ( ! p )
return ERR_PTR ( - ENOMEM ) ;
if ( copy_from_user ( p , src , len ) ) {
kvfree ( p ) ;
return ERR_PTR ( - EFAULT ) ;
}
return p ;
}
EXPORT_SYMBOL ( vmemdup_user ) ;
2018-08-24 03:00:59 +03:00
/**
2006-03-24 14:18:42 +03:00
* strndup_user - duplicate an existing string from user space
* @ s : The string to duplicate
* @ n : Maximum number of bytes to copy , including the trailing NUL .
2019-03-06 02:48:42 +03:00
*
2019-04-06 04:39:34 +03:00
* Return : newly allocated copy of @ s or an ERR_PTR ( ) in case of error
2006-03-24 14:18:42 +03:00
*/
char * strndup_user ( const char __user * s , long n )
{
char * p ;
long length ;
length = strnlen_user ( s , n ) ;
if ( ! length )
return ERR_PTR ( - EFAULT ) ;
if ( length > n )
return ERR_PTR ( - EINVAL ) ;
2010-08-10 04:18:26 +04:00
p = memdup_user ( s , length ) ;
2006-03-24 14:18:42 +03:00
2010-08-10 04:18:26 +04:00
if ( IS_ERR ( p ) )
return p ;
2006-03-24 14:18:42 +03:00
p [ length - 1 ] = ' \0 ' ;
return p ;
}
EXPORT_SYMBOL ( strndup_user ) ;
2008-07-26 06:44:36 +04:00
2015-12-24 08:06:05 +03:00
/**
* memdup_user_nul - duplicate memory region from user space and NUL - terminate
*
* @ src : source address in user space
* @ len : number of bytes to copy
*
2019-03-06 02:48:42 +03:00
* Return : an ERR_PTR ( ) on failure .
2015-12-24 08:06:05 +03:00
*/
void * memdup_user_nul ( const void __user * src , size_t len )
{
char * p ;
/*
* Always use GFP_KERNEL , since copy_from_user ( ) can sleep and
* cause pagefault , which makes it pointless to use GFP_NOFS
* or GFP_ATOMIC .
*/
p = kmalloc_track_caller ( len + 1 , GFP_KERNEL ) ;
if ( ! p )
return ERR_PTR ( - ENOMEM ) ;
if ( copy_from_user ( p , src , len ) ) {
kfree ( p ) ;
return ERR_PTR ( - EFAULT ) ;
}
p [ len ] = ' \0 ' ;
return p ;
}
EXPORT_SYMBOL ( memdup_user_nul ) ;
mm: nommu: sort mm->mmap list properly
When I was reading nommu code, I found that it handles the vma list/tree
in an unusual way. IIUC, because there can be more than one
identical/overrapped vmas in the list/tree, it sorts the tree more
strictly and does a linear search on the tree. But it doesn't applied to
the list (i.e. the list could be constructed in a different order than
the tree so that we can't use the list when finding the first vma in that
order).
Since inserting/sorting a vma in the tree and link is done at the same
time, we can easily construct both of them in the same order. And linear
searching on the tree could be more costly than doing it on the list, it
can be converted to use the list.
Also, after the commit 297c5eee3724 ("mm: make the vma list be doubly
linked") made the list be doubly linked, there were a couple of code need
to be fixed to construct the list properly.
Patch 1/6 is a preparation. It maintains the list sorted same as the tree
and construct doubly-linked list properly. Patch 2/6 is a simple
optimization for the vma deletion. Patch 3/6 and 4/6 convert tree
traversal to list traversal and the rest are simple fixes and cleanups.
This patch:
@vma added into @mm should be sorted by start addr, end addr and VMA
struct addr in that order because we may get identical VMAs in the @mm.
However this was true only for the rbtree, not for the list.
This patch fixes this by remembering 'rb_prev' during the tree traversal
like find_vma_prepare() does and linking the @vma via __vma_link_list().
After this patch, we can iterate the whole VMAs in correct order simply by
using @mm->mmap list.
[akpm@linux-foundation.org: avoid duplicating __vma_link_list()]
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 04:11:22 +04:00
void __vma_link_list ( struct mm_struct * mm , struct vm_area_struct * vma ,
2019-12-01 04:50:53 +03:00
struct vm_area_struct * prev )
mm: nommu: sort mm->mmap list properly
When I was reading nommu code, I found that it handles the vma list/tree
in an unusual way. IIUC, because there can be more than one
identical/overrapped vmas in the list/tree, it sorts the tree more
strictly and does a linear search on the tree. But it doesn't applied to
the list (i.e. the list could be constructed in a different order than
the tree so that we can't use the list when finding the first vma in that
order).
Since inserting/sorting a vma in the tree and link is done at the same
time, we can easily construct both of them in the same order. And linear
searching on the tree could be more costly than doing it on the list, it
can be converted to use the list.
Also, after the commit 297c5eee3724 ("mm: make the vma list be doubly
linked") made the list be doubly linked, there were a couple of code need
to be fixed to construct the list properly.
Patch 1/6 is a preparation. It maintains the list sorted same as the tree
and construct doubly-linked list properly. Patch 2/6 is a simple
optimization for the vma deletion. Patch 3/6 and 4/6 convert tree
traversal to list traversal and the rest are simple fixes and cleanups.
This patch:
@vma added into @mm should be sorted by start addr, end addr and VMA
struct addr in that order because we may get identical VMAs in the @mm.
However this was true only for the rbtree, not for the list.
This patch fixes this by remembering 'rb_prev' during the tree traversal
like find_vma_prepare() does and linking the @vma via __vma_link_list().
After this patch, we can iterate the whole VMAs in correct order simply by
using @mm->mmap list.
[akpm@linux-foundation.org: avoid duplicating __vma_link_list()]
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 04:11:22 +04:00
{
struct vm_area_struct * next ;
vma - > vm_prev = prev ;
if ( prev ) {
next = prev - > vm_next ;
prev - > vm_next = vma ;
} else {
2019-12-01 04:50:53 +03:00
next = mm - > mmap ;
mm: nommu: sort mm->mmap list properly
When I was reading nommu code, I found that it handles the vma list/tree
in an unusual way. IIUC, because there can be more than one
identical/overrapped vmas in the list/tree, it sorts the tree more
strictly and does a linear search on the tree. But it doesn't applied to
the list (i.e. the list could be constructed in a different order than
the tree so that we can't use the list when finding the first vma in that
order).
Since inserting/sorting a vma in the tree and link is done at the same
time, we can easily construct both of them in the same order. And linear
searching on the tree could be more costly than doing it on the list, it
can be converted to use the list.
Also, after the commit 297c5eee3724 ("mm: make the vma list be doubly
linked") made the list be doubly linked, there were a couple of code need
to be fixed to construct the list properly.
Patch 1/6 is a preparation. It maintains the list sorted same as the tree
and construct doubly-linked list properly. Patch 2/6 is a simple
optimization for the vma deletion. Patch 3/6 and 4/6 convert tree
traversal to list traversal and the rest are simple fixes and cleanups.
This patch:
@vma added into @mm should be sorted by start addr, end addr and VMA
struct addr in that order because we may get identical VMAs in the @mm.
However this was true only for the rbtree, not for the list.
This patch fixes this by remembering 'rb_prev' during the tree traversal
like find_vma_prepare() does and linking the @vma via __vma_link_list().
After this patch, we can iterate the whole VMAs in correct order simply by
using @mm->mmap list.
[akpm@linux-foundation.org: avoid duplicating __vma_link_list()]
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-25 04:11:22 +04:00
mm - > mmap = vma ;
}
vma - > vm_next = next ;
if ( next )
next - > vm_prev = vma ;
}
2019-12-01 04:50:49 +03:00
void __vma_unlink_list ( struct mm_struct * mm , struct vm_area_struct * vma )
{
struct vm_area_struct * prev , * next ;
next = vma - > vm_next ;
prev = vma - > vm_prev ;
if ( prev )
prev - > vm_next = next ;
else
mm - > mmap = next ;
if ( next )
next - > vm_prev = prev ;
}
procfs: mark thread stack correctly in proc/<pid>/maps
Stack for a new thread is mapped by userspace code and passed via
sys_clone. This memory is currently seen as anonymous in
/proc/<pid>/maps, which makes it difficult to ascertain which mappings
are being used for thread stacks. This patch uses the individual task
stack pointers to determine which vmas are actually thread stacks.
For a multithreaded program like the following:
#include <pthread.h>
void *thread_main(void *foo)
{
while(1);
}
int main()
{
pthread_t t;
pthread_create(&t, NULL, thread_main, NULL);
pthread_join(t, NULL);
}
proc/PID/maps looks like the following:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Here, one could guess that 7f8a44492000-7f8a44c92000 is a stack since
the earlier vma that has no permissions (7f8a44e3d000-7f8a4503d000) but
that is not always a reliable way to find out which vma is a thread
stack. Also, /proc/PID/maps and /proc/PID/task/TID/maps has the same
content.
With this patch in place, /proc/PID/task/TID/maps are treated as 'maps
as the task would see it' and hence, only the vma that that task uses as
stack is marked as [stack]. All other 'stack' vmas are marked as
anonymous memory. /proc/PID/maps acts as a thread group level view,
where all thread stack vmas are marked as [stack:TID] where TID is the
process ID of the task that uses that vma as stack, while the process
stack is marked as [stack].
So /proc/PID/maps will look like this:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442]
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Thus marking all vmas that are used as stacks by the threads in the
thread group along with the process stack. The task level maps will
however like this:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack]
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
where only the vma that is being used as a stack by *that* task is
marked as [stack].
Analogous changes have been made to /proc/PID/smaps,
/proc/PID/numa_maps, /proc/PID/task/TID/smaps and
/proc/PID/task/TID/numa_maps. Relevant snippets from smaps and
numa_maps:
[siddhesh@localhost ~ ]$ pgrep a.out
1441
[siddhesh@localhost ~ ]$ cat /proc/1441/smaps | grep "\[stack"
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442]
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/smaps | grep "\[stack"
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/smaps | grep "\[stack"
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/numa_maps | grep "stack"
7f8a44492000 default stack:1442 anon=2 dirty=2 N0=2
7fff6273a000 default stack anon=3 dirty=3 N0=3
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/numa_maps | grep "stack"
7f8a44492000 default stack anon=2 dirty=2 N0=2
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/numa_maps | grep "stack"
7fff6273a000 default stack anon=3 dirty=3 N0=3
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix build]
Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Jamie Lokier <jamie@shareable.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-22 03:34:04 +04:00
/* Check if the vma is being used as a stack by this task */
2016-09-30 20:58:58 +03:00
int vma_is_stack_for_current ( struct vm_area_struct * vma )
procfs: mark thread stack correctly in proc/<pid>/maps
Stack for a new thread is mapped by userspace code and passed via
sys_clone. This memory is currently seen as anonymous in
/proc/<pid>/maps, which makes it difficult to ascertain which mappings
are being used for thread stacks. This patch uses the individual task
stack pointers to determine which vmas are actually thread stacks.
For a multithreaded program like the following:
#include <pthread.h>
void *thread_main(void *foo)
{
while(1);
}
int main()
{
pthread_t t;
pthread_create(&t, NULL, thread_main, NULL);
pthread_join(t, NULL);
}
proc/PID/maps looks like the following:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Here, one could guess that 7f8a44492000-7f8a44c92000 is a stack since
the earlier vma that has no permissions (7f8a44e3d000-7f8a4503d000) but
that is not always a reliable way to find out which vma is a thread
stack. Also, /proc/PID/maps and /proc/PID/task/TID/maps has the same
content.
With this patch in place, /proc/PID/task/TID/maps are treated as 'maps
as the task would see it' and hence, only the vma that that task uses as
stack is marked as [stack]. All other 'stack' vmas are marked as
anonymous memory. /proc/PID/maps acts as a thread group level view,
where all thread stack vmas are marked as [stack:TID] where TID is the
process ID of the task that uses that vma as stack, while the process
stack is marked as [stack].
So /proc/PID/maps will look like this:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442]
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Thus marking all vmas that are used as stacks by the threads in the
thread group along with the process stack. The task level maps will
however like this:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack]
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
where only the vma that is being used as a stack by *that* task is
marked as [stack].
Analogous changes have been made to /proc/PID/smaps,
/proc/PID/numa_maps, /proc/PID/task/TID/smaps and
/proc/PID/task/TID/numa_maps. Relevant snippets from smaps and
numa_maps:
[siddhesh@localhost ~ ]$ pgrep a.out
1441
[siddhesh@localhost ~ ]$ cat /proc/1441/smaps | grep "\[stack"
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442]
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/smaps | grep "\[stack"
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/smaps | grep "\[stack"
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/numa_maps | grep "stack"
7f8a44492000 default stack:1442 anon=2 dirty=2 N0=2
7fff6273a000 default stack anon=3 dirty=3 N0=3
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/numa_maps | grep "stack"
7f8a44492000 default stack anon=2 dirty=2 N0=2
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/numa_maps | grep "stack"
7fff6273a000 default stack anon=3 dirty=3 N0=3
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix build]
Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Jamie Lokier <jamie@shareable.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-22 03:34:04 +04:00
{
2016-09-30 20:58:58 +03:00
struct task_struct * __maybe_unused t = current ;
procfs: mark thread stack correctly in proc/<pid>/maps
Stack for a new thread is mapped by userspace code and passed via
sys_clone. This memory is currently seen as anonymous in
/proc/<pid>/maps, which makes it difficult to ascertain which mappings
are being used for thread stacks. This patch uses the individual task
stack pointers to determine which vmas are actually thread stacks.
For a multithreaded program like the following:
#include <pthread.h>
void *thread_main(void *foo)
{
while(1);
}
int main()
{
pthread_t t;
pthread_create(&t, NULL, thread_main, NULL);
pthread_join(t, NULL);
}
proc/PID/maps looks like the following:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Here, one could guess that 7f8a44492000-7f8a44c92000 is a stack since
the earlier vma that has no permissions (7f8a44e3d000-7f8a4503d000) but
that is not always a reliable way to find out which vma is a thread
stack. Also, /proc/PID/maps and /proc/PID/task/TID/maps has the same
content.
With this patch in place, /proc/PID/task/TID/maps are treated as 'maps
as the task would see it' and hence, only the vma that that task uses as
stack is marked as [stack]. All other 'stack' vmas are marked as
anonymous memory. /proc/PID/maps acts as a thread group level view,
where all thread stack vmas are marked as [stack:TID] where TID is the
process ID of the task that uses that vma as stack, while the process
stack is marked as [stack].
So /proc/PID/maps will look like this:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442]
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Thus marking all vmas that are used as stacks by the threads in the
thread group along with the process stack. The task level maps will
however like this:
00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out
00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out
019ef000-01a10000 rw-p 00000000 00:00 0 [heap]
7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack]
7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so
7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so
7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so
7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0
7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
where only the vma that is being used as a stack by *that* task is
marked as [stack].
Analogous changes have been made to /proc/PID/smaps,
/proc/PID/numa_maps, /proc/PID/task/TID/smaps and
/proc/PID/task/TID/numa_maps. Relevant snippets from smaps and
numa_maps:
[siddhesh@localhost ~ ]$ pgrep a.out
1441
[siddhesh@localhost ~ ]$ cat /proc/1441/smaps | grep "\[stack"
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442]
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/smaps | grep "\[stack"
7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/smaps | grep "\[stack"
7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack]
[siddhesh@localhost ~ ]$ cat /proc/1441/numa_maps | grep "stack"
7f8a44492000 default stack:1442 anon=2 dirty=2 N0=2
7fff6273a000 default stack anon=3 dirty=3 N0=3
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/numa_maps | grep "stack"
7f8a44492000 default stack anon=2 dirty=2 N0=2
[siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/numa_maps | grep "stack"
7fff6273a000 default stack anon=3 dirty=3 N0=3
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix build]
Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Jamie Lokier <jamie@shareable.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-22 03:34:04 +04:00
return ( vma - > vm_start < = KSTK_ESP ( t ) & & vma - > vm_end > = KSTK_ESP ( t ) ) ;
}
2019-09-24 01:38:37 +03:00
# ifndef STACK_RND_MASK
# define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) /* 8MB of VA */
# endif
unsigned long randomize_stack_top ( unsigned long stack_top )
{
unsigned long random_variable = 0 ;
if ( current - > flags & PF_RANDOMIZE ) {
random_variable = get_random_long ( ) ;
random_variable & = STACK_RND_MASK ;
random_variable < < = PAGE_SHIFT ;
}
# ifdef CONFIG_STACK_GROWSUP
return PAGE_ALIGN ( stack_top ) + random_variable ;
# else
return PAGE_ALIGN ( stack_top ) - random_variable ;
# endif
}
2019-09-24 01:38:47 +03:00
# ifdef CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
2019-09-24 01:38:50 +03:00
unsigned long arch_randomize_brk ( struct mm_struct * mm )
{
/* Is the current task 32bit ? */
if ( ! IS_ENABLED ( CONFIG_64BIT ) | | is_compat_task ( ) )
return randomize_page ( mm - > brk , SZ_32M ) ;
return randomize_page ( mm - > brk , SZ_1G ) ;
}
2019-09-24 01:38:47 +03:00
unsigned long arch_mmap_rnd ( void )
{
unsigned long rnd ;
# ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS
if ( is_compat_task ( ) )
rnd = get_random_long ( ) & ( ( 1UL < < mmap_rnd_compat_bits ) - 1 ) ;
else
# endif /* CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS */
rnd = get_random_long ( ) & ( ( 1UL < < mmap_rnd_bits ) - 1 ) ;
return rnd < < PAGE_SHIFT ;
}
static int mmap_is_legacy ( struct rlimit * rlim_stack )
{
if ( current - > personality & ADDR_COMPAT_LAYOUT )
return 1 ;
if ( rlim_stack - > rlim_cur = = RLIM_INFINITY )
return 1 ;
return sysctl_legacy_va_layout ;
}
/*
* Leave enough space between the mmap area and the stack to honour ulimit in
* the face of randomisation .
*/
# define MIN_GAP (SZ_128M)
# define MAX_GAP (STACK_TOP / 6 * 5)
static unsigned long mmap_base ( unsigned long rnd , struct rlimit * rlim_stack )
{
unsigned long gap = rlim_stack - > rlim_cur ;
unsigned long pad = stack_guard_gap ;
/* Account for stack randomization if necessary */
if ( current - > flags & PF_RANDOMIZE )
pad + = ( STACK_RND_MASK < < PAGE_SHIFT ) ;
/* Values close to RLIM_INFINITY can overflow. */
if ( gap + pad > gap )
gap + = pad ;
if ( gap < MIN_GAP )
gap = MIN_GAP ;
else if ( gap > MAX_GAP )
gap = MAX_GAP ;
return PAGE_ALIGN ( STACK_TOP - gap - rnd ) ;
}
void arch_pick_mmap_layout ( struct mm_struct * mm , struct rlimit * rlim_stack )
{
unsigned long random_factor = 0UL ;
if ( current - > flags & PF_RANDOMIZE )
random_factor = arch_mmap_rnd ( ) ;
if ( mmap_is_legacy ( rlim_stack ) ) {
mm - > mmap_base = TASK_UNMAPPED_BASE + random_factor ;
mm - > get_unmapped_area = arch_get_unmapped_area ;
} else {
mm - > mmap_base = mmap_base ( random_factor , rlim_stack ) ;
mm - > get_unmapped_area = arch_get_unmapped_area_topdown ;
}
}
# elif defined(CONFIG_MMU) && !defined(HAVE_ARCH_PICK_MMAP_LAYOUT)
2018-04-11 02:34:53 +03:00
void arch_pick_mmap_layout ( struct mm_struct * mm , struct rlimit * rlim_stack )
2008-07-26 06:44:36 +04:00
{
mm - > mmap_base = TASK_UNMAPPED_BASE ;
mm - > get_unmapped_area = arch_get_unmapped_area ;
}
# endif
2008-08-13 02:52:52 +04:00
2019-07-17 02:30:54 +03:00
/**
* __account_locked_vm - account locked pages to an mm ' s locked_vm
* @ mm : mm to account against
* @ pages : number of pages to account
* @ inc : % true if @ pages should be considered positive , % false if not
* @ task : task used to check RLIMIT_MEMLOCK
* @ bypass_rlim : % true if checking RLIMIT_MEMLOCK should be skipped
*
* Assumes @ task and @ mm are valid ( i . e . at least one reference on each ) , and
2020-06-09 07:33:54 +03:00
* that mmap_lock is held as writer .
2019-07-17 02:30:54 +03:00
*
* Return :
* * 0 on success
* * - ENOMEM if RLIMIT_MEMLOCK would be exceeded .
*/
int __account_locked_vm ( struct mm_struct * mm , unsigned long pages , bool inc ,
struct task_struct * task , bool bypass_rlim )
{
unsigned long locked_vm , limit ;
int ret = 0 ;
2020-06-09 07:33:44 +03:00
mmap_assert_write_locked ( mm ) ;
2019-07-17 02:30:54 +03:00
locked_vm = mm - > locked_vm ;
if ( inc ) {
if ( ! bypass_rlim ) {
limit = task_rlimit ( task , RLIMIT_MEMLOCK ) > > PAGE_SHIFT ;
if ( locked_vm + pages > limit )
ret = - ENOMEM ;
}
if ( ! ret )
mm - > locked_vm = locked_vm + pages ;
} else {
WARN_ON_ONCE ( pages > locked_vm ) ;
mm - > locked_vm = locked_vm - pages ;
}
pr_debug ( " %s: [%d] caller %ps %c%lu %lu/%lu%s \n " , __func__ , task - > pid ,
( void * ) _RET_IP_ , ( inc ) ? ' + ' : ' - ' , pages < < PAGE_SHIFT ,
locked_vm < < PAGE_SHIFT , task_rlimit ( task , RLIMIT_MEMLOCK ) ,
ret ? " - exceeded " : " " ) ;
return ret ;
}
EXPORT_SYMBOL_GPL ( __account_locked_vm ) ;
/**
* account_locked_vm - account locked pages to an mm ' s locked_vm
* @ mm : mm to account against , may be NULL
* @ pages : number of pages to account
* @ inc : % true if @ pages should be considered positive , % false if not
*
* Assumes a non - NULL @ mm is valid ( i . e . at least one reference on it ) .
*
* Return :
* * 0 on success , or if mm is NULL
* * - ENOMEM if RLIMIT_MEMLOCK would be exceeded .
*/
int account_locked_vm ( struct mm_struct * mm , unsigned long pages , bool inc )
{
int ret ;
if ( pages = = 0 | | ! mm )
return 0 ;
2020-06-09 07:33:25 +03:00
mmap_write_lock ( mm ) ;
2019-07-17 02:30:54 +03:00
ret = __account_locked_vm ( mm , pages , inc , current ,
capable ( CAP_IPC_LOCK ) ) ;
2020-06-09 07:33:25 +03:00
mmap_write_unlock ( mm ) ;
2019-07-17 02:30:54 +03:00
return ret ;
}
EXPORT_SYMBOL_GPL ( account_locked_vm ) ;
2012-05-31 04:17:35 +04:00
unsigned long vm_mmap_pgoff ( struct file * file , unsigned long addr ,
unsigned long len , unsigned long prot ,
2016-05-24 02:25:30 +03:00
unsigned long flag , unsigned long pgoff )
2012-05-31 04:17:35 +04:00
{
unsigned long ret ;
struct mm_struct * mm = current - > mm ;
2013-02-23 04:32:47 +04:00
unsigned long populate ;
2017-02-25 01:58:22 +03:00
LIST_HEAD ( uf ) ;
2012-05-31 04:17:35 +04:00
ret = security_mmap_file ( file , prot , flag ) ;
if ( ! ret ) {
2020-06-09 07:33:25 +03:00
if ( mmap_write_lock_killable ( mm ) )
2016-05-24 02:25:30 +03:00
return - EINTR ;
2013-02-23 04:32:37 +04:00
ret = do_mmap_pgoff ( file , addr , len , prot , flag , pgoff ,
2017-02-25 01:58:22 +03:00
& populate , & uf ) ;
2020-06-09 07:33:25 +03:00
mmap_write_unlock ( mm ) ;
2017-02-25 01:58:22 +03:00
userfaultfd_unmap_complete ( mm , & uf ) ;
2013-02-23 04:32:47 +04:00
if ( populate )
mm_populate ( ret , populate ) ;
2012-05-31 04:17:35 +04:00
}
return ret ;
}
unsigned long vm_mmap ( struct file * file , unsigned long addr ,
unsigned long len , unsigned long prot ,
unsigned long flag , unsigned long offset )
{
if ( unlikely ( offset + PAGE_ALIGN ( len ) < offset ) )
return - EINVAL ;
2015-11-06 05:46:46 +03:00
if ( unlikely ( offset_in_page ( offset ) ) )
2012-05-31 04:17:35 +04:00
return - EINVAL ;
2016-05-24 02:25:30 +03:00
return vm_mmap_pgoff ( file , addr , len , prot , flag , offset > > PAGE_SHIFT ) ;
2012-05-31 04:17:35 +04:00
}
EXPORT_SYMBOL ( vm_mmap ) ;
2017-05-09 01:57:09 +03:00
/**
* kvmalloc_node - attempt to allocate physically contiguous memory , but upon
* failure , fall back to non - contiguous ( vmalloc ) allocation .
* @ size : size of the request .
* @ flags : gfp mask for the allocation - must be compatible ( superset ) with GFP_KERNEL .
* @ node : numa node to allocate from
*
* Uses kmalloc to get the memory but if the allocation fails then falls back
* to the vmalloc allocator . Use kvfree for freeing the memory .
*
2017-07-13 00:36:52 +03:00
* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported .
* __GFP_RETRY_MAYFAIL is supported , and it should be used only if kmalloc is
* preferable to the vmalloc fallback , due to visible performance drawbacks .
2017-05-09 01:57:09 +03:00
*
2018-06-08 03:09:40 +03:00
* Please note that any use of gfp flags outside of GFP_KERNEL is careful to not
* fall back to vmalloc .
2019-03-06 02:48:42 +03:00
*
* Return : pointer to the allocated memory of % NULL in case of failure
2017-05-09 01:57:09 +03:00
*/
void * kvmalloc_node ( size_t size , gfp_t flags , int node )
{
gfp_t kmalloc_flags = flags ;
void * ret ;
/*
* vmalloc uses GFP_KERNEL for some internal allocations ( e . g page tables )
* so the given set of flags has to be compatible .
*/
2018-06-08 03:09:40 +03:00
if ( ( flags & GFP_KERNEL ) ! = GFP_KERNEL )
return kmalloc_node ( size , flags , node ) ;
2017-05-09 01:57:09 +03:00
/*
2017-06-03 00:46:19 +03:00
* We want to attempt a large physically contiguous block first because
* it is less likely to fragment multiple larger blocks and therefore
* contribute to a long term fragmentation less than vmalloc fallback .
* However make sure that larger requests are not too disruptive - no
* OOM killer and no allocation failure warnings as we have a fallback .
2017-05-09 01:57:09 +03:00
*/
2017-05-09 01:57:15 +03:00
if ( size > PAGE_SIZE ) {
kmalloc_flags | = __GFP_NOWARN ;
2017-07-13 00:36:52 +03:00
if ( ! ( kmalloc_flags & __GFP_RETRY_MAYFAIL ) )
2017-05-09 01:57:15 +03:00
kmalloc_flags | = __GFP_NORETRY ;
}
2017-05-09 01:57:09 +03:00
ret = kmalloc_node ( size , kmalloc_flags , node ) ;
/*
* It doesn ' t really make sense to fallback to vmalloc for sub page
* requests
*/
if ( ret | | size < = PAGE_SIZE )
return ret ;
2020-06-02 07:51:53 +03:00
return __vmalloc_node ( size , 1 , flags , node ,
mm, vmalloc: fix vmalloc users tracking properly
Commit 1f5307b1e094 ("mm, vmalloc: properly track vmalloc users") has
pulled asm/pgtable.h include dependency to linux/vmalloc.h and that
turned out to be a bad idea for some architectures. E.g. m68k fails
with
In file included from arch/m68k/include/asm/pgtable_mm.h:145:0,
from arch/m68k/include/asm/pgtable.h:4,
from include/linux/vmalloc.h:9,
from arch/m68k/kernel/module.c:9:
arch/m68k/include/asm/mcf_pgtable.h: In function 'nocache_page':
>> arch/m68k/include/asm/mcf_pgtable.h:339:43: error: 'init_mm' undeclared (first use in this function)
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
as spotted by kernel build bot. nios2 fails for other reason
In file included from include/asm-generic/io.h:767:0,
from arch/nios2/include/asm/io.h:61,
from include/linux/io.h:25,
from arch/nios2/include/asm/pgtable.h:18,
from include/linux/mm.h:70,
from include/linux/pid_namespace.h:6,
from include/linux/ptrace.h:9,
from arch/nios2/include/uapi/asm/elf.h:23,
from arch/nios2/include/asm/elf.h:22,
from include/linux/elf.h:4,
from include/linux/module.h:15,
from init/main.c:16:
include/linux/vmalloc.h: In function '__vmalloc_node_flags':
include/linux/vmalloc.h:99:40: error: 'PAGE_KERNEL' undeclared (first use in this function); did you mean 'GFP_KERNEL'?
which is due to the newly added #include <asm/pgtable.h>, which on nios2
includes <linux/io.h> and thus <asm/io.h> and <asm-generic/io.h> which
again includes <linux/vmalloc.h>.
Tweaking that around just turns out a bigger headache than necessary.
This patch reverts 1f5307b1e094 and reimplements the original fix in a
different way. __vmalloc_node_flags can stay static inline which will
cover vmalloc* functions. We only have one external user
(kvmalloc_node) and we can export __vmalloc_node_flags_caller and
provide the caller directly. This is much simpler and it doesn't really
need any games with header files.
[akpm@linux-foundation.org: coding-style fixes]
[mhocko@kernel.org: revert old comment]
Link: http://lkml.kernel.org/r/20170509211054.GB16325@dhcp22.suse.cz
Fixes: 1f5307b1e094 ("mm, vmalloc: properly track vmalloc users")
Link: http://lkml.kernel.org/r/20170509153702.GR6481@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: Tobias Klauser <tklauser@distanz.ch>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-13 01:46:41 +03:00
__builtin_return_address ( 0 ) ) ;
2017-05-09 01:57:09 +03:00
}
EXPORT_SYMBOL ( kvmalloc_node ) ;
2018-08-24 03:01:02 +03:00
/**
2018-09-05 01:45:55 +03:00
* kvfree ( ) - Free memory .
* @ addr : Pointer to allocated memory .
2018-08-24 03:01:02 +03:00
*
2018-09-05 01:45:55 +03:00
* kvfree frees memory allocated by any of vmalloc ( ) , kmalloc ( ) or kvmalloc ( ) .
* It is slightly more efficient to use kfree ( ) or vfree ( ) if you are certain
* that you know which one to use .
*
2018-10-27 01:07:00 +03:00
* Context : Either preemptible task context or not - NMI interrupt .
2018-08-24 03:01:02 +03:00
*/
2014-05-06 22:02:53 +04:00
void kvfree ( const void * addr )
{
if ( is_vmalloc_addr ( addr ) )
vfree ( addr ) ;
else
kfree ( addr ) ;
}
EXPORT_SYMBOL ( kvfree ) ;
2020-06-05 02:48:21 +03:00
/**
* kvfree_sensitive - Free a data object containing sensitive information .
* @ addr : address of the data object to be freed .
* @ len : length of the data object .
*
* Use the special memzero_explicit ( ) function to clear the content of a
* kvmalloc ' ed object containing sensitive data to make sure that the
* compiler won ' t optimize out the data clearing .
*/
void kvfree_sensitive ( const void * addr , size_t len )
{
if ( likely ( ! ZERO_OR_NULL_PTR ( addr ) ) ) {
memzero_explicit ( ( void * ) addr , len ) ;
kvfree ( addr ) ;
}
}
EXPORT_SYMBOL ( kvfree_sensitive ) ;
2015-04-16 02:14:53 +03:00
static inline void * __page_rmapping ( struct page * page )
{
unsigned long mapping ;
mapping = ( unsigned long ) page - > mapping ;
mapping & = ~ PAGE_MAPPING_FLAGS ;
return ( void * ) mapping ;
}
/* Neutral page->mapping pointer to address_space or anon_vma or other */
void * page_rmapping ( struct page * page )
{
page = compound_head ( page ) ;
return __page_rmapping ( page ) ;
}
2016-05-20 03:12:00 +03:00
/*
* Return true if this page is mapped into pagetables .
* For compound page it returns true if any subpage of compound page is mapped .
*/
bool page_mapped ( struct page * page )
{
int i ;
if ( likely ( ! PageCompound ( page ) ) )
return atomic_read ( & page - > _mapcount ) > = 0 ;
page = compound_head ( page ) ;
if ( atomic_read ( compound_mapcount_ptr ( page ) ) > = 0 )
return true ;
if ( PageHuge ( page ) )
return false ;
2019-09-24 01:34:30 +03:00
for ( i = 0 ; i < compound_nr ( page ) ; i + + ) {
2016-05-20 03:12:00 +03:00
if ( atomic_read ( & page [ i ] . _mapcount ) > = 0 )
return true ;
}
return false ;
}
EXPORT_SYMBOL ( page_mapped ) ;
2015-04-16 02:14:53 +03:00
struct anon_vma * page_anon_vma ( struct page * page )
{
unsigned long mapping ;
page = compound_head ( page ) ;
mapping = ( unsigned long ) page - > mapping ;
if ( ( mapping & PAGE_MAPPING_FLAGS ) ! = PAGE_MAPPING_ANON )
return NULL ;
return __page_rmapping ( page ) ;
}
2013-02-23 04:34:35 +04:00
struct address_space * page_mapping ( struct page * page )
{
2016-01-16 03:52:07 +03:00
struct address_space * mapping ;
page = compound_head ( page ) ;
2013-02-23 04:34:35 +04:00
2014-01-15 05:56:40 +04:00
/* This happens if someone calls flush_dcache_page on slab page */
if ( unlikely ( PageSlab ( page ) ) )
return NULL ;
2013-02-23 04:34:37 +04:00
if ( unlikely ( PageSwapCache ( page ) ) ) {
swp_entry_t entry ;
entry . val = page_private ( page ) ;
2015-04-16 02:14:53 +03:00
return swap_address_space ( entry ) ;
}
2016-01-16 03:52:07 +03:00
mapping = page - > mapping ;
mm: migrate: support non-lru movable page migration
We have allowed migration for only LRU pages until now and it was enough
to make high-order pages. But recently, embedded system(e.g., webOS,
android) uses lots of non-movable pages(e.g., zram, GPU memory) so we
have seen several reports about troubles of small high-order allocation.
For fixing the problem, there were several efforts (e,g,. enhance
compaction algorithm, SLUB fallback to 0-order page, reserved memory,
vmalloc and so on) but if there are lots of non-movable pages in system,
their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages with
movable. For the feature, this patch introduces functions related to
migration to address_space_operations as well as some page flags.
If a driver want to make own pages movable, it should define three
functions which are function pointers of struct
address_space_operations.
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
What VM expects on isolate_page function of driver is to return *true*
if driver isolates page successfully. On returing true, VM marks the
page as PG_isolated so concurrent isolation in several CPUs skip the
page for isolation. If a driver cannot isolate the page, it should
return *false*.
Once page is successfully isolated, VM uses page.lru fields so driver
shouldn't expect to preserve values in that fields.
2. int (*migratepage) (struct address_space *mapping,
struct page *newpage, struct page *oldpage, enum migrate_mode);
After isolation, VM calls migratepage of driver with isolated page. The
function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via
__ClearPageMovable() under page_lock if you migrated the oldpage
successfully and returns 0. If driver cannot migrate the page at the
moment, driver can return -EAGAIN. On -EAGAIN, VM will retry page
migration in a short time because VM interprets -EAGAIN as "temporal
migration failure". On returning any error except -EAGAIN, VM will give
up the page migration without retrying in this time.
Driver shouldn't touch page.lru field VM using in the functions.
3. void (*putback_page)(struct page *);
If migration fails on isolated page, VM should return the isolated page
to the driver so VM calls driver's putback_page with migration failed
page. In this function, driver should put the isolated page back to the
own data structure.
4. non-lru movable page flags
There are two page flags for supporting non-lru movable page.
* PG_movable
Driver should use the below function to make page movable under
page_lock.
void __SetPageMovable(struct page *page, struct address_space *mapping)
It needs argument of address_space for registering migration family
functions which will be called by VM. Exactly speaking, PG_movable is
not a real flag of struct page. Rather than, VM reuses page->mapping's
lower bits to represent it.
#define PAGE_MAPPING_MOVABLE 0x2
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
so driver shouldn't access page->mapping directly. Instead, driver
should use page_mapping which mask off the low two bits of page->mapping
so it can get right struct address_space.
For testing of non-lru movable page, VM supports __PageMovable function.
However, it doesn't guarantee to identify non-lru movable page because
page->mapping field is unified with other variables in struct page. As
well, if driver releases the page after isolation by VM, page->mapping
doesn't have stable value although it has PAGE_MAPPING_MOVABLE (Look at
__ClearPageMovable). But __PageMovable is cheap to catch whether page
is LRU or non-lru movable once the page has been isolated. Because LRU
pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
good for just peeking to test non-lru movable pages before more
expensive checking with lock_page in pfn scanning to select victim.
For guaranteeing non-lru movable page, VM provides PageMovable function.
Unlike __PageMovable, PageMovable functions validates page->mapping and
mapping->a_ops->isolate_page under lock_page. The lock_page prevents
sudden destroying of page->mapping.
Driver using __SetPageMovable should clear the flag via
__ClearMovablePage under page_lock before the releasing the page.
* PG_isolated
To prevent concurrent isolation among several CPUs, VM marks isolated
page as PG_isolated under lock_page. So if a CPU encounters PG_isolated
non-lru movable page, it can skip it. Driver doesn't need to manipulate
the flag because VM will set/clear it automatically. Keep in mind that
if driver sees PG_isolated page, it means the page have been isolated by
VM so it shouldn't touch page.lru field. PG_isolated is alias with
PG_reclaim flag so driver shouldn't use the flag for own purpose.
[opensource.ganesh@gmail.com: mm/compaction: remove local variable is_lru]
Link: http://lkml.kernel.org/r/20160618014841.GA7422@leo-test
Link: http://lkml.kernel.org/r/1464736881-24886-3-git-send-email-minchan@kernel.org
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: John Einar Reitan <john.reitan@foss.arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-07-27 01:23:05 +03:00
if ( ( unsigned long ) mapping & PAGE_MAPPING_ANON )
2015-04-16 02:14:53 +03:00
return NULL ;
mm: migrate: support non-lru movable page migration
We have allowed migration for only LRU pages until now and it was enough
to make high-order pages. But recently, embedded system(e.g., webOS,
android) uses lots of non-movable pages(e.g., zram, GPU memory) so we
have seen several reports about troubles of small high-order allocation.
For fixing the problem, there were several efforts (e,g,. enhance
compaction algorithm, SLUB fallback to 0-order page, reserved memory,
vmalloc and so on) but if there are lots of non-movable pages in system,
their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages with
movable. For the feature, this patch introduces functions related to
migration to address_space_operations as well as some page flags.
If a driver want to make own pages movable, it should define three
functions which are function pointers of struct
address_space_operations.
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
What VM expects on isolate_page function of driver is to return *true*
if driver isolates page successfully. On returing true, VM marks the
page as PG_isolated so concurrent isolation in several CPUs skip the
page for isolation. If a driver cannot isolate the page, it should
return *false*.
Once page is successfully isolated, VM uses page.lru fields so driver
shouldn't expect to preserve values in that fields.
2. int (*migratepage) (struct address_space *mapping,
struct page *newpage, struct page *oldpage, enum migrate_mode);
After isolation, VM calls migratepage of driver with isolated page. The
function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via
__ClearPageMovable() under page_lock if you migrated the oldpage
successfully and returns 0. If driver cannot migrate the page at the
moment, driver can return -EAGAIN. On -EAGAIN, VM will retry page
migration in a short time because VM interprets -EAGAIN as "temporal
migration failure". On returning any error except -EAGAIN, VM will give
up the page migration without retrying in this time.
Driver shouldn't touch page.lru field VM using in the functions.
3. void (*putback_page)(struct page *);
If migration fails on isolated page, VM should return the isolated page
to the driver so VM calls driver's putback_page with migration failed
page. In this function, driver should put the isolated page back to the
own data structure.
4. non-lru movable page flags
There are two page flags for supporting non-lru movable page.
* PG_movable
Driver should use the below function to make page movable under
page_lock.
void __SetPageMovable(struct page *page, struct address_space *mapping)
It needs argument of address_space for registering migration family
functions which will be called by VM. Exactly speaking, PG_movable is
not a real flag of struct page. Rather than, VM reuses page->mapping's
lower bits to represent it.
#define PAGE_MAPPING_MOVABLE 0x2
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
so driver shouldn't access page->mapping directly. Instead, driver
should use page_mapping which mask off the low two bits of page->mapping
so it can get right struct address_space.
For testing of non-lru movable page, VM supports __PageMovable function.
However, it doesn't guarantee to identify non-lru movable page because
page->mapping field is unified with other variables in struct page. As
well, if driver releases the page after isolation by VM, page->mapping
doesn't have stable value although it has PAGE_MAPPING_MOVABLE (Look at
__ClearPageMovable). But __PageMovable is cheap to catch whether page
is LRU or non-lru movable once the page has been isolated. Because LRU
pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
good for just peeking to test non-lru movable pages before more
expensive checking with lock_page in pfn scanning to select victim.
For guaranteeing non-lru movable page, VM provides PageMovable function.
Unlike __PageMovable, PageMovable functions validates page->mapping and
mapping->a_ops->isolate_page under lock_page. The lock_page prevents
sudden destroying of page->mapping.
Driver using __SetPageMovable should clear the flag via
__ClearMovablePage under page_lock before the releasing the page.
* PG_isolated
To prevent concurrent isolation among several CPUs, VM marks isolated
page as PG_isolated under lock_page. So if a CPU encounters PG_isolated
non-lru movable page, it can skip it. Driver doesn't need to manipulate
the flag because VM will set/clear it automatically. Keep in mind that
if driver sees PG_isolated page, it means the page have been isolated by
VM so it shouldn't touch page.lru field. PG_isolated is alias with
PG_reclaim flag so driver shouldn't use the flag for own purpose.
[opensource.ganesh@gmail.com: mm/compaction: remove local variable is_lru]
Link: http://lkml.kernel.org/r/20160618014841.GA7422@leo-test
Link: http://lkml.kernel.org/r/1464736881-24886-3-git-send-email-minchan@kernel.org
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: John Einar Reitan <john.reitan@foss.arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-07-27 01:23:05 +03:00
return ( void * ) ( ( unsigned long ) mapping & ~ PAGE_MAPPING_FLAGS ) ;
2013-02-23 04:34:35 +04:00
}
mm: migrate: support non-lru movable page migration
We have allowed migration for only LRU pages until now and it was enough
to make high-order pages. But recently, embedded system(e.g., webOS,
android) uses lots of non-movable pages(e.g., zram, GPU memory) so we
have seen several reports about troubles of small high-order allocation.
For fixing the problem, there were several efforts (e,g,. enhance
compaction algorithm, SLUB fallback to 0-order page, reserved memory,
vmalloc and so on) but if there are lots of non-movable pages in system,
their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages with
movable. For the feature, this patch introduces functions related to
migration to address_space_operations as well as some page flags.
If a driver want to make own pages movable, it should define three
functions which are function pointers of struct
address_space_operations.
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
What VM expects on isolate_page function of driver is to return *true*
if driver isolates page successfully. On returing true, VM marks the
page as PG_isolated so concurrent isolation in several CPUs skip the
page for isolation. If a driver cannot isolate the page, it should
return *false*.
Once page is successfully isolated, VM uses page.lru fields so driver
shouldn't expect to preserve values in that fields.
2. int (*migratepage) (struct address_space *mapping,
struct page *newpage, struct page *oldpage, enum migrate_mode);
After isolation, VM calls migratepage of driver with isolated page. The
function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via
__ClearPageMovable() under page_lock if you migrated the oldpage
successfully and returns 0. If driver cannot migrate the page at the
moment, driver can return -EAGAIN. On -EAGAIN, VM will retry page
migration in a short time because VM interprets -EAGAIN as "temporal
migration failure". On returning any error except -EAGAIN, VM will give
up the page migration without retrying in this time.
Driver shouldn't touch page.lru field VM using in the functions.
3. void (*putback_page)(struct page *);
If migration fails on isolated page, VM should return the isolated page
to the driver so VM calls driver's putback_page with migration failed
page. In this function, driver should put the isolated page back to the
own data structure.
4. non-lru movable page flags
There are two page flags for supporting non-lru movable page.
* PG_movable
Driver should use the below function to make page movable under
page_lock.
void __SetPageMovable(struct page *page, struct address_space *mapping)
It needs argument of address_space for registering migration family
functions which will be called by VM. Exactly speaking, PG_movable is
not a real flag of struct page. Rather than, VM reuses page->mapping's
lower bits to represent it.
#define PAGE_MAPPING_MOVABLE 0x2
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
so driver shouldn't access page->mapping directly. Instead, driver
should use page_mapping which mask off the low two bits of page->mapping
so it can get right struct address_space.
For testing of non-lru movable page, VM supports __PageMovable function.
However, it doesn't guarantee to identify non-lru movable page because
page->mapping field is unified with other variables in struct page. As
well, if driver releases the page after isolation by VM, page->mapping
doesn't have stable value although it has PAGE_MAPPING_MOVABLE (Look at
__ClearPageMovable). But __PageMovable is cheap to catch whether page
is LRU or non-lru movable once the page has been isolated. Because LRU
pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
good for just peeking to test non-lru movable pages before more
expensive checking with lock_page in pfn scanning to select victim.
For guaranteeing non-lru movable page, VM provides PageMovable function.
Unlike __PageMovable, PageMovable functions validates page->mapping and
mapping->a_ops->isolate_page under lock_page. The lock_page prevents
sudden destroying of page->mapping.
Driver using __SetPageMovable should clear the flag via
__ClearMovablePage under page_lock before the releasing the page.
* PG_isolated
To prevent concurrent isolation among several CPUs, VM marks isolated
page as PG_isolated under lock_page. So if a CPU encounters PG_isolated
non-lru movable page, it can skip it. Driver doesn't need to manipulate
the flag because VM will set/clear it automatically. Keep in mind that
if driver sees PG_isolated page, it means the page have been isolated by
VM so it shouldn't touch page.lru field. PG_isolated is alias with
PG_reclaim flag so driver shouldn't use the flag for own purpose.
[opensource.ganesh@gmail.com: mm/compaction: remove local variable is_lru]
Link: http://lkml.kernel.org/r/20160618014841.GA7422@leo-test
Link: http://lkml.kernel.org/r/1464736881-24886-3-git-send-email-minchan@kernel.org
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: John Einar Reitan <john.reitan@foss.arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-07-27 01:23:05 +03:00
EXPORT_SYMBOL ( page_mapping ) ;
2013-02-23 04:34:35 +04:00
mm: fix races between swapoff and flush dcache
Thanks to commit 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB
trunks"), after swapoff the address_space associated with the swap
device will be freed. So page_mapping() users which may touch the
address_space need some kind of mechanism to prevent the address_space
from being freed during accessing.
The dcache flushing functions (flush_dcache_page(), etc) in architecture
specific code may access the address_space of swap device for anonymous
pages in swap cache via page_mapping() function. But in some cases
there are no mechanisms to prevent the swap device from being swapoff,
for example,
CPU1 CPU2
__get_user_pages() swapoff()
flush_dcache_page()
mapping = page_mapping()
... exit_swap_address_space()
... kvfree(spaces)
mapping_mapped(mapping)
The address space may be accessed after being freed.
But from cachetlb.txt and Russell King, flush_dcache_page() only care
about file cache pages, for anonymous pages, flush_anon_page() should be
used. The implementation of flush_dcache_page() in all architectures
follows this too. They will check whether page_mapping() is NULL and
whether mapping_mapped() is true to determine whether to flush the
dcache immediately. And they will use interval tree (mapping->i_mmap)
to find all user space mappings. While mapping_mapped() and
mapping->i_mmap isn't used by anonymous pages in swap cache at all.
So, to fix the race between swapoff and flush dcache, __page_mapping()
is add to return the address_space for file cache pages and NULL
otherwise. All page_mapping() invoking in flush dcache functions are
replaced with page_mapping_file().
[akpm@linux-foundation.org: simplify page_mapping_file(), per Mike]
Link: http://lkml.kernel.org/r/20180305083634.15174-1-ying.huang@intel.com
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Chen Liqin <liqin.linux@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Chris Zankel <chris@zankel.net>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-04-06 02:24:39 +03:00
/*
* For file cache pages , return the address_space , otherwise return NULL
*/
struct address_space * page_mapping_file ( struct page * page )
{
if ( unlikely ( PageSwapCache ( page ) ) )
return NULL ;
return page_mapping ( page ) ;
}
2016-01-16 03:54:37 +03:00
/* Slow path of page_mapcount() for compound pages */
int __page_mapcount ( struct page * page )
{
int ret ;
ret = atomic_read ( & page - > _mapcount ) + 1 ;
2016-07-27 01:25:26 +03:00
/*
* For file THP page - > _mapcount contains total number of mapping
* of the page : no need to look into compound_mapcount .
*/
if ( ! PageAnon ( page ) & & ! PageHuge ( page ) )
return ret ;
2016-01-16 03:54:37 +03:00
page = compound_head ( page ) ;
ret + = atomic_read ( compound_mapcount_ptr ( page ) ) + 1 ;
if ( PageDoubleMap ( page ) )
ret - - ;
return ret ;
}
EXPORT_SYMBOL_GPL ( __page_mapcount ) ;
2016-03-18 00:18:50 +03:00
int sysctl_overcommit_memory __read_mostly = OVERCOMMIT_GUESS ;
int sysctl_overcommit_ratio __read_mostly = 50 ;
unsigned long sysctl_overcommit_kbytes __read_mostly ;
int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT ;
unsigned long sysctl_user_reserve_kbytes __read_mostly = 1UL < < 17 ; /* 128MB */
unsigned long sysctl_admin_reserve_kbytes __read_mostly = 1UL < < 13 ; /* 8MB */
2020-04-24 09:43:38 +03:00
int overcommit_ratio_handler ( struct ctl_table * table , int write , void * buffer ,
size_t * lenp , loff_t * ppos )
2014-01-22 03:49:14 +04:00
{
int ret ;
ret = proc_dointvec ( table , write , buffer , lenp , ppos ) ;
if ( ret = = 0 & & write )
sysctl_overcommit_kbytes = 0 ;
return ret ;
}
2020-04-24 09:43:38 +03:00
int overcommit_kbytes_handler ( struct ctl_table * table , int write , void * buffer ,
size_t * lenp , loff_t * ppos )
2014-01-22 03:49:14 +04:00
{
int ret ;
ret = proc_doulongvec_minmax ( table , write , buffer , lenp , ppos ) ;
if ( ret = = 0 & & write )
sysctl_overcommit_ratio = 0 ;
return ret ;
}
2013-11-13 03:08:31 +04:00
/*
* Committed memory limit enforced when OVERCOMMIT_NEVER policy is used
*/
unsigned long vm_commit_limit ( void )
{
2014-01-22 03:49:14 +04:00
unsigned long allowed ;
if ( sysctl_overcommit_kbytes )
allowed = sysctl_overcommit_kbytes > > ( PAGE_SHIFT - 10 ) ;
else
2018-12-28 11:34:29 +03:00
allowed = ( ( totalram_pages ( ) - hugetlb_total_pages ( ) )
2014-01-22 03:49:14 +04:00
* sysctl_overcommit_ratio / 100 ) ;
allowed + = total_swap_pages ;
return allowed ;
2013-11-13 03:08:31 +04:00
}
2016-03-18 00:18:50 +03:00
/*
* Make sure vm_committed_as in one cacheline and not cacheline shared with
* other variables . It can be updated by several CPUs frequently .
*/
struct percpu_counter vm_committed_as ____cacheline_aligned_in_smp ;
/*
* The global memory commitment made in the system can be a metric
* that can be used to drive ballooning decisions when Linux is hosted
* as a guest . On Hyper - V , the host implements a policy engine for dynamically
* balancing memory across competing virtual machines that are hosted .
* Several metrics drive this policy engine including the guest reported
* memory commitment .
2020-08-07 09:23:07 +03:00
*
* The time cost of this is very low for small platforms , and for big
* platform like a 2 S / 36 C / 72 T Skylake server , in worst case where
* vm_committed_as ' s spinlock is under severe contention , the time cost
* could be about 30 ~ 40 microseconds .
2016-03-18 00:18:50 +03:00
*/
unsigned long vm_memory_committed ( void )
{
2020-08-07 09:23:07 +03:00
return percpu_counter_sum_positive ( & vm_committed_as ) ;
2016-03-18 00:18:50 +03:00
}
EXPORT_SYMBOL_GPL ( vm_memory_committed ) ;
/*
* Check that a process has enough memory to allocate a new virtual
* mapping . 0 means there is enough memory for the allocation to
* succeed and - ENOMEM implies there is not .
*
* We currently support three overcommit policies , which are set via the
2018-03-21 22:22:47 +03:00
* vm . overcommit_memory sysctl . See Documentation / vm / overcommit - accounting . rst
2016-03-18 00:18:50 +03:00
*
* Strict overcommit modes added 2002 Feb 26 by Alan Cox .
* Additional code 2002 Jul 20 by Robert Love .
*
* cap_sys_admin is 1 if the process has admin privileges , 0 otherwise .
*
* Note this is a helper function intended to be used by LSMs which
* wish to use this logic .
*/
int __vm_enough_memory ( struct mm_struct * mm , long pages , int cap_sys_admin )
{
2019-05-14 03:21:50 +03:00
long allowed ;
2016-03-18 00:18:50 +03:00
vm_acct_memory ( pages ) ;
/*
* Sometimes we want to use more memory than we have
*/
if ( sysctl_overcommit_memory = = OVERCOMMIT_ALWAYS )
return 0 ;
if ( sysctl_overcommit_memory = = OVERCOMMIT_GUESS ) {
2019-05-14 03:21:50 +03:00
if ( pages > totalram_pages ( ) + total_swap_pages )
2016-03-18 00:18:50 +03:00
goto error ;
2019-05-14 03:21:50 +03:00
return 0 ;
2016-03-18 00:18:50 +03:00
}
allowed = vm_commit_limit ( ) ;
/*
* Reserve some for root
*/
if ( ! cap_sys_admin )
allowed - = sysctl_admin_reserve_kbytes > > ( PAGE_SHIFT - 10 ) ;
/*
* Don ' t let a single process grow so big a user can ' t recover
*/
if ( mm ) {
2019-05-14 03:21:50 +03:00
long reserve = sysctl_user_reserve_kbytes > > ( PAGE_SHIFT - 10 ) ;
2016-03-18 00:18:50 +03:00
allowed - = min_t ( long , mm - > total_vm / 32 , reserve ) ;
}
if ( percpu_counter_read_positive ( & vm_committed_as ) < allowed )
return 0 ;
error :
vm_unacct_memory ( pages ) ;
return - ENOMEM ;
}
2014-02-11 22:11:59 +04:00
/**
* get_cmdline ( ) - copy the cmdline value to a buffer .
* @ task : the task whose cmdline value to copy .
* @ buffer : the buffer to copy to .
* @ buflen : the length of the buffer . Larger cmdline values are truncated
* to this length .
2019-03-06 02:48:42 +03:00
*
* Return : the size of the cmdline field copied . Note that the copy does
2014-02-11 22:11:59 +04:00
* not guarantee an ending NULL byte .
*/
int get_cmdline ( struct task_struct * task , char * buffer , int buflen )
{
int res = 0 ;
unsigned int len ;
struct mm_struct * mm = get_task_mm ( task ) ;
2016-01-21 02:01:05 +03:00
unsigned long arg_start , arg_end , env_start , env_end ;
2014-02-11 22:11:59 +04:00
if ( ! mm )
goto out ;
if ( ! mm - > arg_end )
goto out_mm ; /* Shh! No looking before we're done */
2019-06-01 08:30:19 +03:00
spin_lock ( & mm - > arg_lock ) ;
2016-01-21 02:01:05 +03:00
arg_start = mm - > arg_start ;
arg_end = mm - > arg_end ;
env_start = mm - > env_start ;
env_end = mm - > env_end ;
2019-06-01 08:30:19 +03:00
spin_unlock ( & mm - > arg_lock ) ;
2016-01-21 02:01:05 +03:00
len = arg_end - arg_start ;
2014-02-11 22:11:59 +04:00
if ( len > buflen )
len = buflen ;
2016-10-13 03:20:20 +03:00
res = access_process_vm ( task , arg_start , buffer , len , FOLL_FORCE ) ;
2014-02-11 22:11:59 +04:00
/*
* If the nul at the end of args has been overwritten , then
* assume application is using setproctitle ( 3 ) .
*/
if ( res > 0 & & buffer [ res - 1 ] ! = ' \0 ' & & len < buflen ) {
len = strnlen ( buffer , res ) ;
if ( len < res ) {
res = len ;
} else {
2016-01-21 02:01:05 +03:00
len = env_end - env_start ;
2014-02-11 22:11:59 +04:00
if ( len > buflen - res )
len = buflen - res ;
2016-01-21 02:01:05 +03:00
res + = access_process_vm ( task , env_start ,
2016-10-13 03:20:20 +03:00
buffer + res , len ,
FOLL_FORCE ) ;
2014-02-11 22:11:59 +04:00
res = strnlen ( buffer , res ) ;
}
}
out_mm :
mmput ( mm ) ;
out :
return res ;
}
2019-09-24 01:38:19 +03:00
int memcmp_pages ( struct page * page1 , struct page * page2 )
{
char * addr1 , * addr2 ;
int ret ;
addr1 = kmap_atomic ( page1 ) ;
addr2 = kmap_atomic ( page2 ) ;
ret = memcmp ( addr1 , addr2 , PAGE_SIZE ) ;
kunmap_atomic ( addr2 ) ;
kunmap_atomic ( addr1 ) ;
return ret ;
}