current->mm == NULL in security_vm_enough_memory().

current->mm == NULL in security_vm_enough_memory().

[Tetsuo Handa]

Hello.

2.6.28 and later have a "current->mm != NULL" checking
added by commit 731572d39fcd3498702eda4600db4c43d51e0b26 .

  int security_vm_enough_memory(long pages)
  {
  	WARN_ON(current->mm == NULL);
  	return security_ops->vm_enough_memory(current->mm, pages);
  }

I encountered this warning on Debian Sarge.
Config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.29-next-20090324 .

Mounting local filesystems...
[   18.746829] kjournald starting.  Commit interval 5 seconds
[   18.754102] EXT3 FS on sdb1, internal journal
[   18.756928] EXT3-fs: mounted filesystem with ordered data mode.
/dev/sdb1 on /usr/src/all type ext3 (rw,noatime,nodiratime)
Cleaning /tmp /var/run /var/lock.
Detecting hardware: agpgart pcnet32 piix BusLogic ide_scsi
Skipping unavailable/built-in agpgart module.
pcnet32 disabled in configuration.
Skipping unavailable/built-in piix module.
Skipping unavailable/built-in BusLogic module.
Skipping unavailable/built-in ide_scsi module.
Running 0dns-down to make sure resolv.conf is ok...done.
Setting up networking...done.
Starting hotplug subsystem:
   pci
     ignoring pci display device 00:0f.0
[   28.728908] pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
[   28.735902] pcnet32: PCnet/PCI II 79C970A at 0x2000, 00:0c:29:9e:eb:32 assigned IRQ 18.
[   28.754197] eth0: registered as PCnet/PCI II 79C970A
[   28.758543] pcnet32: 1 cards_found.
[   28.765817] ------------[ cut here ]------------
[   28.768916] WARNING: at security/security.c:217 security_vm_enough_memory+0xa0/0xb0()
[   28.772484] Hardware name: VMware Virtual Platform
[   28.774099] Modules linked in: pcnet32 crc32
[   28.776920] Pid: 3286, comm: khelper Not tainted 2.6.29-next-20090324-dirty #3
[   28.780317] Call Trace:
[   28.781323]  [<c0159200>] ? have_callable_console+0x30/0x50
[   28.784171]  [<c0158497>] warn_slowpath+0x97/0xf0
[   28.785739]  [<c0190f7c>] ? validate_chain+0x3fc/0x540
[   28.788402]  [<c0190f7c>] ? validate_chain+0x3fc/0x540
[   28.790103]  [<c0192dfc>] ? __lock_acquire+0x29c/0x8a0
[   28.792809]  [<c0194859>] ? __lock_acquired+0x109/0x1c0
[   28.794539]  [<c0338ea0>] security_vm_enough_memory+0xa0/0xb0
[   28.797391]  [<c0202117>] acct_stack_growth+0xd7/0x160
[   28.798842]  [<c02022b9>] expand_downwards+0x119/0x150
[   28.801709]  [<c020230d>] expand_stack+0xd/0x10
[   28.804171]  [<c02023bd>] find_extend_vma+0xad/0x110
[   28.805806]  [<c01f9c04>] __get_user_pages+0x94/0x610
[   28.808557]  [<c01fa1fb>] get_user_pages+0x7b/0x90
[   28.810483]  [<c022c028>] get_arg_page+0x48/0x100
[   28.812972]  [<c022c58c>] copy_strings+0x16c/0x2a0
[   28.814552]  [<c022ea52>] do_execve+0x6b2/0x7e0
[   28.817138]  [<c02320eb>] ? getname+0x6b/0xa0
[   28.818622]  [<c010237e>] sys_execve+0x5e/0xb0
[   28.821006]  [<c0103d19>] syscall_call+0x7/0xb
[   28.822469]  [<c010ae94>] ? kernel_execve+0x24/0x30
[   28.825161]  [<c01729af>] ? ____call_usermodehelper+0xff/0x170
[   28.828052]  [<c01728b0>] ? ____call_usermodehelper+0x0/0x170
[   28.829944]  [<c0104707>] ? kernel_thread_helper+0x7/0x10
[   28.832802] ---[ end trace 2e6964f14bb57083 ]---

May I ignore this warning?

Regards.

Re: current->mm == NULL in security_vm_enough_memory().

[James Morris]

On Thu, 26 Mar 2009, Tetsuo Handa wrote:

> [   28.765817] ------------[ cut here ]------------
> [   28.768916] WARNING: at security/security.c:217 security_vm_enough_memory+0xa0/0xb0()
> [   28.772484] Hardware name: VMware Virtual Platform
> [   28.774099] Modules linked in: pcnet32 crc32
> [   28.776920] Pid: 3286, comm: khelper Not tainted 2.6.29-next-20090324-dirty #3
> [   28.780317] Call Trace:
> [   28.781323]  [<c0159200>] ? have_callable_console+0x30/0x50
> [   28.784171]  [<c0158497>] warn_slowpath+0x97/0xf0
> [   28.785739]  [<c0190f7c>] ? validate_chain+0x3fc/0x540
> [   28.788402]  [<c0190f7c>] ? validate_chain+0x3fc/0x540
> [   28.790103]  [<c0192dfc>] ? __lock_acquire+0x29c/0x8a0
> [   28.792809]  [<c0194859>] ? __lock_acquired+0x109/0x1c0
> [   28.794539]  [<c0338ea0>] security_vm_enough_memory+0xa0/0xb0
> [   28.797391]  [<c0202117>] acct_stack_growth+0xd7/0x160
> [   28.798842]  [<c02022b9>] expand_downwards+0x119/0x150
> [   28.801709]  [<c020230d>] expand_stack+0xd/0x10
> [   28.804171]  [<c02023bd>] find_extend_vma+0xad/0x110
> [   28.805806]  [<c01f9c04>] __get_user_pages+0x94/0x610
> [   28.808557]  [<c01fa1fb>] get_user_pages+0x7b/0x90
> [   28.810483]  [<c022c028>] get_arg_page+0x48/0x100
> [   28.812972]  [<c022c58c>] copy_strings+0x16c/0x2a0
> [   28.814552]  [<c022ea52>] do_execve+0x6b2/0x7e0
> [   28.817138]  [<c02320eb>] ? getname+0x6b/0xa0
> [   28.818622]  [<c010237e>] sys_execve+0x5e/0xb0
> [   28.821006]  [<c0103d19>] syscall_call+0x7/0xb
> [   28.822469]  [<c010ae94>] ? kernel_execve+0x24/0x30
> [   28.825161]  [<c01729af>] ? ____call_usermodehelper+0xff/0x170
> [   28.828052]  [<c01728b0>] ? ____call_usermodehelper+0x0/0x170
> [   28.829944]  [<c0104707>] ? kernel_thread_helper+0x7/0x10
> [   28.832802] ---[ end trace 2e6964f14bb57083 ]---
> 
> May I ignore this warning?

khelper is a kernel thread, so it should not have an ->mm, but I wonder 
why this hasn't shown up before.  Odd...


- James
-- 
James Morris
<jmorris@namei.org>

Re: current->mm == NULL in security_vm_enough_memory().

[hooanon05]

James Morris:
> On Thu, 26 Mar 2009, Tetsuo Handa wrote:
> 
> > [   28.765817] ------------[ cut here ]------------
> > [   28.768916] WARNING: at security/security.c:217 security_vm_enough_memory+0xa0/0xb0()
> > [   28.772484] Hardware name: VMware Virtual Platform
> > [   28.774099] Modules linked in: pcnet32 crc32
> > [   28.776920] Pid: 3286, comm: khelper Not tainted 2.6.29-next-20090324-dirty #3
> > [   28.780317] Call Trace:
> > [   28.781323]  [<c0159200>] ? have_callable_console+0x30/0x50
> > [   28.784171]  [<c0158497>] warn_slowpath+0x97/0xf0
> > [   28.785739]  [<c0190f7c>] ? validate_chain+0x3fc/0x540
> > [   28.788402]  [<c0190f7c>] ? validate_chain+0x3fc/0x540
> > [   28.790103]  [<c0192dfc>] ? __lock_acquire+0x29c/0x8a0
> > [   28.792809]  [<c0194859>] ? __lock_acquired+0x109/0x1c0
> > [   28.794539]  [<c0338ea0>] security_vm_enough_memory+0xa0/0xb0
> > [   28.797391]  [<c0202117>] acct_stack_growth+0xd7/0x160
> > [   28.798842]  [<c02022b9>] expand_downwards+0x119/0x150
> > [   28.801709]  [<c020230d>] expand_stack+0xd/0x10
	:::
> > May I ignore this warning?
> 
> khelper is a kernel thread, so it should not have an ->mm, but I wonder 
> why this hasn't shown up before.  Odd...

The patch was merged in 2.6.28. See this url in detail.
http://marc.info/?t=122460314500001&r=1&w=2
Subject: __vm_enough_memory(), OVERCOMMIT_NEVER, current->mm, kernel thread

With this discussion, a new function security_vm_enough_memory_kern()
was introduced. All kernel thread should call this new one instead of
security_vm_enough_memory(). The added WARN_ON() worked exactly as Alan
Cox expected.
But I am not sure this is the case. When expand_stack() is called in the
user context, to call ..._kern() may be a bad idea.


J. R. Okajima

Re: current->mm == NULL in security_vm_enough_memory().

[Tetsuo Handa]

James Morris wrote:
> khelper is a kernel thread, so it should not have an ->mm, but I wonder
> why this hasn't shown up before.  Odd...

I don't see this message for 2.6.29 and earlier.
As of 2.6.30-rc1, this problem is not solved yet.
I think something happened between 2.6.29 and 2.6.30-rc1.

http://I-love.SAKURA.ne.jp/tmp/dmesg-2.6.30-rc1.txt
http://I-love.SAKURA.ne.jp/tmp/config-2.6.30-rc1

Re: current->mm == NULL in security_vm_enough_memory().

[hooanon05]

Tetsuo Handa:
> I don't see this message for 2.6.29 and earlier.
> As of 2.6.30-rc1, this problem is not solved yet.
> I think something happened between 2.6.29 and 2.6.30-rc1.

I could not reproduce the problem.
Are there any conditions?


J. R. Okajima

Re: current->mm == NULL in security_vm_enough_memory().

[Tetsuo Handa]

Hello.

I'm experiencing

  WARNING: at security/security.c:217 security_vm_enough_memory+0xa0/0xb0()

messages.
"git bisect" reported that commit f520360d93cdc37de5d972dac4bf3bdef6a7f6a7
is the cause of this warning. May I ignore this warning?

Regards.

Tetsuo Handa wrote:
> James Morris wrote:
> > khelper is a kernel thread, so it should not have an ->mm, but I wonder
> > why this hasn't shown up before.  Odd...
> 
> I don't see this message for 2.6.29 and earlier.
> As of 2.6.30-rc1, this problem is not solved yet.
> I think something happened between 2.6.29 and 2.6.30-rc1.
> 
> http://I-love.SAKURA.ne.jp/tmp/dmesg-2.6.30-rc1.txt
> http://I-love.SAKURA.ne.jp/tmp/config-2.6.30-rc1

# git bisect start v2.6.30-rc1 v2.6.29 -- arch/x86/ fs/ kernel/ include/asm-generic/
Bisecting: 1304 revisions left to test after this
[749b0afc3a9d90dda3319fd1464a3b32fc225361] kexec: Change kexec jump code ordering
# git bisect bad
Bisecting: 639 revisions left to test after this
[6d2e91bf80e4410207f01edb0962aec9213f3533] Merge branch 'x86/urgent' into x86/mm
# git bisect good
Bisecting: 326 revisions left to test after this
[6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2
# git bisect bad
Bisecting: 163 revisions left to test after this
[13220a94d35708d5378114e96ffcc88d0a74fe99] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
# git bisect bad
Bisecting: 81 revisions left to test after this
[08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
# git bisect bad
Bisecting: 44 revisions left to test after this
[562f477a54478002ddfbb5b85627c009ca41e71d] Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
# git bisect good
Bisecting: 23 revisions left to test after this
[8ff64b539bfd998792614481ccb67139b97075ef] Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw
# git bisect good
Bisecting: 11 revisions left to test after this
[aa4abc9bcce0d2a7ec189e897f8f8c58ca04643b] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
# git bisect good
Bisecting: 5 revisions left to test after this
[f67f129e519fa87f8ebd236b6336fe43f31ee141] Driver core: implement uevent suppress in kobject
# git bisect good
Bisecting: 2 revisions left to test after this
[e9d376f0fa66bd630fe27403669c6ae6c22a868f] dynamic debug: combine dprintk and dynamic printk
# git bisect bad
Bisecting: 1 revisions left to test after this
[669420644c79c207f83fdf9105ae782867e2991f] sysfs: only allow one scheduled removal callback per kobj
# gid bisect good
(...snipped...)
# git bisect reset
(...snipped...)
# git bisect start e9d376f0fa66bd630fe27403669c6ae6c22a868f v2.6.29 6d2e91bf80e4410207f01edb0962aec9213f3533 562f477a54478002ddfbb5b85627c009ca41e71d 8ff64b539bfd998792614481ccb67139b97075ef aa4abc9bcce0d2a7ec189e897f8f8c58ca04643b f67f129e519fa87f8ebd236b6336fe43f31ee141 669420644c79c207f83fdf9105ae782867e2991f
Bisecting: 1 revisions left to test after this
[095160aee954688a9bad225952c4bee546541e19] sysfs: fix some bin_vm_ops errors
# git bisect bad
Bisecting: 0 revisions left to test after this
[f520360d93cdc37de5d972dac4bf3bdef6a7f6a7] kobject: don't block for each kobject_uevent
# git bisect bad
f520360d93cdc37de5d972dac4bf3bdef6a7f6a7 is first bad commit
commit f520360d93cdc37de5d972dac4bf3bdef6a7f6a7
Author: Arjan van de Ven <arjan@linux.intel.com>
Date:   Thu Mar 19 09:09:05 2009 -0700

    kobject: don't block for each kobject_uevent

    Right now, the kobject_uevent code blocks for each uevent that's being
    generated, due to using (for hystoric reasons) UHM_WAIT_EXEC as flag to
    call_usermode_helper().  Specifically, the effect is that each uevent
    that is being sent causes the code to wake up keventd, then block until
    keventd has processed the work. Needless to say, this happens many times
    during the system boot.

    This patches changes that to UHN_NO_WAIT (brilliant name for a constant
    btw) so that we only schedule the work to fire the uevent message, but
    do not wait for keventd to process the work.

    This removes one of the bottlenecks during boot; each one of them is
    only a small effect, but the sum of them does add up.

    [Note, distros that need this are broken, they should be setting
    CONFIG_UEVENT_HELPER_PATH to "", that way this code path will never be
    excuted at all -- gregkh]

    Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

:040000 040000 b1bfc977d11bb63ee29e42ad552eb89df4508815 4b301b5d0277359da91ee5e0162d44f76bbc7585 M      lib

Re: current->mm == NULL in security_vm_enough_memory().

[Greg KH]

On Mon, Apr 13, 2009 at 09:27:29PM +0900, Tetsuo Handa wrote:
> Hello.
> 
> I'm experiencing
> 
>   WARNING: at security/security.c:217 security_vm_enough_memory+0xa0/0xb0()
> 
> messages.
> "git bisect" reported that commit f520360d93cdc37de5d972dac4bf3bdef6a7f6a7
> is the cause of this warning. May I ignore this warning?

I don't know, can you provide the full warning?

And what kernel version is this happening on?

thanks,

greg k-h

Re: current->mm == NULL in security_vm_enough_memory().

[Hugh Dickins]

On Mon, 13 Apr 2009, Tetsuo Handa wrote:
> 
> I'm experiencing
> 
>   WARNING: at security/security.c:217 security_vm_enough_memory+0xa0/0xb0()
> 
> messages.
> "git bisect" reported that commit f520360d93cdc37de5d972dac4bf3bdef6a7f6a7
> is the cause of this warning. May I ignore this warning?

I do believe you may ignore them.

Thanks for doing the bisection: perhaps that commit just changed timings.

> Tetsuo Handa wrote:
> > James Morris wrote:
> > > khelper is a kernel thread, so it should not have an ->mm, but I wonder
> > > why this hasn't shown up before.  Odd...

I don't see anything wrong with an mm-less kernel helper trying to
exec something, and thereby arriving at security_vm_enough_memory(),
so triggering those warnings. 

Easy enough for you to comment them out of security/security.c for now,
and see whether that has any effect on your "RCU detected CPU 1 stall".
I'd guess not (and probably not worth bothering): I suspect the mm-less-
ness is relevant to both issues, but the messages themselves not.

But the real fix would be to back out, not just the warnings,
but almost all of Alan's 731572d39fcd3498702eda4600db4c43d51e0b26
nfsd: fix vm overcommit crash, appended below.

Alan, you remark in that commit:
    We could simply check for NULL and skip the modifier but we've caught
    other real bugs in the past from mm being NULL here - cases where we did
    need a valid mm set up (eg the exec bug about a year ago).

Please could you remind us of that bug?  I just don't see what's so
bad about calling __vm_enough_memory with NULL mm, it's only use
there is to reduce the allowance for an already large process.

You'd be right to argue that actually exec should be arranging for
the bprm->mm to be passed down there, but I don't think that's worth
the effort of additional interfaces.

Hugh

> > 
> > I don't see this message for 2.6.29 and earlier.
> > As of 2.6.30-rc1, this problem is not solved yet.
> > I think something happened between 2.6.29 and 2.6.30-rc1.
> > 
> > http://I-love.SAKURA.ne.jp/tmp/dmesg-2.6.30-rc1.txt
> > http://I-love.SAKURA.ne.jp/tmp/config-2.6.30-rc1
>
> [bisection]
>  
> f520360d93cdc37de5d972dac4bf3bdef6a7f6a7 is first bad commit
> commit f520360d93cdc37de5d972dac4bf3bdef6a7f6a7
> Author: Arjan van de Ven <arjan@linux.intel.com>
> Date:   Thu Mar 19 09:09:05 2009 -0700
> 
>     kobject: don't block for each kobject_uevent
> 
>     Right now, the kobject_uevent code blocks for each uevent that's being
>     generated, due to using (for hystoric reasons) UHM_WAIT_EXEC as flag to
>     call_usermode_helper().  Specifically, the effect is that each uevent
>     that is being sent causes the code to wake up keventd, then block until
>     keventd has processed the work. Needless to say, this happens many times
>     during the system boot.
> 
>     This patches changes that to UHN_NO_WAIT (brilliant name for a constant
>     btw) so that we only schedule the work to fire the uevent message, but
>     do not wait for keventd to process the work.
> 
>     This removes one of the bottlenecks during boot; each one of them is
>     only a small effect, but the sum of them does add up.
> 
>     [Note, distros that need this are broken, they should be setting
>     CONFIG_UEVENT_HELPER_PATH to "", that way this code path will never be
>     excuted at all -- gregkh]
> 
>     Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 731572d39fcd3498702eda4600db4c43d51e0b26
Author: Alan Cox <alan@redhat.com>
Date:   Wed Oct 29 14:01:20 2008 -0700

    nfsd: fix vm overcommit crash
    
    Junjiro R.  Okajima reported a problem where knfsd crashes if you are
    using it to export shmemfs objects and run strict overcommit.  In this
    situation the current->mm based modifier to the overcommit goes through a
    NULL pointer.
    
    We could simply check for NULL and skip the modifier but we've caught
    other real bugs in the past from mm being NULL here - cases where we did
    need a valid mm set up (eg the exec bug about a year ago).
    
    To preserve the checks and get the logic we want shuffle the checking
    around and add a new helper to the vm_ security wrappers
    
    Also fix a current->mm reference in nommu that should use the passed mm
    
    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix build]
    Reported-by: Junjiro R. Okajima <hooanon05@yahoo.co.jp>
    Acked-by: James Morris <jmorris@namei.org>
    Signed-off-by: Alan Cox <alan@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/include/linux/security.h b/include/linux/security.h
index f5c4a51..c13f1ce 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1585,6 +1585,7 @@ int security_syslog(int type);
 int security_settime(struct timespec *ts, struct timezone *tz);
 int security_vm_enough_memory(long pages);
 int security_vm_enough_memory_mm(struct mm_struct *mm, long pages);
+int security_vm_enough_memory_kern(long pages);
 int security_bprm_alloc(struct linux_binprm *bprm);
 void security_bprm_free(struct linux_binprm *bprm);
 void security_bprm_apply_creds(struct linux_binprm *bprm, int unsafe);
@@ -1820,6 +1821,11 @@ static inline int security_vm_enough_memory(long pages)
 	return cap_vm_enough_memory(current->mm, pages);
 }
 
+static inline int security_vm_enough_memory_kern(long pages)
+{
+	return cap_vm_enough_memory(current->mm, pages);
+}
+
 static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long pages)
 {
 	return cap_vm_enough_memory(mm, pages);
diff --git a/mm/mmap.c b/mm/mmap.c
index 74f4d15..de14ac2 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -175,7 +175,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 
 	/* Don't let a single process grow too big:
 	   leave 3% of the size of this process for other processes */
-	allowed -= mm->total_vm / 32;
+	if (mm)
+		allowed -= mm->total_vm / 32;
 
 	/*
 	 * cast `allowed' as a signed long because vm_committed_space
diff --git a/mm/nommu.c b/mm/nommu.c
index 2696b24..7695dc8 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1454,7 +1454,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 
 	/* Don't let a single process grow too big:
 	   leave 3% of the size of this process for other processes */
-	allowed -= current->mm->total_vm / 32;
+	if (mm)
+		allowed -= mm->total_vm / 32;
 
 	/*
 	 * cast `allowed' as a signed long because vm_committed_space
diff --git a/mm/shmem.c b/mm/shmem.c
index d38d7e6..0ed0752 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -161,8 +161,8 @@ static inline struct shmem_sb_info *SHMEM_SB(struct super_block *sb)
  */
 static inline int shmem_acct_size(unsigned long flags, loff_t size)
 {
-	return (flags & VM_ACCOUNT)?
-		security_vm_enough_memory(VM_ACCT(size)): 0;
+	return (flags & VM_ACCOUNT) ?
+		security_vm_enough_memory_kern(VM_ACCT(size)) : 0;
 }
 
 static inline void shmem_unacct_size(unsigned long flags, loff_t size)
@@ -179,8 +179,8 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size)
  */
 static inline int shmem_acct_block(unsigned long flags)
 {
-	return (flags & VM_ACCOUNT)?
-		0: security_vm_enough_memory(VM_ACCT(PAGE_CACHE_SIZE));
+	return (flags & VM_ACCOUNT) ?
+		0 : security_vm_enough_memory_kern(VM_ACCT(PAGE_CACHE_SIZE));
 }
 
 static inline void shmem_unacct_blocks(unsigned long flags, long pages)
diff --git a/security/security.c b/security/security.c
index 255b085..c0acfa7 100644
--- a/security/security.c
+++ b/security/security.c
@@ -198,14 +198,23 @@ int security_settime(struct timespec *ts, struct timezone *tz)
 
 int security_vm_enough_memory(long pages)
 {
+	WARN_ON(current->mm == NULL);
 	return security_ops->vm_enough_memory(current->mm, pages);
 }
 
 int security_vm_enough_memory_mm(struct mm_struct *mm, long pages)
 {
+	WARN_ON(mm == NULL);
 	return security_ops->vm_enough_memory(mm, pages);
 }
 
+int security_vm_enough_memory_kern(long pages)
+{
+	/* If current->mm is a kernel thread then we will pass NULL,
+	   for this specific case that is fine */
+	return security_ops->vm_enough_memory(current->mm, pages);
+}
+
 int security_bprm_alloc(struct linux_binprm *bprm)
 {
 	return security_ops->bprm_alloc_security(bprm);

Re: current->mm == NULL in security_vm_enough_memory().

[Alan Cox]

If you want to permit a NULL vm you can use vm_enough_memory_kern() to
indicate that the caller may be a kernel thread and you are ok with that.

The case you are now hitting was considered in the original design and
provided for. The default handler traps NULL to be sure we catch cases
where nobody has considered if NULL mm is meaningful and valid (such as
old code pre the checks)

Given this case appears to be ok (if a bit novel by the kernels
standards) just flipping to use the _kern() version will do the job.

Alan

Re: current->mm == NULL in security_vm_enough_memory().

[Alan Cox]

> Thanks for doing the bisection: perhaps that commit just changed timings.

As a PS: I'd still like to understand why this is timing sensitive and
what has happened. We have other cases where khelper and the like
mysteriously acquiring an mm might be had so it would be good to
understand if this is a race between init/khelper setup as to whether it
gets an mm and cloned.

Re: current->mm == NULL in security_vm_enough_memory().

[Tetsuo Handa]

Greg KH wrote:
> > I'm experiencing
> > 
> >   WARNING: at security/security.c:217 security_vm_enough_memory+0xa0/0xb0()
> > 
> > messages.
> > "git bisect" reported that commit f520360d93cdc37de5d972dac4bf3bdef6a7f6a7
> > is the cause of this warning. May I ignore this warning?
> 
> I don't know, can you provide the full warning?
Yes. It is http://I-love.SAKURA.ne.jp/tmp/dmesg-2.6.30-rc1.txt

> And what kernel version is this happening on?
It is 2.6.30-rc1.
Config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.30-rc1