linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Thomas Lindroth <thomas.lindroth@gmail.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	linux-mm@kvack.org
Subject: Re: [BUG] kmemcg limit defeats __GFP_NOFAIL allocation
Date: Fri, 6 Sep 2019 13:29:01 +0200	[thread overview]
Message-ID: <20190906112901.GF14491@dhcp22.suse.cz> (raw)
In-Reply-To: <940ea5a4-b580-34f8-2e5f-0bd2534b7426@virtuozzo.com>

On Fri 06-09-19 13:54:30, Andrey Ryabinin wrote:
> 
> 
> On 9/6/19 10:27 AM, Michal Hocko wrote:
> > On Fri 06-09-19 01:11:53, Thomas Lindroth wrote:
> >> On 9/4/19 6:39 PM, Tetsuo Handa wrote:
> >>> On 2019/09/04 23:29, Michal Hocko wrote:
> >>>> Ohh, right. We are trying to uncharge something that hasn't been charged
> >>>> because page_counter_try_charge has failed. So the fix needs to be more
> >>>> involved. Sorry, I should have realized that.
> >>>
> >>> OK. Survived the test. Thomas, please try.
> >>>
> >>>> ---
> >>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> >>>> index 9ec5e12486a7..e18108b2b786 100644
> >>>> --- a/mm/memcontrol.c
> >>>> +++ b/mm/memcontrol.c
> >>>> @@ -2821,6 +2821,16 @@ int __memcg_kmem_charge_memcg(struct page *page, gfp_t gfp, int order,
> >>>>   	if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) &&
> >>>>   	    !page_counter_try_charge(&memcg->kmem, nr_pages, &counter)) {
> >>>> +
> >>>> +		/*
> >>>> +		 * Enforce __GFP_NOFAIL allocation because callers are not
> >>>> +		 * prepared to see failures and likely do not have any failure
> >>>> +		 * handling code.
> >>>> +		 */
> >>>> +		if (gfp & __GFP_NOFAIL) {
> >>>> +			page_counter_charge(&memcg->kmem, nr_pages);
> >>>> +			return 0;
> >>>> +		}
> >>>>   		cancel_charge(memcg, nr_pages);
> >>>>   		return -ENOMEM;
> >>>>   	}
> >>>>
> >>
> >> I tried the patch with 5.2.11 and wasn't able to trigger any null pointer
> >> deref crashes with it. Testing is tricky because the OOM killer will still
> >> run and eventually kill bash and whatever runs in the cgroup.
> > 
> > Yeah, this is unfortunate but also unfixable I am afraid. 
> 
> I think there are two possible ways to fix this. If we decide to keep kmem.limit_in_bytes broken,
> than we can just always bypass limit. Also we could add something like pr_warn_once("kmem limit doesn't work");
> when user changes kmem.limit_in_bytes 
> 
> 
> Or we can fix kmem.limit_in_bytes like this:

I would rather state the brokenness in the documentation. I do not want
to make the more complex. I have only glanced through your patch but
sheer size is really discouraging. Besides that the issue is really not
fixable because kmem charges are simply never going to be guaranteed to
be reclaimable and we simply cannot involve the memcg OOM killer to
resolve the problem. Having a separate counter was just a bad design
choice :/
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2019-09-06 11:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-01 20:43 [BUG] Early OOM and kernel NULL pointer dereference in 4.19.69 Thomas Lindroth
2019-09-02  7:16 ` Michal Hocko
2019-09-02  7:27   ` Michal Hocko
2019-09-02 19:34   ` Thomas Lindroth
2019-09-03  7:41     ` Michal Hocko
2019-09-03 12:01       ` Thomas Lindroth
2019-09-03 12:05       ` Andrey Ryabinin
2019-09-03 12:22         ` Michal Hocko
2019-09-03 18:20           ` Thomas Lindroth
2019-09-03 19:36             ` Michal Hocko
     [not found] ` <666dbcde-1b8a-9e2d-7d1f-48a117c78ae1@I-love.SAKURA.ne.jp>
2019-09-03 18:25   ` Thomas Lindroth
     [not found]     ` <4d0eda9a-319d-1a7d-1eed-71da90902367@i-love.sakura.ne.jp>
2019-09-04 11:25       ` [BUG] kmemcg limit defeats __GFP_NOFAIL allocation Michal Hocko
     [not found]         ` <4d87d770-c110-224f-6c0c-d6fada90417d@i-love.sakura.ne.jp>
2019-09-04 11:59           ` Michal Hocko
     [not found]         ` <0056063b-46ff-0ebd-ff0d-c96a1f9ae6b1@i-love.sakura.ne.jp>
2019-09-04 14:29           ` Michal Hocko
     [not found]             ` <405ce28b-c0b4-780c-c883-42d741ec60e0@i-love.sakura.ne.jp>
2019-09-05 23:11               ` Thomas Lindroth
2019-09-06  7:27                 ` Michal Hocko
2019-09-06 10:54                   ` Andrey Ryabinin
2019-09-06 11:29                     ` Michal Hocko [this message]
     [not found] ` <20190906125608.32129-1-mhocko@kernel.org>
2019-09-06 18:24   ` [PATCH] memcg, kmem: do not fail __GFP_NOFAIL charges Shakeel Butt
2019-09-09 11:22     ` Michal Hocko
2019-09-11 12:00       ` Michal Hocko
2019-09-11 14:37         ` Andrew Morton
2019-09-11 15:16           ` Michal Hocko
2019-09-13  2:46             ` Shakeel Butt
2019-09-24 10:53   ` Michal Hocko
2019-09-24 23:06     ` Andrew Morton

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=20190906112901.GF14491@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=linux-mm@kvack.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=thomas.lindroth@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).