Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1188297rwi; Mon, 10 Oct 2022 12:30:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7SwYrxspFLQ76hLCmXUHtm3l1AXj3B0m0gg/o5jeDJ3d0fNqav8NghCd80gatl/ifHJGvs X-Received: by 2002:a17:906:9756:b0:78b:8c9b:3b1d with SMTP id o22-20020a170906975600b0078b8c9b3b1dmr15424054ejy.256.1665430251044; Mon, 10 Oct 2022 12:30:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665430251; cv=none; d=google.com; s=arc-20160816; b=LMIz4b7eQ0cQky33twz1h6DiVoGaeT5LHEIl+uvSddwaMARDHvXEZfwDidu1jHBeR2 zwlyDBPVM5VP6OROij0+Lc9dtvjfttIgksYYIxC5ptp5VZtHfnRGE0bOkgLVy4UfSBCr PoZt+Vr1bBDRPToz1aadJPrUx6RrmJwb6sn9oO9c4DUt6jwGnXlfn/s0WaEtw7NHKEdr 2UkTL0hHAMHEvrwDKYIwmkd+SDB+5R1uipMk3jp3Zie+wByvAxI5/Q+1j1wc7wgSVgwu CmQEE0dEKueuF0J+kQSHoR+BYs1zk930tp46k1osBEZJI4SB2tE3Ry8E5eiu4F+TDJzR +P0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=73IFEj8UKp21a0lUf+7fHKRgxbCrQEXIzggPWAc8GZk=; b=pgRmR2foOcUAoBA/f2uKMpCd63j9G1awLWeqD+WdnOaDcf2f6yA+UMdJrNCodDl9SK HUBX1S1BZbv3t/lCsVP/GQoRkt7dnrSHhoSY1+ErQak9UQ39BB6Fxflh4VlGSJBsrXWm iWkpO51/uTlQL3/NBYArzbGVLvr/rwe+brzAyvqbPtECp4q0j5/hLnyppcZibXig1+q7 YcxTLe+h4WEcmFjr61PrHqtX5RKcq1uN0BOH0duQZkozwDupFwjfPSxQf7OtLBcm4s/o kMi+laFykWC59z0cWM7NgE4gprfXX+wxVhNaHezNlo6ZYhZDDUKoOYfMsdbKdH241+b1 6o+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="s7kXX/Nz"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f11-20020a0564021e8b00b0044e6b43f044si13690164edf.267.2022.10.10.12.30.24; Mon, 10 Oct 2022 12:30:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="s7kXX/Nz"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229822AbiJJSkw (ORCPT + 99 others); Mon, 10 Oct 2022 14:40:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229800AbiJJSkn (ORCPT ); Mon, 10 Oct 2022 14:40:43 -0400 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1483126106 for ; Mon, 10 Oct 2022 11:40:40 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id l6so1393078pgu.7 for ; Mon, 10 Oct 2022 11:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=73IFEj8UKp21a0lUf+7fHKRgxbCrQEXIzggPWAc8GZk=; b=s7kXX/Nzrao9i8oAWjJPJfckPVhA9J/dx0H9OvPpYn8EN3YVFYh1+K8N8nCs/YRoxb xdBl5kox7WPHUktOMOCjrH8sv6Ibzevz1nG94J5UKZjYoXYej2XtK1sVrgAJu2i1N3lz DeJ8aNpK0+pZxx5AoJb7TSoPl8CNQzRG9Hcj2n5iymm5KMujta82Kk5mytZZ0LozcXH5 aBCWhm1d/e9/LBR7cS96NQ6f9z/GAyOrGyr6/BAHiIhAZ3RZixfHzKNyKZtBdaPJJbnx Xicf+/S5cz+hcjBzR/rbmbt/KCZL8xRGbGFvvNIZUXXer/Vj1cWzy0ZPnSErrz7DmdWm vp8A== 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=73IFEj8UKp21a0lUf+7fHKRgxbCrQEXIzggPWAc8GZk=; b=S44XEEUFPYcucMFK8fLDTfdRFcVtQA3cRmBp7nUmIi0jB416aYUhQPKI7nbQ8hAYqf vDKLK4tRiaMbS627Q8kd6U3kvbLuZExt8huJl4rbdVzle3QhSyNDPqwQlVrHwlxRIaly 8OPKWAkvO5yhcJKJ/G4/NNQfWsYr9fRBWjo4qDYRLvu2k3/HVgNuyo97qF9XVOchpq8+ so13F5TmWKoqBAPwt9BX07cMy7BzvVVvrctVEa28the0FqHfQBpUffjmXm5lr/KAN7yE y96g4UPCYoVqrh1b75G9THeWtbabh9rC3WTyE9uPNU9CMZX/cOkxoABsnd8t5/pe76op N7xA== X-Gm-Message-State: ACrzQf0li7mhWbRKcXor4DR6EIrPzYwylvcsk/8Y8sZtgvMv362C6oO8 tp0qhI6zhNZpjh43KQne7eZ2n7e3tupbhkxKRYCyYw== X-Received: by 2002:aa7:83cd:0:b0:563:5f54:d78c with SMTP id j13-20020aa783cd000000b005635f54d78cmr7096497pfn.66.1665427239975; Mon, 10 Oct 2022 11:40:39 -0700 (PDT) MIME-Version: 1.0 References: <20190307090146.1874906-1-arnd@arndb.de> <20221006222124.aabaemy7ofop7ccz@google.com> In-Reply-To: From: Nick Desaulniers Date: Mon, 10 Oct 2022 11:40:28 -0700 Message-ID: Subject: Re: [PATCH] fs/select: avoid clang stack usage warning To: Arnd Bergmann Cc: Kees Cook , linux-fsdevel@vger.kernel.org, Alexander Viro , Andrew Morton , Andi Kleen , Christoph Hellwig , Eric Dumazet , "Darrick J. Wong" , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Paul Kirth Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 7, 2022 at 3:54 PM Nick Desaulniers wrote: > > This seems to be affected by -fno-conserve-stack, a currently gcc-only > command line flag. If I remove that, then i386 defconfig will inline > do_select but x86_64 defconfig will not. > > I have a sneaking suspicion that -fno-conserve-stack and > -Wframe-larger-than conspire in GCC to avoid inlining when doing so > would trip `-Wframe-larger-than` warnings, but it's just a conspiracy > theory; I haven't read the source. Probably should implement exactly > that behavior in LLVM. Sorry, that should have read `-fconserve-stack` (not `-fno-conserve-stack`). Playing with: https://godbolt.org/z/hE67j1Y9G experimentally, it looks like irrespective of -Wframe-larger-than, -fconserve-stack will try to avoid inlining callees if their frame size is 512B or greater for x86-64 targets, and 410B or greater for 32b targets. aarch64 is 410B though, perhaps that's leftover from the 32b ARM port. There's probably more to the story there though. > I'll triple check 32b+64b arm configs next week to verify. But if GCC > is not inlining do_select into core_sys_select then I think my patch > https://lore.kernel.org/llvm/20221007201140.1744961-1-ndesaulniers@google.com/ > is on the right track; probably could drop the 32b-only condition and > make a note of GCC in the commit message. arm64 does not inline do_select into core_sys_select with aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110 for defconfig. $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make -j128 defconfig fs/select.o $ llvm-objdump -Dr --disassemble-symbols=core_sys_select fs/select.o | grep do_select 1a48: 2e fb ff 97 bl 0x700 Same for 32b ARM. arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110 $ CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm make -j128 defconfig fs/select.o $ llvm-objdump -Dr --disassemble-symbols=core_sys_select fs/select.o | grep do_select 1620: 07 fc ff eb bl #-4068 Is there a set of configs or different compiler version for which that's not the case? Perhaps. But it doesn't look like marking do_select noinline_for_stack changes the default behavior for GCC builds, which is good. So it looks like it's just clang being aggressive with inlining since it doesn't have -fconserve-stack. I think https://lore.kernel.org/lkml/20221007201140.1744961-1-ndesaulniers@google.com/ is still on the right track, though I'd remove the 32b only guard for v2. Christophe mentioned something about KASAN and GCC. I failed to reproduce, and didn't see any reports on lore that seemed relevant. https://lore.kernel.org/lkml/20221010074409.GA20998@lst.de/ I'll wait a day to see if there's more info (a config that reproduces) before sending a v2 though. > Also, my colleague Paul just whipped up a neat tool to help debug > -Wframe-larger-than. > https://reviews.llvm.org/D135488 > See the output from my run here: > https://paste.debian.net/1256338/ > It's a very early WIP, but I think it would be incredibly helpful to > have this, and will probably help us improve Clang's stack usage. Paul also mentioned that -finline-max-stacksize is a thing, at least for clang. https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-finline-max-stacksize Though this only landed recently https://reviews.llvm.org/rG8564e2fea559 and wont ship until clang-16. That feels like a large hammer for core_sys_select/do_select; I think we can use a fine scalpel. But it might be interesting to use that with KASAN. -- Thanks, ~Nick Desaulniers