From: Michal Hocko <mhocko@kernel.org> To: Laurent Dufour <ldufour@linux.vnet.ibm.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Vladimir Davydov <vdavydov.dev@gmail.com>, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/cgroup: avoid panic when init with low memory Date: Mon, 20 Feb 2017 18:42:59 +0100 [thread overview] Message-ID: <20170220174258.GA31541@dhcp22.suse.cz> (raw) In-Reply-To: <934d40ec-060b-4794-2fdc-35a7ea1dc9e2@linux.vnet.ibm.com> On Mon 20-02-17 18:09:43, Laurent Dufour wrote: > 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 ? yes > 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. All callers that need to access the tree unconditionally, yes. Which is the case anyway, right? I haven't checked the check you have added is sufficient, but we shouldn't have that many of them because some code paths are called only when the soft limit is enabled. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Laurent Dufour <ldufour@linux.vnet.ibm.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Vladimir Davydov <vdavydov.dev@gmail.com>, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/cgroup: avoid panic when init with low memory Date: Mon, 20 Feb 2017 18:42:59 +0100 [thread overview] Message-ID: <20170220174258.GA31541@dhcp22.suse.cz> (raw) In-Reply-To: <934d40ec-060b-4794-2fdc-35a7ea1dc9e2@linux.vnet.ibm.com> On Mon 20-02-17 18:09:43, Laurent Dufour wrote: > 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 ? yes > 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. All callers that need to access the tree unconditionally, yes. Which is the case anyway, right? I haven't checked the check you have added is sufficient, but we shouldn't have that many of them because some code paths are called only when the soft limit is enabled. -- Michal Hocko SUSE Labs -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-02-20 17:43 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-15 10:36 [PATCH] mm/cgroup: avoid panic when init with low memory Laurent Dufour 2017-02-15 10:36 ` Laurent Dufour 2017-02-15 10:36 ` Laurent Dufour 2017-02-20 13:01 ` Michal Hocko 2017-02-20 13:01 ` Michal Hocko 2017-02-20 13:01 ` Michal Hocko 2017-02-20 17:09 ` Laurent Dufour 2017-02-20 17:09 ` Laurent Dufour 2017-02-20 17:42 ` Michal Hocko [this message] 2017-02-20 17:42 ` Michal Hocko 2017-02-22 14:02 ` Laurent Dufour 2017-02-22 14:02 ` Laurent Dufour
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170220174258.GA31541@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=cgroups@vger.kernel.org \ --cc=hannes@cmpxchg.org \ --cc=ldufour@linux.vnet.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=vdavydov.dev@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.