Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs
On Tue 21-08-12 13:40:45, Glauber Costa wrote: > On 08/21/2012 01:35 PM, Michal Hocko wrote: [...] > > I am asking because this should trigger memcg-oom > > but that one will usually pick up something else than the fork bomb > > which would have a small memory footprint. But that needs to be handled > > on the oom level obviously. > > > Sure, but keep in mind that the main protection is against tasks *not* > in this memcg. Yes and that's is good step forward. I just wanted to mention that we still have the problem inside the subhierarchy. The changelog was not specific enough. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs
On 08/21/2012 01:35 PM, Michal Hocko wrote: > On Thu 09-08-12 17:01:19, 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. > > quick git grep "define *THREAD_SIZE\>" arch says that there is no such > architecture. > >> 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 :(){ :|:& };: > > I guess there were no other tasks in the same group (except for the > parent shell), right? Yes. > I am asking because this should trigger memcg-oom > but that one will usually pick up something else than the fork bomb > which would have a small memory footprint. But that needs to be handled > on the oom level obviously. > Sure, but keep in mind that the main protection is against tasks *not* in this memcg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs
On Thu 09-08-12 17:01:19, 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. quick git grep "define *THREAD_SIZE\>" arch says that there is no such architecture. > 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 :(){ :|:& };: I guess there were no other tasks in the same group (except for the parent shell), right? I am asking because this should trigger memcg-oom but that one will usually pick up something else than the fork bomb which would have a small memory footprint. But that needs to be handled on the oom level obviously. > Signed-off-by: Glauber Costa > Acked-by: Frederic Weisbecker > CC: Christoph Lameter > CC: Pekka Enberg > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner > CC: Suleiman Souhlal Reviewed-by: Michal Hocko > --- > include/linux/thread_info.h | 2 ++ > kernel/fork.c | 4 ++-- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h > index ccc1899..e7e0473 100644 > --- a/include/linux/thread_info.h > +++ b/include/linux/thread_info.h > @@ -61,6 +61,8 @@ extern long do_no_restart_syscall(struct restart_block > *parm); > # define THREADINFO_GFP (GFP_KERNEL | __GFP_NOTRACK) > #endif > > +#define THREADINFO_GFP_ACCOUNTED (THREADINFO_GFP | __GFP_KMEMCG) > + > /* > * flag set/clear/test wrappers > * - pass TIF_ constants to these functions > diff --git a/kernel/fork.c b/kernel/fork.c > index dc3ff16..b0b90c3 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -142,7 +142,7 @@ void __weak arch_release_thread_info(struct thread_info > *ti) { } > static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, > int node) > { > - struct page *page = alloc_pages_node(node, THREADINFO_GFP, > + struct page *page = alloc_pages_node(node, THREADINFO_GFP_ACCOUNTED, >THREAD_SIZE_ORDER); > > return page ? page_address(page) : NULL; > @@ -151,7 +151,7 @@ static struct thread_info *alloc_thread_info_node(struct > task_struct *tsk, > static inline void free_thread_info(struct thread_info *ti) > { > arch_release_thread_info(ti); > - free_pages((unsigned long)ti, THREAD_SIZE_ORDER); > + free_accounted_pages((unsigned long)ti, THREAD_SIZE_ORDER); > } > # else > static struct kmem_cache *thread_info_cache; > -- > 1.7.11.2 > > -- > To unsubscribe from this list: send the line "unsubscribe cgroups" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE = PAGE_SIZE against fork bombs
On Thu 09-08-12 17:01:19, 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. quick git grep define *THREAD_SIZE\ arch says that there is no such architecture. 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 :(){ :|: };: I guess there were no other tasks in the same group (except for the parent shell), right? I am asking because this should trigger memcg-oom but that one will usually pick up something else than the fork bomb which would have a small memory footprint. But that needs to be handled on the oom level obviously. Signed-off-by: Glauber Costa glom...@parallels.com Acked-by: Frederic Weisbecker fweis...@redhat.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com Reviewed-by: Michal Hocko mho...@suse.cz --- include/linux/thread_info.h | 2 ++ kernel/fork.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index ccc1899..e7e0473 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -61,6 +61,8 @@ extern long do_no_restart_syscall(struct restart_block *parm); # define THREADINFO_GFP (GFP_KERNEL | __GFP_NOTRACK) #endif +#define THREADINFO_GFP_ACCOUNTED (THREADINFO_GFP | __GFP_KMEMCG) + /* * flag set/clear/test wrappers * - pass TIF_ constants to these functions diff --git a/kernel/fork.c b/kernel/fork.c index dc3ff16..b0b90c3 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -142,7 +142,7 @@ void __weak arch_release_thread_info(struct thread_info *ti) { } static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, int node) { - struct page *page = alloc_pages_node(node, THREADINFO_GFP, + struct page *page = alloc_pages_node(node, THREADINFO_GFP_ACCOUNTED, THREAD_SIZE_ORDER); return page ? page_address(page) : NULL; @@ -151,7 +151,7 @@ static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, static inline void free_thread_info(struct thread_info *ti) { arch_release_thread_info(ti); - free_pages((unsigned long)ti, THREAD_SIZE_ORDER); + free_accounted_pages((unsigned long)ti, THREAD_SIZE_ORDER); } # else static struct kmem_cache *thread_info_cache; -- 1.7.11.2 -- To unsubscribe from this list: send the line unsubscribe cgroups in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE = PAGE_SIZE against fork bombs
On 08/21/2012 01:35 PM, Michal Hocko wrote: On Thu 09-08-12 17:01:19, 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. quick git grep define *THREAD_SIZE\ arch says that there is no such architecture. 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 :(){ :|: };: I guess there were no other tasks in the same group (except for the parent shell), right? Yes. I am asking because this should trigger memcg-oom but that one will usually pick up something else than the fork bomb which would have a small memory footprint. But that needs to be handled on the oom level obviously. Sure, but keep in mind that the main protection is against tasks *not* in this memcg. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE = PAGE_SIZE against fork bombs
On Tue 21-08-12 13:40:45, Glauber Costa wrote: On 08/21/2012 01:35 PM, Michal Hocko wrote: [...] I am asking because this should trigger memcg-oom but that one will usually pick up something else than the fork bomb which would have a small memory footprint. But that needs to be handled on the oom level obviously. Sure, but keep in mind that the main protection is against tasks *not* in this memcg. Yes and that's is good step forward. I just wanted to mention that we still have the problem inside the subhierarchy. The changelog was not specific enough. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs
(2012/08/09 22:01), 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 > Acked-by: Frederic Weisbecker > CC: Christoph Lameter > CC: Pekka Enberg > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner > CC: Suleiman Souhlal Acked-by: KAMEZAWA Hiroyuki > --- > include/linux/thread_info.h | 2 ++ > kernel/fork.c | 4 ++-- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h > index ccc1899..e7e0473 100644 > --- a/include/linux/thread_info.h > +++ b/include/linux/thread_info.h > @@ -61,6 +61,8 @@ extern long do_no_restart_syscall(struct restart_block > *parm); > # define THREADINFO_GFP (GFP_KERNEL | __GFP_NOTRACK) > #endif > > +#define THREADINFO_GFP_ACCOUNTED (THREADINFO_GFP | __GFP_KMEMCG) > + > /* >* flag set/clear/test wrappers >* - pass TIF_ constants to these functions > diff --git a/kernel/fork.c b/kernel/fork.c > index dc3ff16..b0b90c3 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -142,7 +142,7 @@ void __weak arch_release_thread_info(struct thread_info > *ti) { } > static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, > int node) > { > - struct page *page = alloc_pages_node(node, THREADINFO_GFP, > + struct page *page = alloc_pages_node(node, THREADINFO_GFP_ACCOUNTED, >THREAD_SIZE_ORDER); > > return page ? page_address(page) : NULL; > @@ -151,7 +151,7 @@ static struct thread_info *alloc_thread_info_node(struct > task_struct *tsk, > static inline void free_thread_info(struct thread_info *ti) > { > arch_release_thread_info(ti); > - free_pages((unsigned long)ti, THREAD_SIZE_ORDER); > + free_accounted_pages((unsigned long)ti, THREAD_SIZE_ORDER); > } > # else > static struct kmem_cache *thread_info_cache; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE = PAGE_SIZE against fork bombs
(2012/08/09 22:01), 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 glom...@parallels.com Acked-by: Frederic Weisbecker fweis...@redhat.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com --- include/linux/thread_info.h | 2 ++ kernel/fork.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index ccc1899..e7e0473 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -61,6 +61,8 @@ extern long do_no_restart_syscall(struct restart_block *parm); # define THREADINFO_GFP (GFP_KERNEL | __GFP_NOTRACK) #endif +#define THREADINFO_GFP_ACCOUNTED (THREADINFO_GFP | __GFP_KMEMCG) + /* * flag set/clear/test wrappers * - pass TIF_ constants to these functions diff --git a/kernel/fork.c b/kernel/fork.c index dc3ff16..b0b90c3 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -142,7 +142,7 @@ void __weak arch_release_thread_info(struct thread_info *ti) { } static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, int node) { - struct page *page = alloc_pages_node(node, THREADINFO_GFP, + struct page *page = alloc_pages_node(node, THREADINFO_GFP_ACCOUNTED, THREAD_SIZE_ORDER); return page ? page_address(page) : NULL; @@ -151,7 +151,7 @@ static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, static inline void free_thread_info(struct thread_info *ti) { arch_release_thread_info(ti); - free_pages((unsigned long)ti, THREAD_SIZE_ORDER); + free_accounted_pages((unsigned long)ti, THREAD_SIZE_ORDER); } # else static struct kmem_cache *thread_info_cache; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/