[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070813122224.6b9d90fd@the-village.bc.nu>
Date: Mon, 13 Aug 2007 12:22:24 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Cyrill Gorcunov <gorcunov@...il.com>
Cc: Balbir Singh <balbir@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Paul Moore <paul.moore@...com>,
Stephen Smalley <sds@...ch.ncsc.mil>,
Chris Vance <cvance@....com>, Wayne Salamon <wsalamon@....com>,
James Morris <jmorris@...hat.com>, dgoeddel@...stedcs.com,
Fengguang Wu <fengguang.wu@...il.com>
Subject: Re: [BUGFIX] NULL pointer dereference in __vm_enough_memory()
> Well, as I see, it seems the Alan's patch is correct. We pass
> newly created mm to security_vm_enough_memory_mm() and get no errors
> here even for overcommit = 2. But my question was that mm->total_vm
> = 0 for this case and that is probably valid too I think. What about
> the thing you pointed about? Well I think security_vm_enough_memory
> should never be called from kernel thread (we have secrurity_vm_enough_memory_mm
> for this). But I will check it more closely. Dont get me wrong - I'm not
> VMM expert and may do errors ;)
A vma has to inserted into an mm struct so we are fine in terms of kernel
threads. init_bprm showed up a new case where we add vma's to an mm that
isn't current->mm. The rest of the vm subsystem supports this and there
are cases for the future (eg the usermode linux mm switching patch) where
it might matter that we do it right.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists