Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756093Ab2FZIrB (ORCPT ); Tue, 26 Jun 2012 04:47:01 -0400 Received: from mx2.parallels.com ([64.131.90.16]:56176 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755929Ab2FZIq7 (ORCPT ); Tue, 26 Jun 2012 04:46:59 -0400 Message-ID: <4FE9765D.2050301@parallels.com> Date: Tue, 26 Jun 2012 12:44:13 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: David Rientjes CC: , , Andrew Morton , , Frederic Weisbecker , Pekka Enberg , Michal Hocko , Johannes Weiner , Christoph Lameter , , , Tejun Heo , Pekka Enberg , Suleiman Souhlal , Frederic Weisbecker Subject: Re: [PATCH 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs References: <1340633728-12785-1-git-send-email-glommer@parallels.com> <1340633728-12785-12-git-send-email-glommer@parallels.com> <4FE96358.6080601@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2063 Lines: 48 On 06/26/2012 12:45 PM, David Rientjes wrote: > On Tue, 26 Jun 2012, Glauber Costa wrote: > >>>> diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h >>>> index ccc1899..914ec07 100644 >>>> --- a/include/linux/thread_info.h >>>> +++ b/include/linux/thread_info.h >>>> @@ -61,6 +61,12 @@ extern long do_no_restart_syscall(struct restart_block >>>> *parm); >>>> # define THREADINFO_GFP (GFP_KERNEL | __GFP_NOTRACK) >>>> #endif >>>> >>>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM >>>> +# define THREADINFO_GFP_ACCOUNTED (THREADINFO_GFP | __GFP_KMEMCG) >>>> +#else >>>> +# define THREADINFO_GFP_ACCOUNTED (THREADINFO_GFP) >>>> +#endif >>>> + >>> >>> This type of requirement is going to become nasty very quickly if nobody >>> can use __GFP_KMEMCG without testing for CONFIG_CGROUP_MEM_RES_CTLR_KMEM. >>> Perhaps define __GFP_KMEMCG to be 0x0 if it's not enabled, similar to how >>> kmemcheck does? >>> >> That is what I've done in my first version of this patch. At that time, >> Christoph wanted it to be this way so we would make sure it would never be >> used with #CONFIG_CGROUP_MEM_RES_CTLR_KMEM defined. A value of zero will >> generate no errors. Undefined value will. >> >> Now, if you ask me, I personally prefer following what kmemcheck does here... >> > > Right, because I'm sure that __GFP_KMEMCG will be used in additional > places outside of this patchset and it will be a shame if we have to > always add #ifdef's. I see no reason why we would care if __GFP_KMEMCG > was used when CONFIG_CGROUP_MEM_RES_CTLR_KMEM=n with the semantics that it > as in this patchset. It's much cleaner by making it 0x0 when disabled. > What I can do, instead, is to WARN_ON conditionally to the config option in the page allocator, and make sure no one is actually passing the flag in that case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/