From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx197.postini.com [74.125.245.197]) by kanga.kvack.org (Postfix) with SMTP id 889736B004F for ; Thu, 12 Jan 2012 16:19:57 -0500 (EST) Received: by iafj26 with SMTP id j26so4339323iaf.14 for ; Thu, 12 Jan 2012 13:19:56 -0800 (PST) Date: Thu, 12 Jan 2012 13:19:54 -0800 (PST) From: David Rientjes Subject: Re: [PATCH] mm: Don't warn if memdup_user fails In-Reply-To: Message-ID: References: <1326300636-29233-1-git-send-email-levinsasha928@gmail.com> <20120111141219.271d3a97.akpm@linux-foundation.org> <1326355594.1999.7.camel@lappy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: Sasha Levin , Andrew Morton , lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Tyler Hicks , Dustin Kirkland , ecryptfs@vger.kernel.org On Thu, 12 Jan 2012, Pekka Enberg wrote: > I think you missed Andrew's point. We absolutely want to issue a > kernel warning here because ecryptfs is misusing the memdup_user() > API. We must not let userspace processes allocate large amounts of > memory arbitrarily. > I think it's good to fix ecryptfs like Tyler is doing and, at the same time, ensure that the len passed to memdup_user() makes sense prior to kmallocing memory with GFP_KERNEL. Perhaps something like if (WARN_ON(len > PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) return ERR_PTR(-ENOMEM); in which case __GFP_NOWARN is irrelevant. I think memdup_user() should definitely be taking gfp flags, though, so the caller can specify things like __GFP_NORETRY on its own to avoid infinitely looping in the page allocator trying reclaim and possibly calling the oom killer. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org