* [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup()
@ 2014-06-24 20:16 Konstantin Khlebnikov
2014-06-24 20:16 ` [PATCH 2/3] shmem: update memory reservation on truncate Konstantin Khlebnikov
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Konstantin Khlebnikov @ 2014-06-24 20:16 UTC (permalink / raw)
To: linux-mm, Andrew Morton; +Cc: Hugh Dickins, linux-kernel
If __shmem_file_setup() fails on struct file allocation it uncharges memory
commitment twice: first by shmem_unacct_size() and second time implicitly in
shmem_evict_inode() when it kills newly created inode.
This patch removes shmem_unacct_size() from error path if inode already here.
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
---
mm/shmem.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 8f419cf..0aabcbd 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2895,16 +2895,16 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
this.len = strlen(name);
this.hash = 0; /* will go */
sb = shm_mnt->mnt_sb;
+ path.mnt = mntget(shm_mnt);
path.dentry = d_alloc_pseudo(sb, &this);
if (!path.dentry)
goto put_memory;
d_set_d_op(path.dentry, &anon_ops);
- path.mnt = mntget(shm_mnt);
res = ERR_PTR(-ENOSPC);
inode = shmem_get_inode(sb, NULL, S_IFREG | S_IRWXUGO, 0, flags);
if (!inode)
- goto put_dentry;
+ goto put_memory;
inode->i_flags |= i_flags;
d_instantiate(path.dentry, inode);
@@ -2912,19 +2912,19 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
clear_nlink(inode); /* It is unlinked */
res = ERR_PTR(ramfs_nommu_expand_for_mapping(inode, size));
if (IS_ERR(res))
- goto put_dentry;
+ goto put_path;
res = alloc_file(&path, FMODE_WRITE | FMODE_READ,
&shmem_file_operations);
if (IS_ERR(res))
- goto put_dentry;
+ goto put_path;
return res;
-put_dentry:
- path_put(&path);
put_memory:
shmem_unacct_size(flags, size);
+put_path:
+ path_put(&path);
return res;
}
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/3] shmem: update memory reservation on truncate
2014-06-24 20:16 [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup() Konstantin Khlebnikov
@ 2014-06-24 20:16 ` Konstantin Khlebnikov
2014-06-26 3:53 ` Hugh Dickins
2014-06-24 20:16 ` [PATCH 3/3] mm: catch memory commitment underflow Konstantin Khlebnikov
2014-06-26 3:44 ` [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup() Hugh Dickins
2 siblings, 1 reply; 13+ messages in thread
From: Konstantin Khlebnikov @ 2014-06-24 20:16 UTC (permalink / raw)
To: linux-mm, Andrew Morton; +Cc: Hugh Dickins, linux-kernel
Shared anonymous mapping created without MAP_NORESERVE holds memory
reservation for whole range of shmem segment. Usually there is no way to
change its size, but /proc/<pid>/map_files/...
(available if CONFIG_CHECKPOINT_RESTORE=y) allows to do that.
This patch adjust memory reservation in shmem_setattr().
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
---
exploit:
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
int main(int argc, char **argv)
{
unsigned long addr;
char path[100];
/* charge 4KiB */
addr = (unsigned long)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
sprintf(path, "/proc/self/map_files/%lx-%lx", addr, addr + 4096);
truncate(path, 1 << 30);
/* uncharge 1GiB */
}
---
mm/shmem.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index 0aabcbd..a3c49d6 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -149,6 +149,19 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size)
vm_unacct_memory(VM_ACCT(size));
}
+static inline int shmem_reacct_size(unsigned long flags,
+ loff_t oldsize, loff_t newsize)
+{
+ if (!(flags & VM_NORESERVE)) {
+ if (VM_ACCT(newsize) > VM_ACCT(oldsize))
+ return security_vm_enough_memory_mm(current->mm,
+ VM_ACCT(newsize) - VM_ACCT(oldsize));
+ else if (VM_ACCT(newsize) < VM_ACCT(oldsize))
+ vm_unacct_memory(VM_ACCT(oldsize) - VM_ACCT(newsize));
+ }
+ return 0;
+}
+
/*
* ... whereas tmpfs objects are accounted incrementally as
* pages are allocated, in order to allow huge sparse files.
@@ -543,6 +556,10 @@ static int shmem_setattr(struct dentry *dentry, struct iattr *attr)
loff_t newsize = attr->ia_size;
if (newsize != oldsize) {
+ error = shmem_reacct_size(SHMEM_I(inode)->flags,
+ oldsize, newsize);
+ if (error)
+ return error;
i_size_write(inode, newsize);
inode->i_ctime = inode->i_mtime = CURRENT_TIME;
}
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 3/3] mm: catch memory commitment underflow
2014-06-24 20:16 [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup() Konstantin Khlebnikov
2014-06-24 20:16 ` [PATCH 2/3] shmem: update memory reservation on truncate Konstantin Khlebnikov
@ 2014-06-24 20:16 ` Konstantin Khlebnikov
2014-06-25 22:03 ` Andrew Morton
` (2 more replies)
2014-06-26 3:44 ` [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup() Hugh Dickins
2 siblings, 3 replies; 13+ messages in thread
From: Konstantin Khlebnikov @ 2014-06-24 20:16 UTC (permalink / raw)
To: linux-mm, Andrew Morton; +Cc: Hugh Dickins, linux-kernel
This patch prints warning (if CONFIG_DEBUG_VM=y) when
memory commitment becomes too negative.
Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
---
mm/mmap.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 129b847..d3decd9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -134,6 +134,12 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
unsigned long free, allowed, reserve;
+#ifdef CONFIG_DEBUG_VM
+ WARN_ONCE(percpu_counter_read(&vm_committed_as) <
+ -(s64)vm_committed_as_batch * num_online_cpus(),
+ "memory commitment underflow");
+#endif
+
vm_acct_memory(pages);
/*
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] mm: catch memory commitment underflow
2014-06-24 20:16 ` [PATCH 3/3] mm: catch memory commitment underflow Konstantin Khlebnikov
@ 2014-06-25 22:03 ` Andrew Morton
2014-06-26 4:08 ` Konstantin Khlebnikov
2014-06-25 22:23 ` Dave Hansen
2015-01-18 11:34 ` Sasha Levin
2 siblings, 1 reply; 13+ messages in thread
From: Andrew Morton @ 2014-06-25 22:03 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-mm, Hugh Dickins, linux-kernel
On Wed, 25 Jun 2014 00:16:14 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
> This patch prints warning (if CONFIG_DEBUG_VM=y) when
> memory commitment becomes too negative.
>
> ...
>
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -134,6 +134,12 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> {
> unsigned long free, allowed, reserve;
>
> +#ifdef CONFIG_DEBUG_VM
> + WARN_ONCE(percpu_counter_read(&vm_committed_as) <
> + -(s64)vm_committed_as_batch * num_online_cpus(),
> + "memory commitment underflow");
> +#endif
> +
> vm_acct_memory(pages);
The changelog doesn't describe the reasons for making the change.
I assume this warning will detect the situation which the previous two
patches just fixed?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] mm: catch memory commitment underflow
2014-06-24 20:16 ` [PATCH 3/3] mm: catch memory commitment underflow Konstantin Khlebnikov
2014-06-25 22:03 ` Andrew Morton
@ 2014-06-25 22:23 ` Dave Hansen
2015-01-18 11:34 ` Sasha Levin
2 siblings, 0 replies; 13+ messages in thread
From: Dave Hansen @ 2014-06-25 22:23 UTC (permalink / raw)
To: Konstantin Khlebnikov, linux-mm, Andrew Morton; +Cc: Hugh Dickins, linux-kernel
On 06/24/2014 01:16 PM, Konstantin Khlebnikov wrote:
> reserve;
>
> +#ifdef CONFIG_DEBUG_VM
> + WARN_ONCE(percpu_counter_read(&vm_committed_as) <
> + -(s64)vm_committed_as_batch * num_online_cpus(),
> + "memory commitment underflow");
> +#endif
Why not use VM_WARN_ON_ONCE()?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup()
2014-06-24 20:16 [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup() Konstantin Khlebnikov
2014-06-24 20:16 ` [PATCH 2/3] shmem: update memory reservation on truncate Konstantin Khlebnikov
2014-06-24 20:16 ` [PATCH 3/3] mm: catch memory commitment underflow Konstantin Khlebnikov
@ 2014-06-26 3:44 ` Hugh Dickins
2 siblings, 0 replies; 13+ messages in thread
From: Hugh Dickins @ 2014-06-26 3:44 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-mm, Andrew Morton, Hugh Dickins, linux-kernel
On Wed, 25 Jun 2014, Konstantin Khlebnikov wrote:
> If __shmem_file_setup() fails on struct file allocation it uncharges memory
> commitment twice: first by shmem_unacct_size() and second time implicitly in
> shmem_evict_inode() when it kills newly created inode.
> This patch removes shmem_unacct_size() from error path if inode already here.
>
> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Thank you for the patch, and thank you for your patience (or perhaps for
your kindly concealed impatience): I realize that this (and the other two)
have been languishing in the must-get-to-look-at-it-sometime end of my
mailbox for nine months now - sorry.
> ---
> mm/shmem.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 8f419cf..0aabcbd 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2895,16 +2895,16 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
> this.len = strlen(name);
> this.hash = 0; /* will go */
> sb = shm_mnt->mnt_sb;
> + path.mnt = mntget(shm_mnt);
> path.dentry = d_alloc_pseudo(sb, &this);
> if (!path.dentry)
> goto put_memory;
> d_set_d_op(path.dentry, &anon_ops);
> - path.mnt = mntget(shm_mnt);
>
> res = ERR_PTR(-ENOSPC);
> inode = shmem_get_inode(sb, NULL, S_IFREG | S_IRWXUGO, 0, flags);
> if (!inode)
> - goto put_dentry;
> + goto put_memory;
>
> inode->i_flags |= i_flags;
> d_instantiate(path.dentry, inode);
> @@ -2912,19 +2912,19 @@ static struct file *__shmem_file_setup(const char *name, loff_t size,
> clear_nlink(inode); /* It is unlinked */
> res = ERR_PTR(ramfs_nommu_expand_for_mapping(inode, size));
> if (IS_ERR(res))
> - goto put_dentry;
> + goto put_path;
>
> res = alloc_file(&path, FMODE_WRITE | FMODE_READ,
> &shmem_file_operations);
> if (IS_ERR(res))
> - goto put_dentry;
> + goto put_path;
>
> return res;
>
> -put_dentry:
> - path_put(&path);
> put_memory:
> shmem_unacct_size(flags, size);
> +put_path:
> + path_put(&path);
> return res;
> }
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/3] shmem: update memory reservation on truncate
2014-06-24 20:16 ` [PATCH 2/3] shmem: update memory reservation on truncate Konstantin Khlebnikov
@ 2014-06-26 3:53 ` Hugh Dickins
2014-06-26 11:27 ` Konstantin Khlebnikov
0 siblings, 1 reply; 13+ messages in thread
From: Hugh Dickins @ 2014-06-26 3:53 UTC (permalink / raw)
To: Konstantin Khlebnikov; +Cc: linux-mm, Andrew Morton, Hugh Dickins, linux-kernel
On Wed, 25 Jun 2014, Konstantin Khlebnikov wrote:
> Shared anonymous mapping created without MAP_NORESERVE holds memory
> reservation for whole range of shmem segment. Usually there is no way to
> change its size, but /proc/<pid>/map_files/...
> (available if CONFIG_CHECKPOINT_RESTORE=y) allows to do that.
>
> This patch adjust memory reservation in shmem_setattr().
>
> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Thank you, I knew nothing about this backdoor to shmem objects. Scary.
Was this really the only problem map_files access leads to? If you
did not do so already, please try to think through other possibilities.
I haven't begun, but perhaps it's not so bad. I guess the interaction
with mremap extension is benign - it's annoyed people in the past that
the underlying shmem object is not extended, but now here's a way that
it can be.
(I'll leave it to others comment on 3/3 if they wish.)
>
> ---
>
> exploit:
>
> #include <sys/mman.h>
> #include <unistd.h>
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
> unsigned long addr;
> char path[100];
>
> /* charge 4KiB */
> addr = (unsigned long)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
> sprintf(path, "/proc/self/map_files/%lx-%lx", addr, addr + 4096);
> truncate(path, 1 << 30);
> /* uncharge 1GiB */
> }
> ---
> mm/shmem.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 0aabcbd..a3c49d6 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -149,6 +149,19 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size)
> vm_unacct_memory(VM_ACCT(size));
> }
>
> +static inline int shmem_reacct_size(unsigned long flags,
> + loff_t oldsize, loff_t newsize)
> +{
> + if (!(flags & VM_NORESERVE)) {
> + if (VM_ACCT(newsize) > VM_ACCT(oldsize))
> + return security_vm_enough_memory_mm(current->mm,
> + VM_ACCT(newsize) - VM_ACCT(oldsize));
> + else if (VM_ACCT(newsize) < VM_ACCT(oldsize))
> + vm_unacct_memory(VM_ACCT(oldsize) - VM_ACCT(newsize));
> + }
> + return 0;
> +}
> +
> /*
> * ... whereas tmpfs objects are accounted incrementally as
> * pages are allocated, in order to allow huge sparse files.
> @@ -543,6 +556,10 @@ static int shmem_setattr(struct dentry *dentry, struct iattr *attr)
> loff_t newsize = attr->ia_size;
>
> if (newsize != oldsize) {
> + error = shmem_reacct_size(SHMEM_I(inode)->flags,
> + oldsize, newsize);
> + if (error)
> + return error;
> i_size_write(inode, newsize);
> inode->i_ctime = inode->i_mtime = CURRENT_TIME;
> }
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] mm: catch memory commitment underflow
2014-06-25 22:03 ` Andrew Morton
@ 2014-06-26 4:08 ` Konstantin Khlebnikov
0 siblings, 0 replies; 13+ messages in thread
From: Konstantin Khlebnikov @ 2014-06-26 4:08 UTC (permalink / raw)
To: Andrew Morton, Dave Hansen
Cc: linux-mm, Hugh Dickins, Linux Kernel Mailing List
On Thu, Jun 26, 2014 at 2:03 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 25 Jun 2014 00:16:14 +0400 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
>
>> This patch prints warning (if CONFIG_DEBUG_VM=y) when
>> memory commitment becomes too negative.
>>
>> ...
>>
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -134,6 +134,12 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>> {
>> unsigned long free, allowed, reserve;
>>
>> +#ifdef CONFIG_DEBUG_VM
>> + WARN_ONCE(percpu_counter_read(&vm_committed_as) <
>> + -(s64)vm_committed_as_batch * num_online_cpus(),
>> + "memory commitment underflow");
>> +#endif
>> +
>> vm_acct_memory(pages);
>
> The changelog doesn't describe the reasons for making the change.
>
> I assume this warning will detect the situation which the previous two
> patches just fixed?
Yep. Otherwise there is no way to validate these bugs, /proc/meminfo
hides negative values.
> Why not use VM_WARN_ON_ONCE()?
This patch is older than this macro.
Previously I've sent it in the last september and it was ignored. Now
I've found it again in my backlog.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/3] shmem: update memory reservation on truncate
2014-06-26 3:53 ` Hugh Dickins
@ 2014-06-26 11:27 ` Konstantin Khlebnikov
0 siblings, 0 replies; 13+ messages in thread
From: Konstantin Khlebnikov @ 2014-06-26 11:27 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linux-mm, Andrew Morton, Linux Kernel Mailing List
On Thu, Jun 26, 2014 at 7:53 AM, Hugh Dickins <hughd@google.com> wrote:
> On Wed, 25 Jun 2014, Konstantin Khlebnikov wrote:
>
>> Shared anonymous mapping created without MAP_NORESERVE holds memory
>> reservation for whole range of shmem segment. Usually there is no way to
>> change its size, but /proc/<pid>/map_files/...
>> (available if CONFIG_CHECKPOINT_RESTORE=y) allows to do that.
>>
>> This patch adjust memory reservation in shmem_setattr().
>>
>> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>
> Acked-by: Hugh Dickins <hughd@google.com>
>
> Thank you, I knew nothing about this backdoor to shmem objects. Scary.
> Was this really the only problem map_files access leads to? If you
> did not do so already, please try to think through other possibilities.
Ouch, it's still broken. I've fixed only truncate.
write_begin/write_end and fallocate might change i_size too.
>
> I haven't begun, but perhaps it's not so bad. I guess the interaction
> with mremap extension is benign - it's annoyed people in the past that
> the underlying shmem object is not extended, but now here's a way that
> it can be.
>
> (I'll leave it to others comment on 3/3 if they wish.)
>
>>
>> ---
>>
>> exploit:
>>
>> #include <sys/mman.h>
>> #include <unistd.h>
>> #include <stdio.h>
>>
>> int main(int argc, char **argv)
>> {
>> unsigned long addr;
>> char path[100];
>>
>> /* charge 4KiB */
>> addr = (unsigned long)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
>> sprintf(path, "/proc/self/map_files/%lx-%lx", addr, addr + 4096);
>> truncate(path, 1 << 30);
>> /* uncharge 1GiB */
>> }
>> ---
>> mm/shmem.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index 0aabcbd..a3c49d6 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -149,6 +149,19 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size)
>> vm_unacct_memory(VM_ACCT(size));
>> }
>>
>> +static inline int shmem_reacct_size(unsigned long flags,
>> + loff_t oldsize, loff_t newsize)
>> +{
>> + if (!(flags & VM_NORESERVE)) {
>> + if (VM_ACCT(newsize) > VM_ACCT(oldsize))
>> + return security_vm_enough_memory_mm(current->mm,
>> + VM_ACCT(newsize) - VM_ACCT(oldsize));
>> + else if (VM_ACCT(newsize) < VM_ACCT(oldsize))
>> + vm_unacct_memory(VM_ACCT(oldsize) - VM_ACCT(newsize));
>> + }
>> + return 0;
>> +}
>> +
>> /*
>> * ... whereas tmpfs objects are accounted incrementally as
>> * pages are allocated, in order to allow huge sparse files.
>> @@ -543,6 +556,10 @@ static int shmem_setattr(struct dentry *dentry, struct iattr *attr)
>> loff_t newsize = attr->ia_size;
>>
>> if (newsize != oldsize) {
>> + error = shmem_reacct_size(SHMEM_I(inode)->flags,
>> + oldsize, newsize);
>> + if (error)
>> + return error;
>> i_size_write(inode, newsize);
>> inode->i_ctime = inode->i_mtime = CURRENT_TIME;
>> }
>>
>>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] mm: catch memory commitment underflow
2014-06-24 20:16 ` [PATCH 3/3] mm: catch memory commitment underflow Konstantin Khlebnikov
2014-06-25 22:03 ` Andrew Morton
2014-06-25 22:23 ` Dave Hansen
@ 2015-01-18 11:34 ` Sasha Levin
2015-01-18 18:36 ` Konstantin Khlebnikov
2 siblings, 1 reply; 13+ messages in thread
From: Sasha Levin @ 2015-01-18 11:34 UTC (permalink / raw)
To: Konstantin Khlebnikov, linux-mm, Andrew Morton
Cc: Hugh Dickins, linux-kernel, Dave Hansen, Hugh Dickins
On 06/24/2014 04:16 PM, Konstantin Khlebnikov wrote:
> This patch prints warning (if CONFIG_DEBUG_VM=y) when
> memory commitment becomes too negative.
>
> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Hi Konstantin,
I seem to be hitting this warning when fuzzing on the latest -next kernel:
[ 683.674323] ------------[ cut here ]------------
[ 683.675552] WARNING: CPU: 12 PID: 25654 at mm/mmap.c:157 __vm_enough_memory+0x1b7/0x1d0()
[ 683.676972] memory commitment underflow
[ 683.678212] Modules linked in:
[ 683.678219] CPU: 12 PID: 25654 Comm: trinity-c373 Not tainted 3.19.0-rc4-next-20150116-sasha-00054-g4ad498c-dirty #1744
[ 683.678227] ffffffff9c6f7e73 ffff8802c0883a58 ffffffff9b439fb2 0000000000000000
[ 683.678231] ffff8802c0883aa8 ffff8802c0883a98 ffffffff98159e1a ffff8802c0883ae8
[ 683.678236] 0000000000000001 0000000000000000 ffffffffffff76f1 ffff8802a9749000
[ 683.678243] Call Trace:
[ 683.678288] dump_stack (lib/dump_stack.c:52)
[ 683.678297] warn_slowpath_common (kernel/panic.c:447)
[ 683.678302] warn_slowpath_fmt (kernel/panic.c:461)
[ 683.678307] __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[ 683.678317] cap_vm_enough_memory (security/commoncap.c:958)
[ 683.678323] security_vm_enough_memory_mm (security/security.c:212)
[ 683.678331] shmem_getpage_gfp (mm/shmem.c:1161)
[ 683.678337] shmem_write_begin (mm/shmem.c:1495)
[ 683.678343] generic_perform_write (mm/filemap.c:2491)
[ 683.678447] __generic_file_write_iter (mm/filemap.c:2632)
[ 683.678452] generic_file_write_iter (mm/filemap.c:2659)
[ 683.678458] do_iter_readv_writev (fs/read_write.c:680)
[ 683.678461] do_readv_writev (fs/read_write.c:848)
[ 683.678512] vfs_writev (fs/read_write.c:893)
[ 683.678515] SyS_writev (fs/read_write.c:926 fs/read_write.c:917)
[ 683.678520] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)
Thanks,
Sasha
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] mm: catch memory commitment underflow
2015-01-18 11:34 ` Sasha Levin
@ 2015-01-18 18:36 ` Konstantin Khlebnikov
2015-04-25 2:15 ` Sasha Levin
0 siblings, 1 reply; 13+ messages in thread
From: Konstantin Khlebnikov @ 2015-01-18 18:36 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-mm, Andrew Morton, Hugh Dickins, Linux Kernel Mailing List,
Dave Hansen
On Sun, Jan 18, 2015 at 2:34 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
> On 06/24/2014 04:16 PM, Konstantin Khlebnikov wrote:
>> This patch prints warning (if CONFIG_DEBUG_VM=y) when
>> memory commitment becomes too negative.
>>
>> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>
> Hi Konstantin,
>
> I seem to be hitting this warning when fuzzing on the latest -next kernel:
That might be unexpected change of shmem file which holds anon-vma data,
thanks to checkpoint-restore they are expoted via /proc/.../map_files
I've fixed truncate (https://lkml.org/lkml/2014/6/24/729) but there
are some other ways
to change i_size: write, fallocate and maybe something else.
We could seal this promblem (literally).
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3355,6 +3355,9 @@ static struct file *__shmem_file_setup(const
char *name, loff_t size,
if (!inode)
goto put_memory;
+ if (!(flags & VM_NORESERVE))
+ SHMEM_I(inode)->seals |= F_SEAL_SHRINK | F_SEAL_GROW;
+
inode->i_flags |= i_flags;
d_instantiate(path.dentry, inode);
inode->i_size = size;
>
> [ 683.674323] ------------[ cut here ]------------
> [ 683.675552] WARNING: CPU: 12 PID: 25654 at mm/mmap.c:157 __vm_enough_memory+0x1b7/0x1d0()
> [ 683.676972] memory commitment underflow
> [ 683.678212] Modules linked in:
> [ 683.678219] CPU: 12 PID: 25654 Comm: trinity-c373 Not tainted 3.19.0-rc4-next-20150116-sasha-00054-g4ad498c-dirty #1744
> [ 683.678227] ffffffff9c6f7e73 ffff8802c0883a58 ffffffff9b439fb2 0000000000000000
> [ 683.678231] ffff8802c0883aa8 ffff8802c0883a98 ffffffff98159e1a ffff8802c0883ae8
> [ 683.678236] 0000000000000001 0000000000000000 ffffffffffff76f1 ffff8802a9749000
> [ 683.678243] Call Trace:
> [ 683.678288] dump_stack (lib/dump_stack.c:52)
> [ 683.678297] warn_slowpath_common (kernel/panic.c:447)
> [ 683.678302] warn_slowpath_fmt (kernel/panic.c:461)
> [ 683.678307] __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
> [ 683.678317] cap_vm_enough_memory (security/commoncap.c:958)
> [ 683.678323] security_vm_enough_memory_mm (security/security.c:212)
> [ 683.678331] shmem_getpage_gfp (mm/shmem.c:1161)
> [ 683.678337] shmem_write_begin (mm/shmem.c:1495)
> [ 683.678343] generic_perform_write (mm/filemap.c:2491)
> [ 683.678447] __generic_file_write_iter (mm/filemap.c:2632)
> [ 683.678452] generic_file_write_iter (mm/filemap.c:2659)
> [ 683.678458] do_iter_readv_writev (fs/read_write.c:680)
> [ 683.678461] do_readv_writev (fs/read_write.c:848)
> [ 683.678512] vfs_writev (fs/read_write.c:893)
> [ 683.678515] SyS_writev (fs/read_write.c:926 fs/read_write.c:917)
> [ 683.678520] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)
>
>
> Thanks,
> Sasha
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] mm: catch memory commitment underflow
2015-01-18 18:36 ` Konstantin Khlebnikov
@ 2015-04-25 2:15 ` Sasha Levin
2015-06-07 14:29 ` Sasha Levin
0 siblings, 1 reply; 13+ messages in thread
From: Sasha Levin @ 2015-04-25 2:15 UTC (permalink / raw)
To: Konstantin Khlebnikov, Sasha Levin
Cc: linux-mm, Andrew Morton, Hugh Dickins, Linux Kernel Mailing List,
Dave Hansen
On 01/18/2015 01:36 PM, Konstantin Khlebnikov wrote:
> On Sun, Jan 18, 2015 at 2:34 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
>> On 06/24/2014 04:16 PM, Konstantin Khlebnikov wrote:
>>> This patch prints warning (if CONFIG_DEBUG_VM=y) when
>>> memory commitment becomes too negative.
>>>
>>> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>>
>> Hi Konstantin,
>>
>> I seem to be hitting this warning when fuzzing on the latest -next kernel:
>
> That might be unexpected change of shmem file which holds anon-vma data,
> thanks to checkpoint-restore they are expoted via /proc/.../map_files
>
> I've fixed truncate (https://lkml.org/lkml/2014/6/24/729) but there
> are some other ways
> to change i_size: write, fallocate and maybe something else.
deja vu!
With the latest -next:
[ 884.898243] ------------[ cut here ]------------
[ 884.899983] ------------[ cut here ]------------
[ 884.900013] WARNING: CPU: 5 PID: 17543 at mm/mmap.c:159 __vm_enough_memory+0x3b7/0x440()
[ 884.900017] ------------[ cut here ]------------
[ 884.900155] memory commitment underflow
[ 884.900158] Modules linked in:
[ 884.900167] CPU: 5 PID: 17543 Comm: trinity-c102 Not tainted 4.0.0-next-20150424-sasha-00038-ga61bf14 #2171
[ 884.900180] WARNING: CPU: 0 PID: 18483 at mm/mmap.c:159 __vm_enough_memory+0x3b7/0x440()
[ 884.900185] ffff88017e180000
[ 884.900188] memory commitment underflow
[ 884.900190] 0000000012331894
[ 884.900193] Modules linked in:
[ 884.900195] ffff8807dd8bf5a8
[ 884.900196]
[ 884.900200] ffffffffa9abbf32
[ 884.900211] 0000000000000000 ffff8807dd8bf628 ffff8807dd8bf5f8 ffffffff9f1f1c2a
[ 884.900222] ffff8807dd8bf5d8 ffffffff9f5efb27 ffff8807dd8bf628 ffffed00fbb17ec1
[ 884.900230] Call Trace:
[ 884.900247] dump_stack (lib/dump_stack.c:52)
[ 884.900260] warn_slowpath_common (kernel/panic.c:447)
[ 884.900270] ? __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[ 884.900278] warn_slowpath_fmt (kernel/panic.c:453)
[ 884.900286] ? warn_slowpath_common (kernel/panic.c:453)
[ 884.900300] ? find_get_entry (include/linux/rcupdate.h:969 mm/filemap.c:1003)
[ 884.900310] __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[ 884.900317] ? find_get_entry (mm/filemap.c:967)
[ 884.900334] cap_vm_enough_memory (security/commoncap.c:954)
[ 884.900344] security_vm_enough_memory_mm (security/security.c:235)
[ 884.900355] shmem_getpage_gfp (mm/shmem.c:1156)
[ 884.900369] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[ 884.900382] ? lockdep_init (include/linux/list.h:28 kernel/locking/lockdep.c:4065)
[ 884.900391] ? shmem_add_to_page_cache (mm/shmem.c:1034)
[ 884.900402] ? __wake_up_locked_key (kernel/sched/wait.c:456)
[ 884.900414] ? __bdi_update_bandwidth (mm/page-writeback.c:1579)
[ 884.900422] ? __lock_is_held (kernel/locking/lockdep.c:3572)
[ 884.900432] ? iov_iter_single_seg_count (lib/iov_iter.c:310)
[ 884.900441] shmem_write_begin (mm/shmem.c:1492)
[ 884.900450] generic_perform_write (mm/filemap.c:2467)
[ 884.900461] ? generic_write_checks (mm/filemap.c:2427)
[ 884.900475] ? file_update_time (fs/inode.c:1746)
[ 884.900483] ? file_remove_suid (fs/inode.c:1718)
[ 884.900492] ? generic_file_write_iter (include/linux/sched.h:3091 include/linux/sched.h:3102 mm/filemap.c:2269 mm/filemap.c:2622)
[ 884.900501] ? mutex_trylock (kernel/locking/mutex.c:615)
[ 884.900510] __generic_file_write_iter (mm/filemap.c:2597)
[ 884.900521] ? get_parent_ip (kernel/sched/core.c:2556)
[ 884.900531] generic_file_write_iter (mm/filemap.c:2625)
[ 884.900543] do_iter_readv_writev (fs/read_write.c:665)
[ 884.900551] ? do_readv_writev (include/linux/fs.h:2417 fs/read_write.c:804)
[ 884.900558] ? do_loop_readv_writev (fs/read_write.c:657)
[ 884.900567] ? rw_verify_area (fs/read_write.c:406 (discriminator 4))
[ 884.900576] do_readv_writev (fs/read_write.c:808)
[ 884.900583] ? __generic_file_write_iter (mm/filemap.c:2616)
[ 884.900591] ? vfs_write (fs/read_write.c:777)
[ 884.900601] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 884.900609] ? get_lock_stats (kernel/locking/lockdep.c:249)
[ 884.900621] ? vtime_account_user (kernel/sched/cputime.c:701)
[ 884.900630] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 884.900639] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636)
[ 884.900646] ? trace_hardirqs_on (kernel/locking/lockdep.c:2644)
[ 884.900654] vfs_writev (fs/read_write.c:848)
[ 884.900663] SyS_writev (fs/read_write.c:881 fs/read_write.c:872)
[ 884.900671] ? SyS_readv (fs/read_write.c:872)
[ 884.900684] ? syscall_trace_enter_phase2 (arch/x86/kernel/ptrace.c:1592)
[ 884.900693] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[ 884.900703] tracesys_phase2 (arch/x86/kernel/entry_64.S:337)
[ 884.900716] ? __percpu_counter_sum (lib/percpu_counter.c:107)
[ 884.900723] ---[ end trace 957b1b1a507acb40 ]---
[ 884.900730] CPU: 0 PID: 18483 Comm: trinity-c39 Not tainted 4.0.0-next-20150424-sasha-00038-ga61bf14 #2171
[ 884.900746] ffff880077ba3000 000000005dbf6d8b ffff88007bd8f5b8 ffffffffa9abbf32
[ 884.900759] 0000000000000000 ffff88007bd8f638 ffff88007bd8f608 ffffffff9f1f1c2a
[ 884.900771] ffff88007bd8f618 ffffffff9f5efb27 ffffffff9f2700d0 ffffed000f7b1ec3
[ 884.900774] Call Trace:
[ 884.900787] dump_stack (lib/dump_stack.c:52)
[ 884.900796] warn_slowpath_common (kernel/panic.c:447)
[ 884.900807] ? __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[ 884.900820] ? finish_task_switch (kernel/sched/sched.h:1077 kernel/sched/core.c:2245)
[ 884.900830] warn_slowpath_fmt (kernel/panic.c:453)
[ 884.900838] ? warn_slowpath_common (kernel/panic.c:453)
[ 884.900846] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 884.900863] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636)
[ 884.900873] __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[ 884.900883] ? find_get_entry (mm/filemap.c:967)
[ 884.900895] cap_vm_enough_memory (security/commoncap.c:954)
[ 884.900905] security_vm_enough_memory_mm (security/security.c:235)
[ 884.900912] ? security_vm_enough_memory_mm (security/security.c:234)
[ 884.900922] shmem_getpage_gfp (mm/shmem.c:1156)
[ 884.900931] ? lockdep_init (include/linux/list.h:28 kernel/locking/lockdep.c:4065)
[ 884.900940] ? shmem_add_to_page_cache (mm/shmem.c:1034)
[ 884.900950] ? __wake_up_locked_key (kernel/sched/wait.c:456)
[ 884.900960] ? __bdi_update_bandwidth (mm/page-writeback.c:1579)
[ 884.900968] ? __lock_is_held (kernel/locking/lockdep.c:3572)
[ 884.900977] ? iov_iter_single_seg_count (lib/iov_iter.c:310)
[ 884.900986] shmem_write_begin (mm/shmem.c:1492)
[ 884.900996] generic_perform_write (mm/filemap.c:2467)
[ 884.901011] ? generic_write_checks (mm/filemap.c:2427)
[ 884.901173] ? file_update_time (fs/inode.c:1746)
[ 884.901182] ? file_remove_suid (fs/inode.c:1718)
[ 884.901190] ? generic_file_write_iter (include/linux/sched.h:3091 include/linux/sched.h:3102 mm/filemap.c:2269 mm/filemap.c:2622)
[ 884.901199] ? mutex_trylock (kernel/locking/mutex.c:615)
[ 884.901207] __generic_file_write_iter (mm/filemap.c:2597)
[ 884.901217] ? get_parent_ip (kernel/sched/core.c:2556)
[ 884.901228] generic_file_write_iter (mm/filemap.c:2625)
[ 884.901240] do_iter_readv_writev (fs/read_write.c:665)
[ 884.901248] ? do_readv_writev (include/linux/fs.h:2417 fs/read_write.c:804)
[ 884.901257] ? do_loop_readv_writev (fs/read_write.c:657)
[ 884.901269] ? rw_verify_area (fs/read_write.c:406 (discriminator 4))
[ 884.901278] do_readv_writev (fs/read_write.c:808)
[ 884.901288] ? __generic_file_write_iter (mm/filemap.c:2616)
[ 884.901297] ? vfs_write (fs/read_write.c:777)
[ 884.901306] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 884.901314] ? get_lock_stats (kernel/locking/lockdep.c:249)
[ 884.901326] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 884.901336] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636)
[ 884.901345] ? trace_hardirqs_on (kernel/locking/lockdep.c:2644)
[ 884.901355] vfs_writev (fs/read_write.c:848)
[ 884.901365] ? __fdget_pos (fs/file.c:717)
[ 884.901374] SyS_pwritev (include/linux/file.h:38 fs/read_write.c:937 fs/read_write.c:922)
[ 884.901382] ? SyS_preadv (fs/read_write.c:922)
[ 884.901393] ? syscall_trace_enter_phase2 (arch/x86/kernel/ptrace.c:1592)
[ 884.901404] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[ 884.901414] tracesys_phase2 (arch/x86/kernel/entry_64.S:337)
[ 884.901423] ---[ end trace 957b1b1a507acb41 ]---
[ 885.133658] WARNING: CPU: 6 PID: 17218 at mm/mmap.c:159 __vm_enough_memory+0x3b7/0x440()
[ 885.136475] memory commitment underflow
[ 885.137807] Modules linked in:
[ 885.139002] CPU: 6 PID: 17218 Comm: trinity-c296 Tainted: G W 4.0.0-next-20150424-sasha-00038-ga61bf14 #2171
[ 885.142889] ffff88078e4a8000 0000000057b5e6a5 ffff88078e6275a8 ffffffffa9abbf32
[ 885.145640] 0000000000000000 ffff88078e627628 ffff88078e6275f8 ffffffff9f1f1c2a
[ 885.148334] ffff88078e6275d8 ffffffff9f5efb27 ffff88078e627628 ffffed00f1cc4ec1
[ 885.150427] Call Trace:
[ 885.151080] dump_stack (lib/dump_stack.c:52)
[ 885.152771] warn_slowpath_common (kernel/panic.c:447)
[ 885.154819] ? __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[ 885.156674] warn_slowpath_fmt (kernel/panic.c:453)
[ 885.158168] ? warn_slowpath_common (kernel/panic.c:453)
[ 885.159853] ? find_get_entry (include/linux/rcupdate.h:969 mm/filemap.c:1003)
[ 885.161311] __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[ 885.162823] ? find_get_entry (mm/filemap.c:967)
[ 885.164599] cap_vm_enough_memory (security/commoncap.c:954)
[ 885.166588] security_vm_enough_memory_mm (security/security.c:235)
[ 885.168923] shmem_getpage_gfp (mm/shmem.c:1156)
[ 885.170990] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[ 885.173230] ? lockdep_init (include/linux/list.h:28 kernel/locking/lockdep.c:4065)
[ 885.175228] ? shmem_add_to_page_cache (mm/shmem.c:1034)
[ 885.177492] ? __wake_up_locked_key (kernel/sched/wait.c:456)
[ 885.179648] ? __bdi_update_bandwidth (mm/page-writeback.c:1579)
[ 885.181288] ? __lock_is_held (kernel/locking/lockdep.c:3572)
[ 885.182750] ? __wake_up_bit (kernel/sched/wait.c:456)
[ 885.184418] ? iov_iter_single_seg_count (lib/iov_iter.c:310)
[ 885.186728] shmem_write_begin (mm/shmem.c:1492)
[ 885.188751] generic_perform_write (mm/filemap.c:2467)
[ 885.190906] ? generic_write_checks (mm/filemap.c:2427)
[ 885.193252] ? file_update_time (fs/inode.c:1746)
[ 885.195344] ? file_remove_suid (fs/inode.c:1718)
[ 885.196996] ? generic_file_write_iter (include/linux/sched.h:3091 include/linux/sched.h:3102 mm/filemap.c:2269 mm/filemap.c:2622)
[ 885.198672] ? mutex_trylock (kernel/locking/mutex.c:615)
[ 885.200440] __generic_file_write_iter (mm/filemap.c:2597)
[ 885.202666] ? get_parent_ip (kernel/sched/core.c:2556)
[ 885.204647] generic_file_write_iter (mm/filemap.c:2625)
[ 885.206875] do_iter_readv_writev (fs/read_write.c:665)
[ 885.209242] ? do_readv_writev (include/linux/fs.h:2417 fs/read_write.c:804)
[ 885.211306] ? do_loop_readv_writev (fs/read_write.c:657)
[ 885.213414] ? rw_verify_area (fs/read_write.c:406 (discriminator 4))
[ 885.215263] do_readv_writev (fs/read_write.c:808)
[ 885.216855] ? __generic_file_write_iter (mm/filemap.c:2616)
[ 885.218482] ? vfs_write (fs/read_write.c:777)
[ 885.219931] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 885.222062] ? get_lock_stats (kernel/locking/lockdep.c:249)
[ 885.224275] ? vtime_account_user (kernel/sched/cputime.c:701)
[ 885.226375] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 885.228472] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 kernel/locking/lockdep.c:2636)
[ 885.230673] ? trace_hardirqs_on (kernel/locking/lockdep.c:2644)
[ 885.232751] vfs_writev (fs/read_write.c:848)
[ 885.234490] SyS_writev (fs/read_write.c:881 fs/read_write.c:872)
[ 885.236473] ? SyS_readv (fs/read_write.c:872)
[ 885.238300] ? syscall_trace_enter_phase2 (arch/x86/kernel/ptrace.c:1592)
[ 885.240677] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[ 885.242909] tracesys_phase2 (arch/x86/kernel/entry_64.S:337)
[ 885.246363] ---[ end trace 957b1b1a507acb42 ]---
Thanks,
Sasha
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] mm: catch memory commitment underflow
2015-04-25 2:15 ` Sasha Levin
@ 2015-06-07 14:29 ` Sasha Levin
0 siblings, 0 replies; 13+ messages in thread
From: Sasha Levin @ 2015-06-07 14:29 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: linux-mm, Andrew Morton, Hugh Dickins, Linux Kernel Mailing List,
Dave Hansen
On 04/24/2015 10:15 PM, Sasha Levin wrote:
> On 01/18/2015 01:36 PM, Konstantin Khlebnikov wrote:
>> On Sun, Jan 18, 2015 at 2:34 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
>>> On 06/24/2014 04:16 PM, Konstantin Khlebnikov wrote:
>>>> This patch prints warning (if CONFIG_DEBUG_VM=y) when
>>>> memory commitment becomes too negative.
>>>>
>>>> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
>>>
>>> Hi Konstantin,
>>>
>>> I seem to be hitting this warning when fuzzing on the latest -next kernel:
>>
>> That might be unexpected change of shmem file which holds anon-vma data,
>> thanks to checkpoint-restore they are expoted via /proc/.../map_files
>>
>> I've fixed truncate (https://lkml.org/lkml/2014/6/24/729) but there
>> are some other ways
>> to change i_size: write, fallocate and maybe something else.
>
> deja vu!
>
> With the latest -next:
Ping? I'm still seeing this in -next:
[668829.173774] ------------[ cut here ]------------
[668829.175259] WARNING: CPU: 18 PID: 4414 at mm/mmap.c:160 __vm_enough_memory+0x39f/0x430()
[668829.177864] memory commitment underflow
[668829.179049] Modules linked in:
[668829.180183] CPU: 18 PID: 4414 Comm: trinity-c21 Tainted: G W 4.1.0-rc6-next-20150604-sasha-00039-g07bbbaf-dirty #2269
[668829.183509] ffff8805326b0000 0000000059024457 ffff88008d387cb8 ffffffff9fa02938
[668829.186008] 0000000000000000 ffff88008d387d38 ffff88008d387d08 ffffffff961e5336
[668829.188330] ffff8805326b1190 ffffffff965639df ffff8805326b0000 ffffed0011a70fa3
[668829.189512] Call Trace:
[668829.189863] [<ffffffff9fa02938>] dump_stack+0x4f/0x7b
[668829.190745] [<ffffffff961e5336>] warn_slowpath_common+0xc6/0x120
[668829.191735] [<ffffffff965639df>] ? __vm_enough_memory+0x39f/0x430
[668829.192740] [<ffffffff961e5445>] warn_slowpath_fmt+0xb5/0xf0
[668829.193588] [<ffffffff961e5390>] ? warn_slowpath_common+0x120/0x120
[668829.194554] [<ffffffff96018040>] ? arch_get_unmapped_area+0x5e0/0x5e0
[668829.195709] [<ffffffff962f08dc>] ? do_raw_spin_unlock+0x16c/0x260
[668829.196897] [<ffffffff97dae510>] ? check_preemption_disabled+0x70/0x1f0
[668829.198035] [<ffffffff965639df>] __vm_enough_memory+0x39f/0x430
[668829.199086] [<ffffffff97b052df>] security_vm_enough_memory_mm+0x7f/0xa0
[668829.200248] [<ffffffff9656ab64>] do_brk+0x3a4/0x910
[668829.201063] [<ffffffff9656b213>] ? SyS_brk+0x63/0x3e0
[668829.202033] [<ffffffff9656b213>] ? SyS_brk+0x63/0x3e0
[668829.202896] [<ffffffff9656b445>] SyS_brk+0x295/0x3e0
[668829.203701] [<ffffffff9fa6f6e2>] tracesys_phase2+0x88/0x8d
[668829.205084] ---[ end trace 3d1f7fa1a382323f ]---
[668829.205871] ------------[ cut here ]------------
[668829.205883] WARNING: CPU: 21 PID: 4719 at mm/mmap.c:160 __vm_enough_memory+0x39f/0x430()
[668829.205887] memory commitment underflow
[668829.205890] Modules linked in:
[668829.205899] CPU: 21 PID: 4719 Comm: kworker/u56:0 Tainted: G W 4.1.0-rc6-next-20150604-sasha-00039-g07bbbaf-dirty #2269
[668829.205910] ffff8808663d0000 000000009a8c3981 ffff880866207738 ffffffff9fa02938
[668829.205918] 0000000000000000 ffff8808662077b8 ffff880866207788 ffffffff961e5336
[668829.205926] ffff880866207768 ffffffff965639df ffff880a70f2455c ffffed010cc40ef3
[668829.205927] Call Trace:
[668829.205938] [<ffffffff9fa02938>] dump_stack+0x4f/0x7b
[668829.205948] [<ffffffff961e5336>] warn_slowpath_common+0xc6/0x120
[668829.205957] [<ffffffff965639df>] ? __vm_enough_memory+0x39f/0x430
[668829.205966] [<ffffffff961e5445>] warn_slowpath_fmt+0xb5/0xf0
[668829.205975] [<ffffffff961e5390>] ? warn_slowpath_common+0x120/0x120
[668829.205986] [<ffffffff97dae6a7>] ? debug_smp_processor_id+0x17/0x20
[668829.205996] [<ffffffff965639df>] __vm_enough_memory+0x39f/0x430
[668829.206008] [<ffffffff97b052df>] security_vm_enough_memory_mm+0x7f/0xa0
[668829.206017] [<ffffffff96568cc8>] expand_downwards+0x3f8/0xd30
[668829.206028] [<ffffffff9fa6e485>] ? _raw_spin_unlock+0x35/0x60
[668829.206039] [<ffffffff96558812>] handle_mm_fault+0x24b2/0x4440
[668829.206049] [<ffffffff962d711e>] ? trace_hardirqs_on_caller+0x2de/0x670
[668829.206057] [<ffffffff962d9920>] ? lockdep_init+0xf0/0xf0
[668829.206067] [<ffffffff96556360>] ? copy_page_range+0x1a00/0x1a00
[668829.206073] [<ffffffff962da139>] ? __lock_is_held+0xa9/0xf0
[668829.206080] [<ffffffff962da316>] ? lock_is_held+0x196/0x1f0
[668829.206091] [<ffffffff965465f7>] ? follow_page_mask+0x87/0xa70
[668829.206098] [<ffffffff965472e2>] __get_user_pages+0x302/0xfb0
[668829.206103] [<ffffffff962d9920>] ? lockdep_init+0xf0/0xf0
[668829.206112] [<ffffffff966047a0>] ? default_llseek+0x270/0x270
[668829.206122] [<ffffffff9667407a>] ? generic_getxattr+0xda/0x130
[668829.206129] [<ffffffff96546fe0>] ? follow_page_mask+0xa70/0xa70
[668829.206135] [<ffffffff962da316>] ? lock_is_held+0x196/0x1f0
[668829.206142] [<ffffffff965485b2>] get_user_pages+0x52/0x60
[668829.206151] [<ffffffff96617484>] copy_strings.isra.24+0x284/0x660
[668829.206158] [<ffffffff96617200>] ? get_user_arg_ptr.isra.20+0x70/0x70
[668829.206165] [<ffffffff966178e9>] copy_strings_kernel+0x89/0x110
[668829.206171] [<ffffffff9661ba56>] do_execveat_common.isra.28+0xfa6/0x1b10
[668829.206177] [<ffffffff9661aedd>] ? do_execveat_common.isra.28+0x42d/0x1b10
[668829.206184] [<ffffffff965c2d25>] ? arch_local_irq_restore+0x15/0x20
[668829.206197] [<ffffffff9661aab0>] ? prepare_bprm_creds+0x100/0x100
[668829.206331] [<ffffffff962da316>] ? lock_is_held+0x196/0x1f0
[668829.206342] [<ffffffff96321563>] ? rcu_read_lock_sched_held+0x1a3/0x1c0
[668829.206349] [<ffffffff965c7d08>] ? kmem_cache_alloc+0x248/0x2d0
[668829.206357] [<ffffffff965cd19a>] ? memcpy+0x3a/0x50
[668829.206363] [<ffffffff9661c5ec>] do_execve+0x2c/0x30
[668829.206372] [<ffffffff96226d1f>] ____call_usermodehelper+0x29f/0x440
[668829.206378] [<ffffffff96226a80>] ? __call_usermodehelper+0xc0/0xc0
[668829.206385] [<ffffffff9fa6fa1f>] ret_from_fork+0x3f/0x70
[668829.206392] [<ffffffff96226a80>] ? __call_usermodehelper+0xc0/0xc0
Thanks,
Sasha
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-06-07 14:31 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-24 20:16 [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup() Konstantin Khlebnikov
2014-06-24 20:16 ` [PATCH 2/3] shmem: update memory reservation on truncate Konstantin Khlebnikov
2014-06-26 3:53 ` Hugh Dickins
2014-06-26 11:27 ` Konstantin Khlebnikov
2014-06-24 20:16 ` [PATCH 3/3] mm: catch memory commitment underflow Konstantin Khlebnikov
2014-06-25 22:03 ` Andrew Morton
2014-06-26 4:08 ` Konstantin Khlebnikov
2014-06-25 22:23 ` Dave Hansen
2015-01-18 11:34 ` Sasha Levin
2015-01-18 18:36 ` Konstantin Khlebnikov
2015-04-25 2:15 ` Sasha Levin
2015-06-07 14:29 ` Sasha Levin
2014-06-26 3:44 ` [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup() Hugh Dickins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).