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 260E3EB64D9 for ; Wed, 14 Jun 2023 20:28:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2AB86B0074; Wed, 14 Jun 2023 16:28:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DB286B0075; Wed, 14 Jun 2023 16:28:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A3216B0078; Wed, 14 Jun 2023 16:28:02 -0400 (EDT) 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 7D5316B0074 for ; Wed, 14 Jun 2023 16:28:02 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4571DC07A4 for ; Wed, 14 Jun 2023 20:28:02 +0000 (UTC) X-FDA: 80902490004.10.BC4EBF7 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf08.hostedemail.com (Postfix) with ESMTP id 84420160012 for ; Wed, 14 Jun 2023 20:27:59 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=1Dp95kTj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of ndesaulniers@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=ndesaulniers@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686774479; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kimLIYWPOvzs4k2x7Iocr5Znn/T70aABOYbrugGGfHk=; b=FEZWbHOScxTnPWdk4V+LqpZDaL0JBQqQjk9zgHPUYc3mtd6x4QmAS8hz7oUCeScxkSpjgc fDctM5u8+XpjziJsr8M1Ma8wT59wE8wQskONviivPfcLpj6prjYth+hxV0k3SING/gt2uN rVOxRh+H7ksh1lt7qouQLrM6fktDtyE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=1Dp95kTj; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of ndesaulniers@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=ndesaulniers@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686774479; a=rsa-sha256; cv=none; b=G6xeVBE/uN+tCQR3CwZye0m5zDHkc7Wgn3yH6oKPr9CrE2wAcopzIrYp6piQJPwvOGUz9J GlXRgeflIwRZwk+JxZC22XjkBpCnmxM6uyby1HEyueZXdTqxc+VeJ2EY/oPx2y0L9huCeC B+5+01Yg409X24lVe0WI8kVNXvKV5Lk= Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-62dee1b51f9so510426d6.1 for ; Wed, 14 Jun 2023 13:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686774478; x=1689366478; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kimLIYWPOvzs4k2x7Iocr5Znn/T70aABOYbrugGGfHk=; b=1Dp95kTjoBgw5soGCnXEj5PVJ6JaMLGi2nMWtU3y4lJXt/E0oBA57JOFvEur5abN9G /h1JgUgo4ExdPrbtD1+VINTEzbAsmENDcwvFunWnDCyWxHOOVP8Myu34ou4unGSmhQPG QIpKgJJHxQ/JFZGzff9JsQfURNfLROVmZv9gBDoLXr2bFf1BHB2CDsdNKFsH9XqHB9ig wPD4mqR+Bh2stXDXR9XGEVOoQJJpAgs76OvLjUNqtnV2Sl7c9Qyt+kx5eE0ZU28neurQ pMaksSioupfoOYZWx9pkzPP1AEK254YXDgmmvTSAbq8boRAuFjnuBC1ZY1NpwywDKJCv V9+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686774478; x=1689366478; h=content-transfer-encoding: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=kimLIYWPOvzs4k2x7Iocr5Znn/T70aABOYbrugGGfHk=; b=JXjDydynjaijCr212oypfSAvTNbEqQWy7SioU3UJjcPkJ/2uFmGaPumE4IQK7ZhfXO WlKj8WC1ysFUht+aXEzvwNbQv42NYDvx/fQe42sHuj4J9y+RRGaQ7lTJyvQHOxxRbBs2 LyHyVjgHJs8IP8giSX+9+HWaweiZ39m4fcon0dqGkQ4iv+tR+wixwvfzpks8uUy2OKsI zL5yxdk3WvobijnQ0jiUyC6N4HRbETUNwTJ0H0FDFJ+D1tM5cODURDvP7ApXTRHyfZH7 D4d+5Aq7i5sqkhRsucTobi8GHlVMFU+WVjedJi8RS3DgEL3Z/mrmkuu6PfMmZB43GoUv qFiA== X-Gm-Message-State: AC+VfDxaC0vtZzPmXP9cyGn/f05YuS4xVFzVoPhrPYLAGw0uzkuyDpkt 3muaeUWhID4EkokM3Zd/r//GD9HtSj4h8IX9js0pOw== X-Google-Smtp-Source: ACHHUZ7ay8BwIAHN3FlqdH3RTUmegJtrBYKRwr5TaPYYT2JLfVoH8FJtYQ8A89LRAaOeARNe1NIR4/MB8+6wMGmCs0o= X-Received: by 2002:ad4:5c81:0:b0:62d:e3d7:5b7a with SMTP id o1-20020ad45c81000000b0062de3d75b7amr3409806qvh.11.1686774478425; Wed, 14 Jun 2023 13:27:58 -0700 (PDT) MIME-Version: 1.0 References: <202306100035.VTusNhm4-lkp@intel.com> <202306131418.35B5D649DC@keescook> In-Reply-To: <202306131418.35B5D649DC@keescook> From: Nick Desaulniers Date: Wed, 14 Jun 2023 16:27:46 -0400 Message-ID: Subject: Re: [linux-next:master 3357/8413] drivers/scsi/FlashPoint.c:1712:12: warning: stack frame size (1056) exceeds limit (1024) in 'FlashPoint_HandleInterrupt' To: Kees Cook Cc: kernel test robot , llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev, Linux Memory Management List , "Gustavo A. R. Silva" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 84420160012 X-Stat-Signature: 1pc898nrs78nj35qujrx7giedbahk34p X-HE-Tag: 1686774479-418381 X-HE-Meta: U2FsdGVkX1+ZMA/FVaa2d3zic15qfm+yB2FqbwW+PH0Yp8PmjSFHaRBHHFXMDudG3ZNWVXxZ1yemj0aShPLPKM+3jwFjhtdrL9R5i5vf4zjvAitQXQsM8Hl4be+6OT+yOpVC0TRIKNKt67nfz1yGHliwvhpn9rF62O5TVBQlZAIbNn3Wu0W4QCYbw+VopXii1J5e3EpzHN6nInHktepqgGlZVqorfiDLBSpcsdCBYLWwZIvnSSgrdjYd9lXJ22miPqKvz3x7KsFz7TP+6qMwgAHLe8eEo0/kAkHnmzo8XjsFW5he0Aqg7r25/3IRcSubbmjTani738WyO8ku9Eokz1Ob+F45JHk+jBz2iWuM+Ws0pd7SBQnKN1VUXCozct1eNYaY2qr+X96c77/L6YZLjpS3aj6cds0D4BpVpEmJSbPaB1KiXxYR+z7eMeLeo6C+fpoCsTBd/SLorr8kRWuEha6XJFAaRx28Xcbtyz2z2i1NEv4lhcvGiH7YWhnGUQ4RY3Qugm4QnmBy7VpQztDjY++eKaDARhhwP/8YTLg41L0acH9vEDCf44IUmaullRj/NdgHmEA8bqlfG7Cnct56k96n3+3Tk4HBZ7LTFFjLoSMGTQCbmjXsR0cH+2sA9rsGtMwyh4el06Y8kPrpVwLxrVwhMLgw8647tguOt0xkYqISoGhRQktFdobUikv4ztxBg/LlSF+kEI3ImYB1P+Q8249nFi1UhD/H2evnlZlfQf0hewcsXFiRrvF/pB2RZxSaPZMipOVkLu8AxpJsSIFRGSOL39W8ao5+cDN1dOrrz/DbxK1XPSeZIo6aYQtnmjfXJaCoX6GS1Ylylo2TkSWYEen6g5X0uJt4EU2k2AR8nEMG54gEKdpJLXzrfI+hWiLDYd1AecyIFGuZyr4hpbO5RX8uLMiLnFKGtyh+HkEKDc1Cavg70Y8t0zh+LtLMtfo/CyaiwlgXE+587uqh8NF s3kUcQxU Dh4mLNipsg/fEor2GTUClJ94F4cRDyXVsseyK1ItEy0+OSGGHAcHj2TVi5GYbpKr8DlHvC5efsaTQS+LySyqtlL3EQiVnET6DsJW8yyQvZ8peiNYGFIK4nzQ7SUVO7YxjYlACaSX7k5RrVB2atzYMF3ZCodibR83xvp738FF1sTyGZ7OixS+dQcLYYSsoJfnRFTFWWSKPMKKTfHOqCf4iTwaaTsAWlccFoLTCeUNRrYLrD4IoOE2hn8flnIgVUbM6cMvmhQjVLXZtTH3HP2BCXlOHaTJY7I0FV/nNOufP8TFbBunh5dFh0WFxB1tgvtN5jUeeU3eFo80QcxeVsT+7WUUl70MgfmnO1lmYL+Ysi2YAqFcGHntNYVtS5fdD7rLnIXDhCtOkMQWjih1nkNs3K+XS96nU6/tC60l4kpuues/MN9dsUbnqiXON3o6r8+Du0saNEAkwHeWQcKqwqnY7mAnNgTDUeOA0BgiNj+fPMbgX0Qpn/7TVxTie80uXVkI8CeXViV2HToQVLjRSlFnD7pRxfkNaxfta42jReusDVOiH/7E= 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, Jun 13, 2023 at 5:22=E2=80=AFPM Kees Cook w= rote: > > On Sat, Jun 10, 2023 at 12:58:23AM +0800, kernel test robot wrote: > > First bad commit (maybe !=3D root cause): > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next= .git master > > head: 53ab6975c12d1ad86c599a8927e8c698b144d669 > > commit: df8fc4e934c12b906d08050d7779f292b9c5c6b5 [3357/8413] kbuild: En= able -fstrict-flex-arrays=3D3 > > config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/2= 0230610/202306100035.VTusNhm4-lkp@intel.com/config) ^ I just checked this config. CONFIG_KASAN=3Dy is not set, so this is not a case of https://github.com/ClangBuiltLinux/linux/issues/39 UBSAN is though (maybe a red herring) as well as GCOV and TSAN/KCSAN. Disabling GCOV did not change the stack usage from allmodconfig. Disable KCSAN dropped it down from 2272 to 2160. Disabling UBSAN produced no warnings, and changed the inlining behavior such that FlashPoint_HandleInterrupt only uses 656B rather than 2272 via allmodconfig. Seems specific to: ``` CONFIG_UBSAN=3Dy CONFIG_CC_HAS_UBSAN_ARRAY_BOUNDS=3Dy CONFIG_UBSAN_BOUNDS=3Dy CONFIG_UBSAN_ARRAY_BOUNDS=3Dy # CONFIG_UBSAN_SHIFT is not set # CONFIG_UBSAN_UNREACHABLE is not set # CONFIG_UBSAN_BOOL is not set # CONFIG_UBSAN_ENUM is not set CONFIG_UBSAN_SANITIZE_ALL=3Dy ``` but adding these on top of powernv_defconfig I couldn't reproduce. So perhaps we can do a config bisection between allmodconfig and powernv_defconfig to see what combination of configs in allmodconfig is causing this to blow up. > > compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.gi= t 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a) > > reproduce (this is a W=3D1 build): > > mkdir -p ~/bin > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/s= bin/make.cross -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # install powerpc cross compiling tool for clang build > > # apt-get install binutils-powerpc-linux-gnu > > # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-ne= xt.git/commit/?id=3Ddf8fc4e934c12b906d08050d7779f292b9c5c6b5 > > git remote add linux-next https://git.kernel.org/pub/scm/linux/= kernel/git/next/linux-next.git > > git fetch --no-tags linux-next master > > git checkout df8fc4e934c12b906d08050d7779f292b9c5c6b5 > > # save the config file > > mkdir build_dir && cp config build_dir/.config > > COMPILER_INSTALL_PATH=3D$HOME/0day COMPILER=3Dclang ~/bin/make.= cross W=3D1 O=3Dbuild_dir ARCH=3Dpowerpc olddefconfig > > COMPILER_INSTALL_PATH=3D$HOME/0day COMPILER=3Dclang ~/bin/make.= cross W=3D1 O=3Dbuild_dir ARCH=3Dpowerpc SHELL=3D/bin/bash drivers/ > > > > If you fix the issue in a separate patch/commit (i.e. not just a new ve= rsion of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot > > | Closes: https://lore.kernel.org/oe-kbuild-all/202306100035.VTusNhm4-l= kp@intel.com/ > > > > All warnings (new ones prefixed by >>): > > > > In file included from drivers/scsi/BusLogic.c:51: > > >> drivers/scsi/FlashPoint.c:1712:12: warning: stack frame size (1056) = exceeds limit (1024) in 'FlashPoint_HandleInterrupt' [-Wframe-larger-than] > > 1712 | static int FlashPoint_HandleInterrupt(void *pcard) > > | ^ > > 1 warning generated. > > I wasn't able to generate the warning with my Clang, but it sure is > close! Building with KCFLAGS=3D-Rpass-analysis=3Dstack-frame-layout I see= : > > > In file included from ../drivers/scsi/BusLogic.c:51: > ../drivers/scsi/FlashPoint.c:1713:1: remark: > Function: FlashPoint_HandleInterrupt > Offset: [SP-4], Type: Protector, Align: 4, Size: 4 > Offset: [SP-8], Type: Spill, Align: 8, Size: 4 > Offset: [SP-12], Type: Spill, Align: 4, Size: 4 > Offset: [SP-16], Type: Spill, Align: 16, Size: 4 Perhaps alignment 16B for a 4B variable leads to excessive padding? Perhaps this config changes the alignment of a type? No, looks like most spills are the 4B w/ 4B alignment and the 16B alignment spills are insignificant. > Offset: [SP-20], Type: Spill, Align: 4, Size: 4 > Offset: [SP-24], Type: Spill, Align: 8, Size: 4 > Offset: [SP-28], Type: Spill, Align: 4, Size: 4 > Offset: [SP-32], Type: Spill, Align: 16, Size: 4 > Offset: [SP-36], Type: Spill, Align: 4, Size: 4 > Offset: [SP-40], Type: Spill, Align: 8, Size: 4 > Offset: [SP-44], Type: Spill, Align: 4, Size: 4 > Offset: [SP-48], Type: Spill, Align: 16, Size: 4 > Offset: [SP-52], Type: Spill, Align: 4, Size: 4 > Offset: [SP-56], Type: Spill, Align: 8, Size: 4 > Offset: [SP-60], Type: Spill, Align: 4, Size: 4 > Offset: [SP-64], Type: Spill, Align: 16, Size: 4 > Offset: [SP-68], Type: Spill, Align: 4, Size: 4 > Offset: [SP-72], Type: Spill, Align: 8, Size: 4 > Offset: [SP-76], Type: Variable, Align: 4, Size: 4 > Offset: [SP-80], Type: Spill, Align: 4, Size: 4 > Offset: [SP-84], Type: Spill, Align: 4, Size: 4 > ...[4 byte spills]... > Offset: [SP-1012], Type: Variable, Align: 4, Size: 4 > Offset: [SP-1016], Type: Variable, Align: 4, Size: 4 > [-Rpass-analysis=3Dstack-frame-layout] > > So something is very weird in FlashPoint_HandleInterrupt -- it has a > single while loop with an internal if/else if/.../else chain. So I don't > see why it would need such extensive spills... > > This seems like a missed optimization in Clang, maybe? > > -- > Kees Cook > --=20 Thanks, ~Nick Desaulniers