From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754041AbdBTRJx (ORCPT ); Mon, 20 Feb 2017 12:09:53 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:35756 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752118AbdBTRJv (ORCPT ); Mon, 20 Feb 2017 12:09:51 -0500 Subject: Re: [PATCH] mm/cgroup: avoid panic when init with low memory To: Michal Hocko References: <1487154969-6704-1-git-send-email-ldufour@linux.vnet.ibm.com> <20170220130123.GI2431@dhcp22.suse.cz> Cc: Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Laurent Dufour Date: Mon, 20 Feb 2017 18:09:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170220130123.GI2431@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17022017-0016-0000-0000-000004427D64 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17022017-0017-0000-0000-000026832C33 Message-Id: <934d40ec-060b-4794-2fdc-35a7ea1dc9e2@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-20_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702200161 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/02/2017 14:01, Michal Hocko wrote: > On Wed 15-02-17 11:36:09, Laurent Dufour wrote: >> The system may panic when initialisation is done when almost all the >> memory is assigned to the huge pages using the kernel command line >> parameter hugepage=xxxx. Panic may occur like this: > > I am pretty sure the system might blow up in many other ways when you > misconfigure it and pull basically all the memory out. Anyway... > > [...] > >> This is a chicken and egg issue where the kernel try to get free >> memory when allocating per node data in mem_cgroup_init(), but in that >> path mem_cgroup_soft_limit_reclaim() is called which assumes that >> these data are allocated. >> >> As mem_cgroup_soft_limit_reclaim() is best effort, it should return >> when these data are not yet allocated. > > ... this makes some sense. Especially when there is no soft limit > configured. So this is a good step. I would just like to ask you to go > one step further. Can we make the whole soft reclaim thing uninitialized > until the soft limit is actually set? Soft limit is not used in cgroup > v2 at all and I would strongly discourage it in v1 as well. We will save > few bytes as a bonus. Hi Michal, and thanks for the review. I'm not familiar with that part of the kernel, so to be sure we are on the same line, are you suggesting to set soft_limit_tree at the first time mem_cgroup_write() is called to set a soft_limit field ? Obviously, all callers to soft_limit_tree_node() and soft_limit_tree_from_page() will have to check for the return pointer to be NULL. Cheers, Laurent. >> Signed-off-by: Laurent Dufour >> --- >> mm/memcontrol.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 1fd6affcdde7..213f96b2f601 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2556,7 +2556,7 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order, >> * is empty. Do it lockless to prevent lock bouncing. Races >> * are acceptable as soft limit is best effort anyway. >> */ >> - if (RB_EMPTY_ROOT(&mctz->rb_root)) >> + if (!mctz || RB_EMPTY_ROOT(&mctz->rb_root)) >> return 0; >> >> /* >> -- >> 2.7.4 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Dufour Subject: Re: [PATCH] mm/cgroup: avoid panic when init with low memory Date: Mon, 20 Feb 2017 18:09:43 +0100 Message-ID: <934d40ec-060b-4794-2fdc-35a7ea1dc9e2@linux.vnet.ibm.com> References: <1487154969-6704-1-git-send-email-ldufour@linux.vnet.ibm.com> <20170220130123.GI2431@dhcp22.suse.cz> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170220130123.GI2431@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org On 20/02/2017 14:01, Michal Hocko wrote: > On Wed 15-02-17 11:36:09, Laurent Dufour wrote: >> The system may panic when initialisation is done when almost all the >> memory is assigned to the huge pages using the kernel command line >> parameter hugepage=xxxx. Panic may occur like this: > > I am pretty sure the system might blow up in many other ways when you > misconfigure it and pull basically all the memory out. Anyway... > > [...] > >> This is a chicken and egg issue where the kernel try to get free >> memory when allocating per node data in mem_cgroup_init(), but in that >> path mem_cgroup_soft_limit_reclaim() is called which assumes that >> these data are allocated. >> >> As mem_cgroup_soft_limit_reclaim() is best effort, it should return >> when these data are not yet allocated. > > ... this makes some sense. Especially when there is no soft limit > configured. So this is a good step. I would just like to ask you to go > one step further. Can we make the whole soft reclaim thing uninitialized > until the soft limit is actually set? Soft limit is not used in cgroup > v2 at all and I would strongly discourage it in v1 as well. We will save > few bytes as a bonus. Hi Michal, and thanks for the review. I'm not familiar with that part of the kernel, so to be sure we are on the same line, are you suggesting to set soft_limit_tree at the first time mem_cgroup_write() is called to set a soft_limit field ? Obviously, all callers to soft_limit_tree_node() and soft_limit_tree_from_page() will have to check for the return pointer to be NULL. Cheers, Laurent. >> Signed-off-by: Laurent Dufour >> --- >> mm/memcontrol.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 1fd6affcdde7..213f96b2f601 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2556,7 +2556,7 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order, >> * is empty. Do it lockless to prevent lock bouncing. Races >> * are acceptable as soft limit is best effort anyway. >> */ >> - if (RB_EMPTY_ROOT(&mctz->rb_root)) >> + if (!mctz || RB_EMPTY_ROOT(&mctz->rb_root)) >> return 0; >> >> /* >> -- >> 2.7.4 > -- 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