From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 898D1C433EF for ; Sat, 2 Jul 2022 05:50:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E350F6B0071; Sat, 2 Jul 2022 01:50:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE4BB6B0073; Sat, 2 Jul 2022 01:50:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD5A46B0074; Sat, 2 Jul 2022 01:50:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BE7956B0071 for ; Sat, 2 Jul 2022 01:50:52 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 92B6780DC3 for ; Sat, 2 Jul 2022 05:50:52 +0000 (UTC) X-FDA: 79641085944.16.A6FCA05 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf15.hostedemail.com (Postfix) with ESMTP id 39ECBA003C for ; Sat, 2 Jul 2022 05:50:52 +0000 (UTC) Received: by mail-pl1-f173.google.com with SMTP id n10so4220307plp.0 for ; Fri, 01 Jul 2022 22:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8qtzQsHSUiJ4njxuFZSHmk7WzYx/9S8h0IgnGcSJp0Q=; b=XbpRXQnjxt6+EHcIDifmMhgCz9P8NjZYvPJBAcZpS+YAbhdr4Mf7ucGl3K9kDWb3Sk +omwUSF8e7r/y9zsWXeYQTGko6DwIp1zn8qlu0/b97RKhhQur2P7I6eOomkFo2PU1ALH hgR0bVsN0kiKxy8apJ780YH98SbKF0ZRzjbv68R9DXzZ8zDo3WWIaeYNFgNMUcwHJtm3 NA2FDZizt58+qGaSs1wCCGy6jERhpsILnicGek6cuTJ4TWYSyapTs3JoLWOCGZTy6FS0 aAtJWrvejyeFPvDiCh/SKTO4KRN+neIA605mh/Dpcy9lOJCa++OhJPONojzpSN0nzgZD 6ydg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8qtzQsHSUiJ4njxuFZSHmk7WzYx/9S8h0IgnGcSJp0Q=; b=J6UYQpOh6yYKkAfERSkuKqrKjKixDbSnrmZx3lB+D/RhnKpXkG1dYEm2tEdvBIGrC0 ahPknv67/V0Kv083yMxcKuJx+kUE3p1WE3Hj0oaePbrZujzZjJaXcW8HiV5l8LYio3uG aqvgBZODPSyDQkSBG5qhAJExFmXNjx56PYc7z6Fi4gZFBzwM09uQeOcVhPKGUt3F/2Yb 07LsxF90CxJPDIelsqOROkUharJ5/j+/TXFLMhSWjpzdewow1/VVA0ML1pUOcRk4nwUp 7+qSTB+hZFMyqMHT16AnIDuqEnU4u/RbbIAx34XyWaXiYrJuvPCIr3upzEdgKrWTzqw4 +30w== X-Gm-Message-State: AJIora9cHxza19Wdi4g73l00BqfyCzZ33y/iO9D2DgGxZO9ZPVexCHsq Vw3SBO34Iba1ZpbOOHdsEp6TmWMphIwY/HDZlCs75Q== X-Google-Smtp-Source: AGRyM1vbSQdXGyH6L0zs8jtlDMyZ8BzhUpRxx/EAh8d4seGyQA8pdfr8jTcN+NEamh6jseV0fEVo1N0tm0Twp8/02rc= X-Received: by 2002:a17:90b:3b92:b0:1ec:b866:c398 with SMTP id pc18-20020a17090b3b9200b001ecb866c398mr20816134pjb.237.1656741050960; Fri, 01 Jul 2022 22:50:50 -0700 (PDT) MIME-Version: 1.0 References: <20220702033521.64630-1-roman.gushchin@linux.dev> In-Reply-To: <20220702033521.64630-1-roman.gushchin@linux.dev> From: Shakeel Butt Date: Fri, 1 Jul 2022 22:50:40 -0700 Message-ID: Subject: Re: [PATCH] mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations To: Roman Gushchin Cc: Andrew Morton , Yafang Shao , Johannes Weiner , Michal Hocko , Muchun Song , Cgroups , Linux MM , bpf Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656741052; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8qtzQsHSUiJ4njxuFZSHmk7WzYx/9S8h0IgnGcSJp0Q=; b=dBF2TlZ6bah+xHJzdAjrYQTaARJ+83Xf4HMudi18s6GxbHyF9173ZmO21/NoaRE/ZLxIke G7LlW4uh7tQ1BXueiru6DI54JABKnh04ICPC9YePnTBkGjodQaNKL/icBchOI9xjRRd01r ylwN2bQ2JlADG52DSgHxNxCxowgPPUM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656741052; a=rsa-sha256; cv=none; b=uy3d2qf7xeK2HMbRb0ez7R+3F9ZcbhCTlPkxICmB+i9i2mPTsIsKorXTCusmV4Mn/MimNl LFkoucgV/iglii7Z3WcNfViqkBVgoHVZBy51JI60f39M7CfAIQOKEHjRK/XSCXubByfiIv macTT0Z+LvI+A+CjFs5VA2awzXCeANo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XbpRXQnj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Stat-Signature: 3kkb8c8zhab9j8qmi3rq6npdwcrjt3jj X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XbpRXQnj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 39ECBA003C X-HE-Tag: 1656741052-732852 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jul 1, 2022 at 8:35 PM Roman Gushchin wrote: > > Yafang Shao reported an issue related to the accounting of bpf > memory: if a bpf map is charged indirectly for memory consumed > from an interrupt context and allocations are enforced, MEMCG_MAX > events are not raised. > > It's not/less of an issue in a generic case because consequent > allocations from a process context will trigger the reclaim and > MEMCG_MAX events. However a bpf map can belong to a dying/abandoned > memory cgroup, so it might never happen. The patch looks good but the above sentence is confusing. What might never happen? Reclaim or MAX event on dying memcg? > So the cgroup can > significantly exceed the memory.max limit without even triggering > MEMCG_MAX events. > > Fix this by making sure that we never enforce allocations without > raising a MEMCG_MAX event. > > Reported-by: Yafang Shao > Signed-off-by: Roman Gushchin > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Shakeel Butt > Cc: Muchun Song > Cc: cgroups@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: bpf@vger.kernel.org > --- > mm/memcontrol.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 655c09393ad5..eb383695659a 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2577,6 +2577,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, > bool passed_oom = false; > bool may_swap = true; > bool drained = false; > + bool raised_max_event = false; > unsigned long pflags; > > retry: > @@ -2616,6 +2617,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, > goto nomem; > > memcg_memory_event(mem_over_limit, MEMCG_MAX); > + raised_max_event = true; > > psi_memstall_enter(&pflags); > nr_reclaimed = try_to_free_mem_cgroup_pages(mem_over_limit, nr_pages, > @@ -2682,6 +2684,13 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, > if (!(gfp_mask & (__GFP_NOFAIL | __GFP_HIGH))) > return -ENOMEM; > force: > + /* > + * If the allocation has to be enforced, don't forget to raise > + * a MEMCG_MAX event. > + */ > + if (!raised_max_event) > + memcg_memory_event(mem_over_limit, MEMCG_MAX); > + > /* > * The allocation either can't fail or will lead to more memory > * being freed very soon. Allow memory usage go over the limit > -- > 2.36.1 >