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 07775ECAAA1 for ; Tue, 6 Sep 2022 07:30:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78ED48025D; Tue, 6 Sep 2022 03:30:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73D7980224; Tue, 6 Sep 2022 03:30:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62C0C8025D; Tue, 6 Sep 2022 03:30:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 54BC980224 for ; Tue, 6 Sep 2022 03:30:23 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 288191405A6 for ; Tue, 6 Sep 2022 07:30:23 +0000 (UTC) X-FDA: 79880837526.30.1ADDDD1 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf01.hostedemail.com (Postfix) with ESMTP id D5C7B4006C for ; Tue, 6 Sep 2022 07:30:22 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id s15so11324638ljp.5 for ; Tue, 06 Sep 2022 00:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=DiSpmFkHopXEMzzo8GEVfCCu3wvcb3PHuqr/MihPiik=; b=Suy9xaG0hDq6pQIqD17PejsNfIIVQ1gI46mV663jKAw1v93lFaPhwY9IXY8ghDVxKy d9DJginmJWkDWy7YLyofcSmFzx5yNI46hnqeFDJ0ZiYHX8g4Z3syWLNSsEvIYTl5svws 5eUaITyEljNt+AdQViAPPPIbkgxUeWRQ6pZtP7XE/tDfRMaflkFeMvCuiu4pbMtgh6tz mOLeTB3S/UIWTFRvxPjR16iKNah2ZXHtbHPzx5w7kssmGwGre5C4qQXwhXE9UgwPiSOz 4yHIe9K45Ytj9KeRxBMRtLnYaIw8vhxVdMSWHLKkhZgZQoh9qOSQN65BUQXgvNMNLWcB HdeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=DiSpmFkHopXEMzzo8GEVfCCu3wvcb3PHuqr/MihPiik=; b=2yUlwblJuvuDVYQ4IUYEHBHtXobrL9mVB6rgaRx6BJ+kDNI2B8NYZXUjATI4KINc7X 8Xrmcm/GdaUjkD4sLAUZiI8dxx5lrC9/UXjqCN68bU47LnAH3u4iXDU265gheoFlJXoi aveUOStl5gCZ49iJx0pbJZh6xMWu30Me8NEmkXYvhEyuLY7Juy8oNg7rpZbtGbY2OKB/ vF1GsA4FEzVvmuyPqh42fabXzUvN7Y4eGQ2/af+sG6J/prlX1x1j6tUXqt5qKfP23uaA oVnod39aly5ek0TWS4SiYVE3reO0LLbiQ+Owkc4SYbMgatLqHp7R3Pb8cOuBfMwskv2M 4TNg== X-Gm-Message-State: ACgBeo0hb6YWtSi80Xt14bh4XhA3KSOAFvcqcfCgiiQCEeqLwqiRwxYs Mfu6or4BxadVfsX2hGittfomxccgt9XghoOVeMg= X-Google-Smtp-Source: AA6agR4t+tu3ZAd8IIAOVS0YvuOjTmZsbQrd1ilWJTHuJQPtGKs9Z7gCq7sk1u98aeMMci/idTKSyrQKZwEnHC+WP8I= X-Received: by 2002:a05:651c:2203:b0:26a:44ad:706c with SMTP id y3-20020a05651c220300b0026a44ad706cmr3414950ljq.359.1662449421133; Tue, 06 Sep 2022 00:30:21 -0700 (PDT) MIME-Version: 1.0 References: <1662116347-17649-1-git-send-email-zhaoyang.huang@unisoc.com> <20220902115839.1e3fafd159e42d4e7dae90af@linux-foundation.org> In-Reply-To: From: Zhaoyang Huang Date: Tue, 6 Sep 2022 15:29:52 +0800 Message-ID: Subject: Re: [Resend RFC PATCH] mm: introduce __GFP_TRACKLEAK to track in-kernel allocation To: Matthew Wilcox Cc: Andrew Morton , "zhaoyang.huang" , Catalin Marinas , "open list:MEMORY MANAGEMENT" , LKML , Ke Wang Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Suy9xaG0; spf=pass (imf01.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662449422; a=rsa-sha256; cv=none; b=TEmzacRRdTq4bJetoEYRK/azliABLvnMw98/4l/KkXQkr7e6Eh6QiUZ+NGFuyK6xQGcZSe peVscU1+PlcCHlCZyGmKeQgJlal+hoShrLKX5wBitlVzpURasyS5qH1eQUFSsW0jUXJjqB hDlPqKcbFSICnjl34FPHxFGE1I0wm6g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662449422; 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=DiSpmFkHopXEMzzo8GEVfCCu3wvcb3PHuqr/MihPiik=; b=rR/5NHGUopY//FZriY1G23No/av38BvuxHmESp05+5HVCRbZ9iQKmkPrcpXaHOcOL7fSto hkw5BziGffK1n56PQ9XSHXN/6WYEZlML1x6YuQNz4V5kTC7tldUcFThML3d5Jykr3+U/SV 8RG98PffE3lpg5gQHrgzhoLlRq7BGXo= Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Suy9xaG0; spf=pass (imf01.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: hzboh7q88cnjden8gchh7bp5soztugir X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: D5C7B4006C X-HE-Tag: 1662449422-40419 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 Sat, Sep 3, 2022 at 3:08 AM Matthew Wilcox wrote: > > On Fri, Sep 02, 2022 at 11:58:39AM -0700, Andrew Morton wrote: > > Cc willy for page-flags changes. > > Thanks. This is probably OK. The biggest problem is that it won't > work for drivers which allocate memory and then map it to userspace. > If they try, they'll get a nice splat, but it may limit the usefulness > of this option. We should probably document that limitation in this > patch. > > > On Fri, 2 Sep 2022 18:59:07 +0800 "zhaoyang.huang" wrote: > > > +++ b/mm/page_alloc.c > > > @@ -1361,6 +1361,8 @@ static __always_inline bool free_pages_prepare(struct page *page, > > > page->mapping = NULL; > > > if (memcg_kmem_enabled() && PageMemcgKmem(page)) > > > __memcg_kmem_uncharge_page(page, order); > > > + if (PageTrackleak(page)) > > > + kmemleak_free(page); > > Don't we also need to __ClearPageTrackleak()? ok > > > > + if (gfp & __GFP_TRACKLEAK) { > > > > And we'd want __GFP_TRACKLEAK to evaluate to zero at compile time if > > CONFIG_HAVE_DEBUG_KMEMLEAK=n. > > > > > + kmemleak_alloc(page_address(page), PAGE_SIZE << order, 1, gfp & ~__GFP_TRACKLEAK); > > > + __SetPageTrackleak(page); > > > + } > > We only set this on the first page we allocate. I think there's a > problem for multi-page, non-compound allocations, no? Particularly > when you consider the problem fixed in e320d3012d25. Please correct me if I am wrong. AFAICT, the leak_object is created for tracking from page_address(page) to page_address(page) + PAGE_SIZE << order via checksum of the whole area while not referring to page->cnt. Non-compound high order tail pages will not be checked anymore since the leak_object has been freed together with head page by put_page, whereas, it would not be a problem as the tail pages should NOT be accessed also as they should be considered as buddy pages, no? > > I'm not opposed to this tracking, it just needs a bit more thought and > awareness of some of the corner cases of the VM. A few test cases would > be nice; they could demonstrate that this works for both compound and > non-compound high-order allocations.