From patchwork Tue Apr 30 05:28:23 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Chinner X-Patchwork-Id: 13648274 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 5CE40C4345F for ; Tue, 30 Apr 2024 05:46:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCB526B0089; Tue, 30 Apr 2024 01:46:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B78CC6B008C; Tue, 30 Apr 2024 01:46:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1B446B0095; Tue, 30 Apr 2024 01:46:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 682C96B0089 for ; Tue, 30 Apr 2024 01:46:19 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 16AED160569 for ; Tue, 30 Apr 2024 05:46:19 +0000 (UTC) X-FDA: 82065112878.08.B5C4498 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf29.hostedemail.com (Postfix) with ESMTP id 441B212000F for ; Tue, 30 Apr 2024 05:46:17 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=WMJyQO+8; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf29.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714455977; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=afP6uLcLEQVtnVJJKaVxA8xiCeVS0XyPUQmW3bND5yY=; b=cjzZ//ycwq5I7Qlcgwit6Ky5I0Zjb9xNmA8lWiHWiVxMWnZvwnLghE0vhaDoZef7yygSB9 0O+pBwbbGHthyZkgajBnB8NYnlP8pQOkzCewb+p8EF6ETV0ZFJSvtiO+nGHRyidcS2Zl0h /Z1Bi4tHMwxDRMcdgVog1sqbztRe4EM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=WMJyQO+8; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf29.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714455977; a=rsa-sha256; cv=none; b=xAX33pfez6uOMpweQ4S7BkqbWv/TKvm8hUaUM5QRoISEry7DoW4YBr21njv5YetI1KeYVj tQrutlc2DlxMmVJwlxTL1GbzUDEE0U5kCKj8HxXN1uGtdtN67KM2T8tVu3JphzF1ltHmfL B7d/wBFxYyqI2I+j25FmcmLm+P/Thrw= Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1e86d56b3bcso48251165ad.1 for ; Mon, 29 Apr 2024 22:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1714455976; x=1715060776; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=afP6uLcLEQVtnVJJKaVxA8xiCeVS0XyPUQmW3bND5yY=; b=WMJyQO+89cjGRl2axXqXQ1/VAhY7FACYA22P+QKSryo6DlumJbWLfcjMqrW5qheFJZ oBSpcGYjpCIFKzUJU9K0fgLmHSkjiQmAaOcRRudkkFIzX95M2GOgYoqGtmpXcjOmavur lHIb0gXV56CkGKZanhHwktAPaiznoMulNmDUQ+dj0MXUe/T8bmc9QEJlJmkoQYo8NUcX UPv/6Nrsfa/LhWW3+ujXWRwT/0K09SrfJpsgLegQTdG2onKyYgrqWDgzJYrreDtbszNV DStudYb6QiFb5kcVlA+tCmjlG4zuPmGvI4FAAv0ieaYSweIcdK/aNBfRa0SfBQlKC8M1 X6mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714455976; x=1715060776; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=afP6uLcLEQVtnVJJKaVxA8xiCeVS0XyPUQmW3bND5yY=; b=gVcbeNqSZRTjPD9oWBvzJI0fSCtHxWvQQhkYa/dllx9/6wvCei+jO1N29SI68HeCaE 2j8gIs+pxPlPYCELFsUz3H7kjD8EAML4VXOYoKZJDlClTvJJm/l+pYb+gDY2YSmwwCbC cLnoAPvlNxPZyNnRHxzwrHVX8wHjy90os0p2iBSo+La6nPevDw6AwgKZBVOkrzbB+M42 07EN790ViXjK1FvZMdmVsEHBQlrXGSpYLNFciPRA/zbjOPl8lMoyKKcOn/PZPrVj03Dt Ejq8cThYEB6+aCmDrKoLI3zqQSmg9EpDz/cNVOrhnMZVOfcz9UtsqnrmYzlQqju3u6Gu selg== X-Gm-Message-State: AOJu0Ywud4zXAHE2DW3Xr2Kx210NKND+/xvYu7oLwkSfSsMweTEg55fh ZWbbqTrjxhAUv8oa8TTgscyEcZ9eO+ktxu9uDIeH7fh0cyK7Y9ovQs3UDAlN7ULpv8DOD65qn0F F X-Google-Smtp-Source: AGHT+IHfRat6F8yIN7+2x4pzgcpjky23ySzyPfrQ6r5F2OTC8Is4yOECP718T/VXfznbNFuUF0NMLw== X-Received: by 2002:a17:902:f60f:b0:1eb:1af8:309f with SMTP id n15-20020a170902f60f00b001eb1af8309fmr2194540plg.4.1714455976018; Mon, 29 Apr 2024 22:46:16 -0700 (PDT) Received: from dread.disaster.area (pa49-179-32-121.pa.nsw.optusnet.com.au. [49.179.32.121]) by smtp.gmail.com with ESMTPSA id c13-20020a170902b68d00b001e8a7ec6aabsm20267530pls.49.2024.04.29.22.46.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Apr 2024 22:46:14 -0700 (PDT) Received: from [192.168.253.23] (helo=devoid.disaster.area) by dread.disaster.area with esmtp (Exim 4.96) (envelope-from ) id 1s1gJg-00FsCE-20; Tue, 30 Apr 2024 15:46:12 +1000 Received: from dave by devoid.disaster.area with local (Exim 4.97) (envelope-from ) id 1s1gJg-0000000HUwp-0TU0; Tue, 30 Apr 2024 15:46:12 +1000 From: Dave Chinner To: linux-mm@kvack.org, linux-xfs@vger.kernel.org Cc: akpm@linux-foundation.org, hch@lst.de, osalvador@suse.de, elver@google.com, vbabka@suse.cz, andreyknvl@gmail.com Subject: [PATCH 1/3] mm: lift gfp_kmemleak_mask() to gfp.h Date: Tue, 30 Apr 2024 15:28:23 +1000 Message-ID: <20240430054604.4169568-2-david@fromorbit.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240430054604.4169568-1-david@fromorbit.com> References: <20240430054604.4169568-1-david@fromorbit.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 441B212000F X-Stat-Signature: aqhjwdr1ybz5117hsr46prt8ianwibio X-HE-Tag: 1714455977-596437 X-HE-Meta: U2FsdGVkX19aHcVzqidMiB2LOsAfS+COgX9xnMd/t59V3fRPR05H9HoJTz2/x+TrrOFsx8++2bdGt2HcjcuMDzTlL7NzRyA3iHH1QnRuMaHiT8SxbsiYid5IBBjLXZTvJui+dcIQY5ndUZCmtW/mRzWZVWrpxGRdOLz7/Qj/gnvC0536OIalerOKszBKImZZC3KLd4RZmYOF3hko5Sq58LbS05TlR4RTS9IH+P5spbn+UwASlujwZxQJGaH7caUUNUhiEx0RpPrhaMWpjtSiLhD6AKTjRXa2Y/vUH+dYBi+SLFjYfUETyeMeg2eIO7qByo7ECcH9O1PIRbDY/GcBsug6Qqgc2PaDddmOPjAGWtLt3jz+X7FsOIJepCRoNgHQLBqYHueeSsQ3wghBemsGAceSFrNnWb7xbuKMW8xhYOMmaPkP13i9xKbf70QX6hFgBUOiu7R8IJ4RraOV9/yqOydaCqWMnSnHxNPjptwhCDaSEi1bRKPYf6nUR/DoJL6q9NOmGDj7lDf7Tr8EYsxlHgt+Mm4Z+O1wIxr+hmxbGow9yDMiOwh+g1pD6aDunUaO6clLX+gg3VGondsddPEsQXmsbaI9zRlxMljg9fubEhlqm6wN0ySQEHrfv/ubJByuE2BLy2pzEWYrxChF138K1huTfDCFOc3RUZQGAMLRZZpzwVrGF7boh/Zih6ZTUW/2LxXIYLqLbfQgGcpzaI8RP4U9kHfZdgbbFPyCE75/RPH0Rq3OJKuaJqQM2rylM6OR4aEPzHsibckprZxNsvgD77o8I8orMesYzoIThToAH9ManuRwCJnUNE4nMdr9133GwmBeCBlMFR97QGj9P0LurE9hKXkuz64cYzFCVh4CRzaOVvLjNVieFLu7RKb/L6Vka+GSUOyuFWhhM/iIC2bZ0ix8d/HKMTmq8BodTY2713RD+1MIsHIGWTUdnA47jUaWtvy4krVwQ8fnHZz4lJb fOqUX6Of cLr4TkqbVIuOxT7Zd3YC5RFxvCD8cUXJK9fMI5E1PMiOArcak4+oa5IHEKLeyGldJfs1stF6GWxecqGR/FaAqDGVC/PGybQIpeIn6nLUgYdzR0z3tpgO4rKF8YQcz8MyHplTaGGrXTb9xGwFUa32m6DeyMmRr+SvPOK11iWR5RjYNGEj2jcyFpdS/qcSKt8ipCYZo/YFmDmhX7C747PW1BbV6jhJ4BIoZVYD8uqhnwshKLP9ruUT941BFx5mT7iFmL1DRMqj4YAnOdyuN9Cwl12AkHMSB77pPf88r/+wJpmEyZDHJjruJK1znES8akGO7VM1FC2NPY1f5ravTNYii7J2xBUN81yPiyKCwrACWQL+zTe8dzrWoIdV3cEziR6PvGwAPH+sgWs0NvgqIvbzMxvDjp7HqikAm8i7yCPXMlDFZNZcUqVnc5LibP87iznyKeJ39wWs72vBSXF0b6nCSZZYPTAbK2A21eEnjf20X8hYJ9co= 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: 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 --- 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) {