From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757180Ab2FYU6A (ORCPT ); Mon, 25 Jun 2012 16:58:00 -0400 Received: from mail-yx0-f174.google.com ([209.85.213.174]:36211 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756270Ab2FYU57 (ORCPT ); Mon, 25 Jun 2012 16:57:59 -0400 Date: Mon, 25 Jun 2012 22:57:51 +0200 From: Frederic Weisbecker To: Tejun Heo Cc: Frederic Weisbecker , Glauber Costa , cgroups@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, David Rientjes , Pekka Enberg , Michal Hocko , Johannes Weiner , Christoph Lameter , devel@openvz.org, kamezawa.hiroyu@jp.fujitsu.com, Pekka Enberg , Suleiman Souhlal Subject: Re: [PATCH 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs Message-ID: <20120625205747.GA8101@somewhere> References: <1340633728-12785-1-git-send-email-glommer@parallels.com> <1340633728-12785-12-git-send-email-glommer@parallels.com> <4FE89807.50708@redhat.com> <20120625183818.GH3869@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120625183818.GH3869@google.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 25, 2012 at 11:38:18AM -0700, Tejun Heo wrote: > On Mon, Jun 25, 2012 at 06:55:35PM +0200, Frederic Weisbecker wrote: > > On 06/25/2012 04:15 PM, Glauber Costa wrote: > > > > > Because those architectures will draw their stacks directly from > > > the page allocator, rather than the slab cache, we can directly > > > pass __GFP_KMEMCG flag, and issue the corresponding free_pages. > > > > > > This code path is taken when the architecture doesn't define > > > CONFIG_ARCH_THREAD_INFO_ALLOCATOR (only ia64 seems to), and has > > > THREAD_SIZE >= PAGE_SIZE. Luckily, most - if not all - of the > > > remaining architectures fall in this category. > > > > > > This will guarantee that every stack page is accounted to the memcg > > > the process currently lives on, and will have the allocations to fail > > > if they go over limit. > > > > > > For the time being, I am defining a new variant of THREADINFO_GFP, not > > > to mess with the other path. Once the slab is also tracked by memcg, > > > we can get rid of that flag. > > > > > > Tested to successfully protect against :(){ :|:& };: > > > > > > Signed-off-by: Glauber Costa > > > CC: Christoph Lameter > > > CC: Pekka Enberg > > > CC: Michal Hocko > > > CC: Kamezawa Hiroyuki > > > CC: Johannes Weiner > > > CC: Suleiman Souhlal > > > > > > Acked-by: Frederic Weisbecker > > Frederic, does this (with proper slab accounting added later) achieve > what you wanted with the task counter? I think so yeah. Relying on general kernel memory accounting should do the trick for us. And if we need more finegrained limitation on kernel stack accounting we can still add it incrementally. But I believe global limitation can be enough. Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx131.postini.com [74.125.245.131]) by kanga.kvack.org (Postfix) with SMTP id 8D7896B0391 for ; Mon, 25 Jun 2012 16:57:59 -0400 (EDT) Received: by ggm4 with SMTP id 4so4088233ggm.14 for ; Mon, 25 Jun 2012 13:57:58 -0700 (PDT) Date: Mon, 25 Jun 2012 22:57:51 +0200 From: Frederic Weisbecker Subject: Re: [PATCH 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs Message-ID: <20120625205747.GA8101@somewhere> References: <1340633728-12785-1-git-send-email-glommer@parallels.com> <1340633728-12785-12-git-send-email-glommer@parallels.com> <4FE89807.50708@redhat.com> <20120625183818.GH3869@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120625183818.GH3869@google.com> Sender: owner-linux-mm@kvack.org List-ID: To: Tejun Heo Cc: Frederic Weisbecker , Glauber Costa , cgroups@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, David Rientjes , Pekka Enberg , Michal Hocko , Johannes Weiner , Christoph Lameter , devel@openvz.org, kamezawa.hiroyu@jp.fujitsu.com, Pekka Enberg , Suleiman Souhlal On Mon, Jun 25, 2012 at 11:38:18AM -0700, Tejun Heo wrote: > On Mon, Jun 25, 2012 at 06:55:35PM +0200, Frederic Weisbecker wrote: > > On 06/25/2012 04:15 PM, Glauber Costa wrote: > > > > > Because those architectures will draw their stacks directly from > > > the page allocator, rather than the slab cache, we can directly > > > pass __GFP_KMEMCG flag, and issue the corresponding free_pages. > > > > > > This code path is taken when the architecture doesn't define > > > CONFIG_ARCH_THREAD_INFO_ALLOCATOR (only ia64 seems to), and has > > > THREAD_SIZE >= PAGE_SIZE. Luckily, most - if not all - of the > > > remaining architectures fall in this category. > > > > > > This will guarantee that every stack page is accounted to the memcg > > > the process currently lives on, and will have the allocations to fail > > > if they go over limit. > > > > > > For the time being, I am defining a new variant of THREADINFO_GFP, not > > > to mess with the other path. Once the slab is also tracked by memcg, > > > we can get rid of that flag. > > > > > > Tested to successfully protect against :(){ :|:& };: > > > > > > Signed-off-by: Glauber Costa > > > CC: Christoph Lameter > > > CC: Pekka Enberg > > > CC: Michal Hocko > > > CC: Kamezawa Hiroyuki > > > CC: Johannes Weiner > > > CC: Suleiman Souhlal > > > > > > Acked-by: Frederic Weisbecker > > Frederic, does this (with proper slab accounting added later) achieve > what you wanted with the task counter? I think so yeah. Relying on general kernel memory accounting should do the trick for us. And if we need more finegrained limitation on kernel stack accounting we can still add it incrementally. But I believe global limitation can be enough. Thanks. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [PATCH 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs Date: Mon, 25 Jun 2012 22:57:51 +0200 Message-ID: <20120625205747.GA8101@somewhere> References: <1340633728-12785-1-git-send-email-glommer@parallels.com> <1340633728-12785-12-git-send-email-glommer@parallels.com> <4FE89807.50708@redhat.com> <20120625183818.GH3869@google.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=eyshD+uMyAcKZQdxf62ztp+V5xMmI28ervG9DIYstvc=; b=ASA/7MFGIKs8Tmjcpet0FAH+EbqS41ueoWX2oZbMwa4WQr/AGzPaHaV/jZjUk7PGFX C2azr9XxIzi5TsXNAH6deaJnACcrxw0cio1PRQ0FbzeA1vnH9+7IHKeogAVAspHgnGxD PHvm6BrVNFg/5IpfH1liWHzYYxfUzfuo6KUh+quy308YnHtz10EpnJdQHSACxZejwL5s kon7iU0hReQvNofRmADxRFEEXt3wq6H7SpgoIx6aQp8jrJzsCeba3eh1ACj3zDGQoeqy zT9O+j/JiYD29r85uaTPKMi8Cl1bhWnnvI0MADpEl0maQ8Jh2spBWiGx4OzbJus6PpFW yNHw== Content-Disposition: inline In-Reply-To: <20120625183818.GH3869-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tejun Heo Cc: Frederic Weisbecker , Glauber Costa , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Andrew Morton , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Rientjes , Pekka Enberg , Michal Hocko , Johannes Weiner , Christoph Lameter , devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, Pekka Enberg , Suleiman Souhlal On Mon, Jun 25, 2012 at 11:38:18AM -0700, Tejun Heo wrote: > On Mon, Jun 25, 2012 at 06:55:35PM +0200, Frederic Weisbecker wrote: > > On 06/25/2012 04:15 PM, Glauber Costa wrote: > > > > > Because those architectures will draw their stacks directly from > > > the page allocator, rather than the slab cache, we can directly > > > pass __GFP_KMEMCG flag, and issue the corresponding free_pages. > > > > > > This code path is taken when the architecture doesn't define > > > CONFIG_ARCH_THREAD_INFO_ALLOCATOR (only ia64 seems to), and has > > > THREAD_SIZE >= PAGE_SIZE. Luckily, most - if not all - of the > > > remaining architectures fall in this category. > > > > > > This will guarantee that every stack page is accounted to the memcg > > > the process currently lives on, and will have the allocations to fail > > > if they go over limit. > > > > > > For the time being, I am defining a new variant of THREADINFO_GFP, not > > > to mess with the other path. Once the slab is also tracked by memcg, > > > we can get rid of that flag. > > > > > > Tested to successfully protect against :(){ :|:& };: > > > > > > Signed-off-by: Glauber Costa > > > CC: Christoph Lameter > > > CC: Pekka Enberg > > > CC: Michal Hocko > > > CC: Kamezawa Hiroyuki > > > CC: Johannes Weiner > > > CC: Suleiman Souhlal > > > > > > Acked-by: Frederic Weisbecker > > Frederic, does this (with proper slab accounting added later) achieve > what you wanted with the task counter? I think so yeah. Relying on general kernel memory accounting should do the trick for us. And if we need more finegrained limitation on kernel stack accounting we can still add it incrementally. But I believe global limitation can be enough. Thanks.