From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF40929A9 for ; Mon, 10 Oct 2022 18:40:40 +0000 (UTC) Received: by mail-pg1-f171.google.com with SMTP id q1so2599463pgl.11 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=a0XdToQnl+B3YU5wfUeD5hxiBdZiGt8SxvPrfyMyhfkuwLkPdVE9oHgGShxBmBsuhh IakiBr0N9Wbn00k4oqXkdp/C44T1di37fa9B5RY5szR4wIt132T22YRrul9rKMHVbSyE Qv/HlO1Cw6KCWYkDRiCJcZ1rh+vmCZkM73kw5YyHPYBZTjsiHaXmUPM56d/QI/RLIodZ rlVKp5hA4yRNQ0bkmbHpWuhIh15UZhj37Fk18Li+iBqbNd0WFsyygqKVJt91t/gapPts jqAn1wMe1x9QBtamLKUhsaqOd63rUeyYpysMtPLdTKJgQ5t2diBQe6S4gzfztyKjh6BG KLJA== X-Gm-Message-State: ACrzQf1OjlncO4uR8ScsRo1e3Mp+1MSXmdj8Ckqx7wNsZUS6FWmEtAD8 odvHNx23bAZJfwyJgD2hPyfzbIT2L1RQW+hUG/YlPg== X-Google-Smtp-Source: AMsMyM6EDBQwGEdbN7Wbm0jiIRVw6lRI/YWSkiDGiSLzkecxw2vOElVi8XDqpQstg5QnBVRXM9TymdvbvkMuf480wKk= 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) Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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" 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