From patchwork Tue Apr 30 05:28:22 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Chinner X-Patchwork-Id: 13648272 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 C4AD0C10F16 for ; Tue, 30 Apr 2024 05:46:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 476D96B0088; Tue, 30 Apr 2024 01:46:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 425EC6B008C; 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 0CB6E6B0088; 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 DEF156B0089 for ; Tue, 30 Apr 2024 01:46:18 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6991B120454 for ; Tue, 30 Apr 2024 05:46:18 +0000 (UTC) X-FDA: 82065112836.20.1721951 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 84F3320016 for ; Tue, 30 Apr 2024 05:46:16 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=d4RggpMx; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf03.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.172 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=1714455976; 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:references:dkim-signature; bh=5L+DbHHyg9/U1kdFGH+74R7K4u9DGBrF4s+3873+bY0=; b=xilQMNRNEUr0qvbQgE4luy73nAG8FH6MkbYN1D06s7MzCHoyLSZnKvnlvj3m9JSAyc4iLU EsiU0tYSkAgkZmBT9ulpON9DdeeGQRvyn8ilMv8Y4XskbbaUESQkOTm/59W7AEe1vKfOOP fxsTEXeo6+FOk/KfQ5PfXaICT2bI0wY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=d4RggpMx; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf03.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714455976; a=rsa-sha256; cv=none; b=YXKw60Hoqr1s+cK15ZDbMIfcEz9tbYDT/GQ57lJJVyqooTIWi6OLWJ/14bWXpf6A5q7BK5 DMdMfKyYHeBJ8AC7+9V5pKMR7YMTIC3IQhTQhoIxtOdR5QS0D9/0TLAOQim417M10VJs5v xXdcb4U68Qk94VQ5so9NmoTMvobwEGM= Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-6123726725eso1643527a12.3 for ; Mon, 29 Apr 2024 22:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1714455975; x=1715060775; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=5L+DbHHyg9/U1kdFGH+74R7K4u9DGBrF4s+3873+bY0=; b=d4RggpMx0Pv2fdNVjStUr+ELj97EHcHO8AM6EBtjHg9sN68LFFpBAhUx7YYcIFTpGE ekvFTTbNhzpo6+EpJiCwwuWMQso8ABxIf+lzowIaNGJCCdfFPJK/jM7EUw9LmAMR0C4r dNclGBAN3PDQNKNn6Zdn6Z6jEK+5dFPE0koQM9LZKAvJth9V5duhR6jlLhGYocKhr6D0 i4v8FKgfAYKYWhYDlkCi0MzIyUNPV4sXYDpOW8sybWG2O62kvjSMZ/bY+f6pLFYNQt4K V3bGFhj/veIwL7nRRJyTXoHIZ+ODP0qG836R3NnvI9M4EbCqc5LZ9WN26vggK9JLjJ6/ 73WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714455975; x=1715060775; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5L+DbHHyg9/U1kdFGH+74R7K4u9DGBrF4s+3873+bY0=; b=Dn1rsCLQdEz8RakPDHJXDWV+kRIFOUYNuXJALdlG2Nf/a7C9cY92Bsxq40CFeyBw/V TE5i/tmCnVbboIfE25jqsiW7/fYJLPdsEKq8zVNad9xJ0Uh3BZc2ftkahtkRKI3kl2FY Y/Fu9tfrwYO+FIkN56vgEzMvyioQr1RAd9XbBSg6d1VzpDDtMAgynbjejz9qNXB9T9Bg tfsKwJM8Y3jkYpV/1tQlCBggV1lfvM1vGHsUpX+YVZIyV3nlgMMRcsBSuU5z161zpDIr p5WuGQOR63Wgk0f7FxiRA6gJ8VL1F0M8TME549YF9RZtr6dKgagV5rwRANwE4Wa1j9ZP qlTw== X-Gm-Message-State: AOJu0YwIqkhbh2K6iCiVgB2sqEDIIwV4NTHL+Oe5yZSrF4keLSVRnu9c 7QhzgPM1Ww52/+vjUdr/zMJYcQgayqPs+vC4DKcsP8m58iiNUheZTV6sG1lpF7/4ThWLQS1C4I6 P X-Google-Smtp-Source: AGHT+IGk6XaLGpfuoUdDJFudtbrf8u4lswHLxBXGWN7TmyCvejeVLID4Xr999uOxMPq+1SjKPHPkVQ== X-Received: by 2002:a17:90a:b00b:b0:2ac:5a83:b8b7 with SMTP id x11-20020a17090ab00b00b002ac5a83b8b7mr9438434pjq.0.1714455975083; Mon, 29 Apr 2024 22:46:15 -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 r6-20020a17090a940600b002b2a7c89970sm252533pjo.35.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-00FsCB-1r; Tue, 30 Apr 2024 15:46:12 +1000 Received: from dave by devoid.disaster.area with local (Exim 4.97) (envelope-from ) id 1s1gJg-0000000HUwm-02aA; 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 0/3] mm: fix nested allocation context filtering Date: Tue, 30 Apr 2024 15:28:22 +1000 Message-ID: <20240430054604.4169568-1-david@fromorbit.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 84F3320016 X-Stat-Signature: rh4i8ruo5jpyjb3yk6ychkapmofrtba6 X-Rspam-User: X-HE-Tag: 1714455976-824664 X-HE-Meta: U2FsdGVkX19SPTHPToKI2+TMSyGXTFCDUooRIwj0VV0ep+vBOX4nEipCIr80XTVnG281NKEN0TsRaKt7EyOAQbLzEfot5jn8RZGsplGyJrSwdX9z57cUnv8DRwN/kgnAUpFAjMXQNSjRUQvE+NET2WrfddFvx55kdtYZOnaG7I6ugyqIXio9Fha6/zXNs8jkmFxDtAoJDFgN9rtUjx3vg2kF2vFA9xpJMz+MXFKnbDT6EtGHjSRg4rOTqkuRN/MDu0s/wbgmj4FudG3n0hXQC087HN/YRQUEqI0M64weK2DidFQiVHkJD52IFWRjdJwcPJVI24/8vhv/8IAQQK9IAzDDk8NZYw9viSq/opkD6Bz0AlQdQ6nDG4wLuWG2GDGt8HZpXhCGjcoQzLZVqtiygWIkHVFS6cqq7swuWPq1PunaIbaNG2BwgxgFmz5XS0lWNwqJNDNKRfkNZXR92E2llrXGPgw/C0e5Vk+uI4cx8bQXBREiF78UIOzk/aYZi2pHUcuLd+MEeFL6PaY7Kq2GQAjRF4jX3VzuPHtz0J+K1BgkkZd5GxlJ4Ezw0s5MZL442XeDU66Igt0LYOhbttNQ/5lawleCBjSjjU2T04GR5lxm7efvUQDLeue0CsC8Bc6bLPGhzZAd2GaUXxjT1RGgAtYqOVMuxutfg5vYWnXq4yPEqIziQ3kEFrJwidh7eayi515MyGXIdUlHVjRsFxu0JWSJe5YLNnhvuQPXymFYm6D8c7eiTnNU4GNCZSZuZfbLo5RVBSaXSpNYZDzkXjR0qoiFKEep2TBAou0GfEqmkzuLKlWpZC5KeyXEGqNtMVKGlp7elMNQAsey1QSm22teVUO1gv3tptaEDZqNwedyjdx1cNb8lvjvDYidpwyqCuL4nP9tnYfZ9hQ7bFII4h3f9oRqG8k1ZXdSJ2xzTs/FmSiTWFxughxTpntZrGFrkxgewMqgGhRJ0oapGnOGBjI X3PMYjsC 57TFf+zduRdiUPechqTjV8RbmDjzl39F4DOORjNITTqmv/j17LnGxRoOm6ENnUOgrk8hFYpnnnV14Dx5qrK0J2+aYVbz2n1IJsOv5Faz8zxYL0dra2bnr17Eh34Jzp/9VkVNIlri4o7vXEzjQ7pO65auPDHfF8Bv2EfzusNlDzwBBDJI8yOWlslO+bWAeOAyrGqDRnN4OalT9UCI2MXL5Nbff/q1MJTBdZ5kY3mK+/CBhEMrUGPIQ9Ry2m2rHM8ad2pcXgmlL23RrGqDwczpjup00j2Ws0cX0/jE+CEZ7nD8dR+VqC4NQOP340zPElEsvKHocWjfYUmA/RdLqjp1pyoJotIffck4NofITcqzk9UVTErYs5HHildJcPi+O4hTBnPXSa1llw4cre870kYSbjAOxTO+CcH6UTHG0qpml+Wk81LfNgVlB3sNFvqT4V5FAM6Gwx4l9UmWciP6J8E6yLKG99mwsC98sLmk4 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000468, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This patchset is the followup to the comment I made earlier today: https://lore.kernel.org/linux-xfs/ZjAyIWUzDipofHFJ@dread.disaster.area/ Tl;dr: Memory allocations that are done inside the public memory allocation API need to obey the reclaim recursion constraints placed on the allocation by the original caller, including the "don't track recursion for this allocation" case defined by __GFP_NOLOCKDEP. These nested allocations are generally in debug code that is tracking something about the allocation (kmemleak, KASAN, etc) and so are allocating private kernel objects that only that debug system will use. Neither the page-owner code nor the stack depot code get this right. They also also clear GFP_ZONEMASK as a separate operation, which is completely redundant because the constraint filter applied immediately after guarantees that GFP_ZONEMASK bits are cleared. kmemleak gets this filtering right. It preserves the allocation constraints for deadlock prevention and clears all other context flags whilst also ensuring that the nested allocation will fail quickly, silently and without depleting emergency kernel reserves if there is no memory available. This can be made much more robust, immune to whack-a-mole games and the code greatly simplified by lifting gfp_kmemleak_mask() to include/linux/gfp.h and using that everywhere. Also document it so that there is no excuse for not knowing about it when writing new debug code that nests allocations. Tested with lockdep, KASAN + page_owner=on and kmemleak=on over multiple fstests runs with XFS. Reviewed-by: Christoph Hellwig Reviewed-by: Vlastimil Babka Reviewed-by: Oscar Salvador