Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] mm: page_alloc: document kmemleak's non-blockable __GFP_NOFAIL case
From:   Catalin Marinas <catalin.marinas@gmail.com>
In-Reply-To: <20190715131732.GX29483@dhcp22.suse.cz>
Date:   Mon, 15 Jul 2019 10:01:00 -0500
Cc:     Yang Shi <yang.shi@linux.alibaba.com>,
        "dvyukov@google.com" <dvyukov@google.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F89E7123-C21C-41AA-8084-1DB4C832D7BD@gmail.com>
References: <1562964544-59519-1-git-send-email-yang.shi@linux.alibaba.com> <20190715131732.GX29483@dhcp22.suse.cz>
To:     Michal Hocko <mhocko@kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 15 Jul 2019, at 08:17, Michal Hocko <mhocko@kernel.org> wrote:
> On Sat 13-07-19 04:49:04, Yang Shi wrote:
>> When running ltp's oom test with kmemleak enabled, the below warning was
>> triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
>> passed in:
>=20
> kmemleak is broken and this is a long term issue. I thought that
> Catalin had something to address this.

What needs to be done in the short term is revert commit d9570ee3bd1d4f20ce6=
3485f5ef05663866fe6c0. Longer term the solution is to embed kmemleak metadat=
a into the slab so that we don=E2=80=99t have the situation where the primar=
y slab allocation success but the kmemleak metadata fails.=20

I=E2=80=99m on holiday for one more week with just a phone to reply from but=
 feel free to revert the above commit. I=E2=80=99ll follow up with a better s=
olution.=20

Catalin