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 C6F18C4345F for ; Tue, 30 Apr 2024 12:39:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C4976B0088; Tue, 30 Apr 2024 08:39:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24D066B0089; Tue, 30 Apr 2024 08:39:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C6DD6B008A; Tue, 30 Apr 2024 08:39:46 -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 DF0A76B0088 for ; Tue, 30 Apr 2024 08:39:45 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 53B4012030C for ; Tue, 30 Apr 2024 12:39:45 +0000 (UTC) X-FDA: 82066154730.22.221FEED Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf15.hostedemail.com (Postfix) with ESMTP id A7305A0017 for ; Tue, 30 Apr 2024 12:39:43 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="IJxLqIp/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of elver@google.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714480783; 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=PZRv4mKNGpnlZv+nzsq+J9a/kblTtfRZRI+IS2d96V4=; b=jknZ5MJULCv0bPzo8DJ7fcorLTXnP+1tvuBmDFB1fLYis5+AWrrFKioDptYjA8Ia+bUCXh kgij28jwpjYsnBwWGzdEhcKx366i0o3/HPWFezyInWyJHL6d9s9/1CkA7a5mMV6Y7zt0Cj RvQhmYuw7So8P71j6ArkueWLgMjgJf4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714480783; a=rsa-sha256; cv=none; b=MXFxtnYx/OClcyiC15rL9vYHoSfW7kZDjSarwIuh6m3oOi4jxh+eFBbg2pb1DHWgplaHXz nSIcVEdekp8xO1NkRFZ+augo6wHbHar0VrMTtOvBg1BabboPDBA7AcVKiGclRxz1GLXKyS CHJ/C9h8QhXSshZ7Iya3ljZa5QRn8tg= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="IJxLqIp/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of elver@google.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=elver@google.com Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-7f161a3eeb6so357435241.1 for ; Tue, 30 Apr 2024 05:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1714480783; x=1715085583; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PZRv4mKNGpnlZv+nzsq+J9a/kblTtfRZRI+IS2d96V4=; b=IJxLqIp/TQWPDgzx/ZCA/B1i4ZZisLr808rP45RhGe8s0ryooP6tGQSybf6LYR0OaM O+MMGIWUeInDrfrWCaqmDUOOdSLc+h2ZNDYTuVtEIiv9LCmqDXgwz75RidX8zipupGtp RTlGsyiHfmh6GcJUT9/44eB3umxUCt/eif1wBkVq4jBqIfsSMNagyhcxChu9pBWIGzIF Q+IlwF0s0DEDLD7umvQJdvHJOtUyHRvA3KygFDDpy+J4wbNHcInz1ABKJ2LERCVMbG0G EXUUsc9VIu/wgoe+C5iexa2JnAdyTRJfCY90pJ4ew/etRjaSGPbjqyDE1B0nbc+KX+fO ODsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714480783; x=1715085583; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PZRv4mKNGpnlZv+nzsq+J9a/kblTtfRZRI+IS2d96V4=; b=Q8L6ZxythUrPkSL0E5nzLS0SAYOZKXJSu4IiJnXha1aKJci4Vh5mBe7bbgh0g2muLi YNeQx/iZnI/Z0kvmugZPGWA+uY7DhfF+YPaKRyu5a53ZkOqPl2g1ukPBmV48v9Lad4Bt KxEvFrqcb/E8Ocq6qw6GmWmFSmGN0zlIp2iU4SdCDXK7Fq8OW7XfHC9F4J7huecDkNtA UK1hg4Oiw2QZaXy8jhpHnK57nYR7ZeI/A9OuLZuydtfOe9W/TpJePDwv3PyQxOYMQ7aO pxrovov2A+r1o3uUoqQpbH5VtEGb8dVNUHUZ58GdSH1lIQmx7svdXm3yvjbSBGYpabeU 82Cg== X-Gm-Message-State: AOJu0YwZffL7w0H2H//rJNM4gfd73POAfWfP8WdMCuVSxpwgRc/YFxZy 4QrN0KYZqxBoyCNJPkIljTxyxHIHVbBNMl9CICCKF8q7GYBPyUZ8Wa4bIFvOez5GVBjternCUln ioRnSqjdECQMon1Hdx7u+knxIqcHfoGEQdfig X-Google-Smtp-Source: AGHT+IHyjMVbPcaMiV1qHC09V0wXme2k4N77APd0OWHpJKNbqJbrVwAzQ3kXjJKvqQ3gXS0iWjPzoK/bZ94N2sqjAGQ= X-Received: by 2002:a05:6122:311f:b0:4d4:5d86:b2d with SMTP id cg31-20020a056122311f00b004d45d860b2dmr13994961vkb.16.1714480782463; Tue, 30 Apr 2024 05:39:42 -0700 (PDT) MIME-Version: 1.0 References: <20240430054604.4169568-1-david@fromorbit.com> <20240430054604.4169568-2-david@fromorbit.com> In-Reply-To: <20240430054604.4169568-2-david@fromorbit.com> From: Marco Elver Date: Tue, 30 Apr 2024 14:39:04 +0200 Message-ID: Subject: Re: [PATCH 1/3] mm: lift gfp_kmemleak_mask() to gfp.h To: Dave Chinner Cc: linux-mm@kvack.org, linux-xfs@vger.kernel.org, akpm@linux-foundation.org, hch@lst.de, osalvador@suse.de, vbabka@suse.cz, andreyknvl@gmail.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A7305A0017 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 8jbem8m76tqwfsqwob6far9j55u1hj5z X-HE-Tag: 1714480783-389369 X-HE-Meta: U2FsdGVkX1+q+YEldKddd+/LS9T3vCYi3qISlyEMJPZbUyx/rA9S3cSZ4TmAZEwEl52fBhOjlm2m+H1u3dPvWxq/zCmJQJfjPKt8jsCaoBXYdYewLiA0slkKCag+dzDwfFy/2mv3jtQlD0U7ZCwRbsF1mN4W0f8ifTcQbPqRwZG3nr2LwadrETGCJ/UEvc0z+/Rg0f9nYnMrog+E3rl0W/JEWFeEpYsEuK2TOgsCTfsfd9uYgDFJN2kxkf5bz//cqDgXEUh4YweSOoXPIK7ZxaYXT+anw6LwKCLYqThR/Vk/phza1iNU7Sm/4Y3lhVw4HT7QAICFywHYLjnq3RezBSEv6wJ6Lt98MI0D/0G5dSj0to/z1NAaeypwahAPVG4CPhuwEkhVNByfeZOP0kEhBAqN9v5/Mm+EAGJXd+193znaUU19rMhoiHx18cgtmZY6OWEDRdpg/5ZIMgR20u5ipbsGneq8T++NqJG8DuT8GhOkuaLRV69Qo71rHUKrj3E5JcUItmDNrgTBL0rULtiu22ou8EeqLiAYwtRsm0bPUmoaJjlryZrMFb44wi1vAcpJe0+sSUnmogSCcfSJ+jybpYFcvWjNLx+P1sGQTVkmmOb0Sv01PM+s24dEapNGWabtEoElaNTfQh2Fwp6cJZFqqWW6fK8EsmiTFf1sPHqUTRhWM7lWP591IdJnP6tQeCe1VXttxYQ+DAVLa0CHOCVszf5o20uUaSQQNAiCAiYr4jmhHLJmbIhboFAGmr0aXJ2YHI59C5DhXIDCAUU5cfCSFeZrm8Ev0uatzESjRYGC2i/hpmXgKH3fl5zlQkfQgd78/pZwRb0ypZgKMQikKhsfGXt6PgQn/A0Jm5Y34V6WVJKwlqV00NT51pVxf3Trk8/JxoFzwv1yuczE6A0ybUZ79kQxtruJoqceapma4vs5Dofd4hHaKUtkGDzlwv8vC/t8kIOYZaXQOLOaiCyRySz qxy6Ypav oJSmWZSS+mYvtX9tvrqL7aailJOPcxwXI10OaBtE9ulG5FVJ9R6mjQMzFO5AUJ/9L9P9YZpe2k9b+332t7s1HUQ9rriaCL2Rg8/aze1iFfsieyLHBSduJwpugfzYc4YFIcVg9cz8WeCNFLrh+3hUiIG8RlIWB6BJZXMfZXPDLXtTx+IP8HjRMQpWkfkcKv1lPP8KA+LF34TGqLHpgNwH36N60r+bHVJYBReMZVYyU9Y7FqdRFpQ+ZSyFCTq8T4ZCz1qcsra6i+QxgLfR9Mq3PuEzdd17LNRe2xF/wJuAE2/F+4stTJKZRutUPS2x1mtTEwbL22JLcn1OKYkOwMRsxjhH7TFZcl6JeBxgPp1VTFYAEo+M2jVawpQ+r7kSXYW65CCkK 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: List-Subscribe: List-Unsubscribe: On Tue, 30 Apr 2024 at 07:46, Dave Chinner wrote: > > From: Dave Chinner > > Any "internal" nested allocation done from within an allocation > context needs to obey the high level allocation gfp_mask > constraints. This is necessary for debug code like KASAN, kmemleak, > lockdep, etc that allocate memory for saving stack traces and other > information during memory allocation. If they don't obey things like > __GFP_NOLOCKDEP or __GFP_NOWARN, they produce false positive failure > detections. > > kmemleak gets this right by using gfp_kmemleak_mask() to pass > through the relevant context flags to the nested allocation > to ensure that the allocation follows the constraints of the caller > context. > > KASAN recently was foudn to be missing __GFP_NOLOCKDEP due to stack > depot allocations, and even more recently the page owner tracking > code was also found to be missing __GFP_NOLOCKDEP support. > > We also don't wan't want KASAN or lockdep to drive the system into > OOM kill territory by exhausting emergency reserves. This is > something that kmemleak also gets right by adding (__GFP_NORETRY | > __GFP_NOMEMALLOC | __GFP_NOWARN) to the allocation mask. > > Hence it is clear that we need to define a common nested allocation > filter mask for these sorts of third party nested allocations used > in debug code. So to start this process, lift gfp_kmemleak_mask() to > gfp.h and rename it to gfp_nested_mask(), and convert the kmemleak > callers to use it. > > Signed-off-by: Dave Chinner Reviewed-by: Marco Elver Looks very reasonable, thanks. > --- > include/linux/gfp.h | 25 +++++++++++++++++++++++++ > mm/kmemleak.c | 10 ++-------- > 2 files changed, 27 insertions(+), 8 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index c775ea3c6015..a4ca004f3b8e 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -154,6 +154,31 @@ static inline int gfp_zonelist(gfp_t flags) > return ZONELIST_FALLBACK; > } > > +/* > + * gfp flag masking for nested internal allocations. > + * > + * For code that needs to do allocations inside the public allocation API (e.g. > + * memory allocation tracking code) the allocations need to obey the caller > + * allocation context constrains to prevent allocation context mismatches (e.g. > + * GFP_KERNEL allocations in GFP_NOFS contexts) from potential deadlock > + * situations. > + * > + * It is also assumed that these nested allocations are for internal kernel > + * object storage purposes only and are not going to be used for DMA, etc. Hence > + * we strip out all the zone information and leave just the context information > + * intact. > + * > + * Further, internal allocations must fail before the higher level allocation > + * can fail, so we must make them fail faster and fail silently. We also don't > + * want them to deplete emergency reserves. Hence nested allocations must be > + * prepared for these allocations to fail. > + */ > +static inline gfp_t gfp_nested_mask(gfp_t flags) > +{ > + return ((flags & (GFP_KERNEL | GFP_ATOMIC | __GFP_NOLOCKDEP)) | > + (__GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN)); > +} > + > /* > * We get the zone list from the current node and the gfp_mask. > * This zone list contains a maximum of MAX_NUMNODES*MAX_NR_ZONES zones. > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index 6a540c2b27c5..b723f937e513 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -114,12 +114,6 @@ > > #define BYTES_PER_POINTER sizeof(void *) > > -/* GFP bitmask for kmemleak internal allocations */ > -#define gfp_kmemleak_mask(gfp) (((gfp) & (GFP_KERNEL | GFP_ATOMIC | \ > - __GFP_NOLOCKDEP)) | \ > - __GFP_NORETRY | __GFP_NOMEMALLOC | \ > - __GFP_NOWARN) > - > /* scanning area inside a memory block */ > struct kmemleak_scan_area { > struct hlist_node node; > @@ -463,7 +457,7 @@ static struct kmemleak_object *mem_pool_alloc(gfp_t gfp) > > /* try the slab allocator first */ > if (object_cache) { > - object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp)); > + object = kmem_cache_alloc(object_cache, gfp_nested_mask(gfp)); > if (object) > return object; > } > @@ -947,7 +941,7 @@ static void add_scan_area(unsigned long ptr, size_t size, gfp_t gfp) > untagged_objp = (unsigned long)kasan_reset_tag((void *)object->pointer); > > if (scan_area_cache) > - area = kmem_cache_alloc(scan_area_cache, gfp_kmemleak_mask(gfp)); > + area = kmem_cache_alloc(scan_area_cache, gfp_nested_mask(gfp)); > > raw_spin_lock_irqsave(&object->lock, flags); > if (!area) { > -- > 2.43.0 >