[PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup()

[PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup()

[Konstantin Khlebnikov]

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;
 }
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 2/3] shmem: update memory reservation on truncate

[Konstantin Khlebnikov]

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;
 		}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/3] shmem: update memory reservation on truncate

[Hugh Dickins]

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;
>  		}
> 
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/3] shmem: update memory reservation on truncate

[Konstantin Khlebnikov]

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;
>>               }
>>
>>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 3/3] mm: catch memory commitment underflow

[Konstantin Khlebnikov]

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);
 
 	/*

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Andrew Morton]

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?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Konstantin Khlebnikov]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Dave Hansen]

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()?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Sasha Levin]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Konstantin Khlebnikov]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Sasha Levin]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Sasha Levin]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup()

[Hugh Dickins]

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;
>  }
>  

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>