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 E006DC05027 for ; Fri, 17 Feb 2023 10:01:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64A376B0072; Fri, 17 Feb 2023 05:01:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F8A66B0073; Fri, 17 Feb 2023 05:01:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C0846B0074; Fri, 17 Feb 2023 05:01:56 -0500 (EST) 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 3AE866B0072 for ; Fri, 17 Feb 2023 05:01:56 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C1388C1656 for ; Fri, 17 Feb 2023 10:01:55 +0000 (UTC) X-FDA: 80476342590.05.EE781AA Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf28.hostedemail.com (Postfix) with ESMTP id 15811C001C for ; Fri, 17 Feb 2023 10:01:52 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="q70CP/QF"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676628113; 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=c8t7WQSrgRYnzbMUfpx5jhJTpcbpl8qDHziyJ4Fw+Sg=; b=38wwCa+j40s4Bs/UkooT5ebZmz2n/11H9YJ8BL/4blbZMkBb9cGn8IeJw6BLFGu2AuIEwk F+0PIiiINlMHO6xcB4sLBqYDG+D54301xk5PKq4wQJx4BTyzKamIOyBefWfiFDYRI4NgRm wHKvrgn9oxpFDsS+xnZq2hobW3fpi7o= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="q70CP/QF"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676628113; a=rsa-sha256; cv=none; b=WOR6hxWoVXWqrlqaw7qAAAQYF/FGk8NNUJWVoZIqopHuYC4MCDUa2lqly8D0liYO1yaR+K SyK53sXIVZqO461jwjEjVJ6lf6j+p4+D0mJjShCjAAbMRhDzPRYtYxDVm4N4yRrVG1kl8d T8KoZ31/CllGZ2p63j1rKlUXJcTZ0tc= Received: by mail-pj1-f48.google.com with SMTP id i10-20020a17090a7e0a00b002341a2656e5so640516pjl.1 for ; Fri, 17 Feb 2023 02:01:52 -0800 (PST) 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:message-id:reply-to; bh=c8t7WQSrgRYnzbMUfpx5jhJTpcbpl8qDHziyJ4Fw+Sg=; b=q70CP/QFgs6PEqGyKgfVEA31Yu5EVz0lkM7E0OfzfZRNasH/nYKuY8/S01CCtQVTEY Z86AYmsAYeqWkmLWlk+ky0Vh7fhXFFsD1WXJCYoxoKNsWDa/9rnsuvdtGgjFi7F23mTA 7oHoOonf9TnLsij+/1GfNIY7m62MRHlwjNPpufMKT28geomKXPPjCfk1GBBXom1w5Jdg m5nHQgRVtoATOcImH8OMOrGxtjv/yehFcdEVy1GY8sqcfqrflK8cauK03L76LhX8lR6V RAqzkvFUX/EE40Loo7UgwATVBfiUZWSGBSZIgqja2U0PJVCmKyNdRk5keXByOsaL0ywK FuRQ== 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:message-id :reply-to; bh=c8t7WQSrgRYnzbMUfpx5jhJTpcbpl8qDHziyJ4Fw+Sg=; b=G+dyqq8NCXXSPLdeAoyKjFoywPQKeNMbyx3q//2zAIx35krPfu5TEc4TcExjK7ioWM I6+eWynbFrIf/9b8n8dOfQjRLmHEpi+bB9TmCh+Yai1AnnUAp4pySypRQTHDSaAsm140 7f51c6UHtRY+Gohz4kx/bz0PxmWGwC94NYZn0224DNhwGA1cWzDaKSEJkND1pHwG0+9L 8Yl07KRmvsNHMzfI+TqywHhk4VYe3mkhd8/EV7aETDz0FXjgk9eJ8BBR7nMJeLrB9QPs Go4LB/79Sf1SaR1IDyvLj7Q0cDknMFuqX9SG9+RbOGdD8v2DfWIoXEw1yNVKq4n0oG+6 Lo6Q== X-Gm-Message-State: AO0yUKVPqIviBecUItYaSuTVejv8QIeG0T1yDCZKFYUlkpKbEYbbbx8P 8EBRxyVwTZNGE/Wa3eP2DL2qBEm6ItDg5DtscTc= X-Google-Smtp-Source: AK7set941QTkqCm3TFzslREr98zlAXZMgvgCqNHyiGIY5qIz8+bgoLo/EMT4lkKeBddDOxdAlC1IMmZZ+3RekZkEKW8= X-Received: by 2002:a17:90b:1f8f:b0:233:3c5a:b41b with SMTP id so15-20020a17090b1f8f00b002333c5ab41bmr1381346pjb.133.1676628112015; Fri, 17 Feb 2023 02:01:52 -0800 (PST) MIME-Version: 1.0 References: <20230214103030.1051950-1-arnd@kernel.org> <20230214114014.4ce0afb658fae97d81f32925@linux-foundation.org> In-Reply-To: <20230214114014.4ce0afb658fae97d81f32925@linux-foundation.org> From: Andrey Konovalov Date: Fri, 17 Feb 2023 11:01:41 +0100 Message-ID: Subject: Re: [PATCH] [RFC] maple_tree: reduce stack usage with gcc-9 and earlier To: Andrew Morton , Arnd Bergmann Cc: "Liam R. Howlett" , Arnd Bergmann , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com, Vernon Yang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 15811C001C X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: xdhaztucpwejhmx8mcxbknbmpp4ccpii X-HE-Tag: 1676628112-98515 X-HE-Meta: U2FsdGVkX1/kENP/ekCLTN6LNgOKYT7O0KiMhp2GO2OLj+DXDIQ+4bGy5t22nKh85G43IZ/wJhEiPOoWgwsyjPnGwDVeuPJP1iRS9+pTyYHxlI8gsI+IwX36C03zqAVnp0VaAW8cVz810/5Y4xfHJ5ecEJiDj6Rx+aJq4QCnrliBtXk6W9wIkwHmoSiHFv9VoqofQx8J+RZ0nEGi/kffoOU1vd+hqRuLDZI5MALE2woSlpz2UWau2Uk6VHqiNTAJBhVLm1JoXwlqh0JbUO136L10UdKZL/V1IcEx5MjvUKnRXskidPW7BMkv2/qCM1M79cb8pN6a0TMYqf6V2RzE3FDxtwIbJf5wbupprgfwRMeRCAbB5BeGFyLz2iNi99XTFlbFFc3kOFbST9UNmQKnP4ucE1eUQp2t7cl/s4q1cmyT9WgQlhikbLzmnY6EoUNuQc27EFx4ID/OUhvdiYM2y6nZ9ZhP2lGO6u8t1/0Wltv7Htm6z5P9GQlJW/a7PdyatwBOfIlK13jCZtgW8L6+e6NLhObw4zMXEwtZmmDeM7BjUlh7h5oYMLt7x25b68FY5kFwltf7XSFF3TTBmaElUHxvbH9iHE4NY8emhmHahR3Ul4bauM5pKikgVHdgs3wGAT9EKRU8n2+fcajQti9FKH2qqtamF8nICD0f9XxVq0k5NoHSvXTCtwjo2cXu/QBixcWAj2IMjSAS92L0XQ6iQTB3Etx1vPP8V9v6605chJQvlWBnrbYuIH5BsbiYbVVe6PI6THz9wNOyEwRL3OVJyxpxxTFuh79MDwEnsO3Fb02ZP7R+xXE4DtWiUznXJc/a0Kk5+lUssEfrSV7tI82oh78EULaAV/9OW4caQdEZ1Iycskku1y4tWLSWAYZe4/kTa8qZ3G+lR3d+cgWvMYgj0T0IwKBMAAFzTy/m7WCbrG8469A7NuQO06yrvGDveyMQ7xCNfFzgQR9ezQQTMxr 8f8l2++b wt3wOPpBiJJTaL1tK1J4RQQLri3CpywIHr2/tmxo/WQ0K6+QbPSTOizHZjpmE+FzyFhVYtuJB6PTE22mcRREWqHS9+uvrfgn2InVDAHzbaaRUvCvC1+/7g6+iwRui/NXKH2qEUdni7L4YVSM30g71IAJX89U7m/gBd4RVg+qxjxx6EJA4pNZokMH34bjJgGzOVMGxe4PKoCp7WtIgLL3T5AVTKWuRaOC72K+9fKeIxftO/dt3SG4T1OHlkfvIk/cH39jXs92bQcF6dLKtlNmgHuqZXyMzQWPsPUK4n7RP/fHQfeujll6RInB+xcbpGvDLkwWfT/TdRV1t9KrgfrIW2R31Fa+jUnV+61XxFLCzkZDxCDJaWVfprrRjTyskxIAAY5eyqyq9z2Jot4z0sYnHjiRb1Zet9pU1WZuksVrLQsoUq9fgehkff6p/acIbUcq016k8ugTwzLSvhGkUaPQhG4eR16CqMfYUpS6Lzx5a1Nyz+0ujK2PWFKEFpSbOS5OOPDVAS9VEkI0vAjwqv104D3DJLzSOAAkxCyUUMVtmYB0r0qrRmuk4uyhtrb2Kj6HYT+UTR/aOUxtLf6A0w3EZieorDfOoqLLDgcJq 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 Tue, Feb 14, 2023 at 8:40 PM Andrew Morton wrote: > > On Tue, 14 Feb 2023 11:30:24 +0100 Arnd Bergmann wrote: > > > From: Arnd Bergmann > > > > gcc-10 changed the way inlining works to be less aggressive, but > > older versions run into an oversized stack frame warning whenever > > CONFIG_KASAN_STACK is enabled, as that forces variables from > > inlined callees to be non-overlapping: > > > > lib/maple_tree.c: In function 'mas_wr_bnode': > > lib/maple_tree.c:4320:1: error: the frame size of 1424 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] > > > > Change the annotations on mas_store_b_node() and mas_commit_b_node() > > to explicitly forbid inlining in this configuration, which is > > the same behavior that newer versions already have. > > > > ... > > > > --- a/lib/maple_tree.c > > +++ b/lib/maple_tree.c > > @@ -146,6 +146,13 @@ struct maple_subtree_state { > > struct maple_big_node *bn; > > }; > > > > +#ifdef CONFIG_KASAN_STACK > > +/* Prevent mas_wr_bnode() from exceeding the stack frame limit */ > > +#define noinline_for_kasan noinline_for_stack > > +#else > > +#define noinline_for_kasan inline > > +#endif > > Should noinline_for_kasan be defined in kasan.h? maple_tree.c is > unlikely to be the only place in the kernel which could use this > treatment? We could also define it in include/linux/compiler_types.h along with other KASAN attributes.