From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (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 E671F7C for ; Tue, 1 Mar 2022 18:47:47 +0000 (UTC) Received: by mail-ej1-f41.google.com with SMTP id hw13so33271287ejc.9 for ; Tue, 01 Mar 2022 10:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=ZEWbFFu3eWrZxUgaaScwD4ZJ//Z7mV4SGMyACB20WwCKEMFGKIBMMEXVkM4kZXdOyd EokMKBVyAcoYChV/SvtOh5q5h0Yafm3wlsC3jCGOeoM0h4pn550KTbE+/sUn3z3m8p0V ZL0gG9ZTrYCOlyUURTCDAGrluijISoqXbB1wA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=l2IxwN2q767Me+n6bfZ0LFKd9RjWTSo/GAcd6Qr8Ax/lU/I3b2uLGMZ2T/uhXhP+Rw tPdikGiljaGvmbfXDNHreIEkg28FW/pCovdekbxvCmc98PrxhBZWDoA6kTZvbnZnG4q3 GwScq5jpG80RHgJirZxqnwwfW7ZNEhTa5F9pyFTVAB3oewbWZ1dcV41rZanHyNj1qvgf 9rthZHdmtolhfonrxKS3mwUpWVykTUx6HtUBynWx6UIDuXW8oUfmDhiRoec1eKt8qRlT LQGDdAd8E6DaF6PDtNY5XEOZ5IpxsN6YtBJn5GQfTgtN6NqW9noKDQrpm7IjtlXUewlK oInw== X-Gm-Message-State: AOAM5336pI/UrtOMIQLiilyYEK+2iHni8kt7j1spQu14JPYr25lp0jzk qq88F+Yrk50RtPDYLxRZQ2vRO2AFuGwJki/Eicg= X-Google-Smtp-Source: ABdhPJw1x0pvXiJ6ZreEMWzOJh1tjLD9pseF8XzLYAkfTiWQ1FDQt16spNwIhu+bY2ZHngBsv5r8CQ== X-Received: by 2002:a17:906:9f21:b0:6b6:1f07:fb86 with SMTP id fy33-20020a1709069f2100b006b61f07fb86mr20010050ejc.495.1646160465900; Tue, 01 Mar 2022 10:47:45 -0800 (PST) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id l5-20020a170906644500b006ce6b73ffd2sm5558415ejn.84.2022.03.01.10.47.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 10:47:43 -0800 (PST) Received: by mail-ej1-f51.google.com with SMTP id qk11so33400898ejb.2 for ; Tue, 01 Mar 2022 10:47:41 -0800 (PST) X-Received: by 2002:a05:6512:2033:b0:443:3d49:dac with SMTP id s19-20020a056512203300b004433d490dacmr16440784lfs.52.1646160451271; Tue, 01 Mar 2022 10:47:31 -0800 (PST) Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> <202203011008.AA0B5A2D@keescook> In-Reply-To: <202203011008.AA0B5A2D@keescook> From: Linus Torvalds Date: Tue, 1 Mar 2022 10:47:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr To: Kees Cook Cc: Matthew Wilcox , =?UTF-8?Q?Christian_K=C3=B6nig?= , Jakob Koschel , alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, "Gustavo A. R. Silva" , linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel , Cristiano Giuffrida , amd-gfx list , samba-technical@lists.samba.org, linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , KVM list , linux-scsi , linux-rdma , linux-staging@lists.linux.dev, "Bos, H.J." , Jason Gunthorpe , intel-wired-lan@lists.osuosl.org, kgdb-bugreport@lists.sourceforge.net, bcm-kernel-feedback-list@broadcom.com, Dan Carpenter , Linux Media Mailing List , Arnd Bergman , Linux PM , intel-gfx , Brian Johannesmeyer , Nathan Chancellor , linux-fsdevel , Christophe JAILLET , v9fs-developer@lists.sourceforge.net, linux-tegra , Thomas Gleixner , Andy Shevchenko , Linux ARM , linux-sgx@vger.kernel.org, linux-block , Netdev , linux-usb@vger.kernel.org, linux-wireless , Linux Kernel Mailing List , Linux F2FS Dev Mailing List , tipc-discussion@lists.sourceforge.net, Linux Crypto Mailing List , dma , linux-mediatek@lists.infradead.org, Andrew Morton , linuxppc-dev , Mike Rapoport Content-Type: text/plain; charset="UTF-8" On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a disaster". You looked into the details. > Another way to try to catch misused shadow variables is > -Wunused-but-set-varible, but it, too, has tons of false positives. That on the face of it should be an easy warning to get technically right for a compiler. So I assume the "false positives" are simply because we end up having various variables that really don't end up being used - and "intentionally" so). Or rather, they might only be used under some config option - perhaps the use is even syntactically there and parsed, but the compiler notices that it's turned off under some if (IS_ENABLED(..)) option? Because yeah, we have a lot of those. I think that's a common theme with a lot of compiler warnings: on the face of it they sound "obviously sane" and nobody should ever write code like that. A conditional that is always true? Sounds idiotic, and sounds like a reasonable thing for a compiler to warn about, since why would you have a conditional in the first place for that? But then you realize that maybe the conditional is a build config option, and "always true" suddenly makes sense. Or it's a test for something that is always true on _that_architecture_ but not in some general sense (ie testing "sizeof()"). Or it's a purely syntactic conditional, like "do { } while (0)". It's why I'm often so down on a lot of the odd warnings that are hiding under W=1 and friends. They all may make sense in the trivial case ("That is insane") but then in the end they happen for sane code. And yeah, -Wshadow has had tons of history with macro nesting, and just being badly done in the first place (eg "strlen" can be a perfectly fine local variable). That said, maybe people could ask the gcc and clan people for a way to _mark_ the places where we expect to validly see shadowing. For example, that "local variable in a macro expression statement" thing is absolutely horrendous to fix with preprocessor tricks to try to make for unique identifiers. But I think it would be much more syntactically reasonable to add (for example) a "shadow" attribute to such a variable exactly to tell the compiler "yeah, yeah, I know this identifier could shadow an outer one" and turn it off that way. Linus 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 110EBC433EF for ; Tue, 1 Mar 2022 18:47:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dmhmrR8TLkjNRr8haIojjP8b0dVkU9abZbpmNU+xNLw=; b=ld8mRAghVjkcl4 0Ycr3eC4opdqnbsn9j8hR8Iv58RY0E2OrCvMb+xxJQs/J3FtpUbOshqQtI4WnMh22L7jdw8EMLVlA vO+d86+2Bss2gxeJBhOplEN7zZZL+zsGx2oQl6EP8V5PdhJgNohKbkxqCkpY37UanvDxu2zE+5RW4 OQkO/RIXS1kABdxFzLwd6OvMC/p66KTuJIyEtqfRatV3Pus55m6X6tb2z5uHJ8SMiG2y+lRK6SnT9 mgmrtbsHl+KbHiZ5hN3yPKEQJlweSfqQceTi4t+Yud5yXQJMAk00gCUm2JuhRUIhysm8UwowxU7aP ZKUwst4EB2m/2m0xgcmA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nP7XL-000Cwi-B5; Tue, 01 Mar 2022 18:47:51 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nP7XI-000Cw5-BI for linux-mediatek@lists.infradead.org; Tue, 01 Mar 2022 18:47:49 +0000 Received: by mail-ej1-x635.google.com with SMTP id p14so33290845ejf.11 for ; Tue, 01 Mar 2022 10:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=ZEWbFFu3eWrZxUgaaScwD4ZJ//Z7mV4SGMyACB20WwCKEMFGKIBMMEXVkM4kZXdOyd EokMKBVyAcoYChV/SvtOh5q5h0Yafm3wlsC3jCGOeoM0h4pn550KTbE+/sUn3z3m8p0V ZL0gG9ZTrYCOlyUURTCDAGrluijISoqXbB1wA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=wzPj//PUpWgEclkPIBHVY6a2DZRQ+osZiGvphPMQd4iyexLY3HzPkUJ/V8EyaNHAO9 Pv3gZHl7d3vn5cRKb1/ZA6ATYBVU9NfZ+xfmCy/3f+j7pdi9KTfeOnnF6z3EieSWbRlB 7vMOl6Ym+E5dYL2B0ZGXQN+l9gwPr8jpTerJQuVchP1TLYlcJHi51VHDgyEuCsawDH9Y S7DTdGlLQ25DIiiW9VaQpuaR6k4x/UAFFTu18oPpQLTCpgWymy+3Qo9GfYyzx7hTzL9I 8dkZmzfobwal0JMFLxWY1wVw/koeCjd/tNLpzLGow7MBJ+MgHK9HIVOZvbE1IZRQEC+f M8vw== X-Gm-Message-State: AOAM532i46tgi3jBZB4BiwUc82Iji5ZsZ1wPw+P7IUPkrTizw+SevB3w bb6berGmnPezxsxohWa2j7/ssXNYtQ4EWLXKVzI= X-Google-Smtp-Source: ABdhPJwGeDAQLPj9reDNM7R2OipzweJnGhZ2pS6s/8f0yk+9oVEBvBHYGCGsT2dCNlnf9kno8BvKbQ== X-Received: by 2002:a17:906:7d83:b0:6ce:fee:9256 with SMTP id v3-20020a1709067d8300b006ce0fee9256mr20754510ejo.647.1646160466945; Tue, 01 Mar 2022 10:47:46 -0800 (PST) Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com. [209.85.218.46]) by smtp.gmail.com with ESMTPSA id bo14-20020a170906d04e00b006ce98d9c3e3sm5588564ejb.194.2022.03.01.10.47.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 10:47:43 -0800 (PST) Received: by mail-ej1-f46.google.com with SMTP id p14so33290422ejf.11 for ; Tue, 01 Mar 2022 10:47:42 -0800 (PST) X-Received: by 2002:a05:6512:2033:b0:443:3d49:dac with SMTP id s19-20020a056512203300b004433d490dacmr16440784lfs.52.1646160451271; Tue, 01 Mar 2022 10:47:31 -0800 (PST) MIME-Version: 1.0 References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> <202203011008.AA0B5A2D@keescook> In-Reply-To: <202203011008.AA0B5A2D@keescook> From: Linus Torvalds Date: Tue, 1 Mar 2022 10:47:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr To: Kees Cook Cc: Matthew Wilcox , =?UTF-8?Q?Christian_K=C3=B6nig?= , Jakob Koschel , alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, "Gustavo A. R. Silva" , linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel , Cristiano Giuffrida , amd-gfx list , samba-technical@lists.samba.org, linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , KVM list , linux-scsi , linux-rdma , linux-staging@lists.linux.dev, "Bos, H.J." , Jason Gunthorpe , intel-wired-lan@lists.osuosl.org, kgdb-bugreport@lists.sourceforge.net, bcm-kernel-feedback-list@broadcom.com, Dan Carpenter , Linux Media Mailing List , Arnd Bergman , Linux PM , intel-gfx , Brian Johannesmeyer , Nathan Chancellor , linux-fsdevel , Christophe JAILLET , v9fs-developer@lists.sourceforge.net, linux-tegra , Thomas Gleixner , Andy Shevchenko , Linux ARM , linux-sgx@vger.kernel.org, linux-block , Netdev , linux-usb@vger.kernel.org, linux-wireless , Linux Kernel Mailing List , Linux F2FS Dev Mailing List , tipc-discussion@lists.sourceforge.net, Linux Crypto Mailing List , dma , linux-mediatek@lists.infradead.org, Andrew Morton , linuxppc-dev , Mike Rapoport X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220301_104748_399083_4887CD93 X-CRM114-Status: GOOD ( 21.22 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a disaster". You looked into the details. > Another way to try to catch misused shadow variables is > -Wunused-but-set-varible, but it, too, has tons of false positives. That on the face of it should be an easy warning to get technically right for a compiler. So I assume the "false positives" are simply because we end up having various variables that really don't end up being used - and "intentionally" so). Or rather, they might only be used under some config option - perhaps the use is even syntactically there and parsed, but the compiler notices that it's turned off under some if (IS_ENABLED(..)) option? Because yeah, we have a lot of those. I think that's a common theme with a lot of compiler warnings: on the face of it they sound "obviously sane" and nobody should ever write code like that. A conditional that is always true? Sounds idiotic, and sounds like a reasonable thing for a compiler to warn about, since why would you have a conditional in the first place for that? But then you realize that maybe the conditional is a build config option, and "always true" suddenly makes sense. Or it's a test for something that is always true on _that_architecture_ but not in some general sense (ie testing "sizeof()"). Or it's a purely syntactic conditional, like "do { } while (0)". It's why I'm often so down on a lot of the odd warnings that are hiding under W=1 and friends. They all may make sense in the trivial case ("That is insane") but then in the end they happen for sane code. And yeah, -Wshadow has had tons of history with macro nesting, and just being badly done in the first place (eg "strlen" can be a perfectly fine local variable). That said, maybe people could ask the gcc and clan people for a way to _mark_ the places where we expect to validly see shadowing. For example, that "local variable in a macro expression statement" thing is absolutely horrendous to fix with preprocessor tricks to try to make for unique identifiers. But I think it would be much more syntactically reasonable to add (for example) a "shadow" attribute to such a variable exactly to tell the compiler "yeah, yeah, I know this identifier could shadow an outer one" and turn it off that way. Linus _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1EF99C433EF for ; Wed, 2 Mar 2022 08:59:39 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 53F272049; Wed, 2 Mar 2022 09:58:47 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 53F272049 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1646211577; bh=zCR9gf3HIAG85JliOWZi3a4EI6obxZJzCE+9lk48Yq4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=QUIi24PHR02oXhRDEC5FPeL22L1zqnkDFLxXQ7ABosXlkKCaeTx8liIcmCyzbS3kp xQZ0R5qOht3H9pepuwAY06YHEeykVN/StG8b9D78yN0NNU5jAbjNUIJpkU7+37s9Ry NTysJxHa/EGF9tPm66S4Kj5KHdjTsY+SxQ0HZYuk= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 4C309F80846; Wed, 2 Mar 2022 09:34:31 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 9E5D9F80227; Tue, 1 Mar 2022 19:53:52 +0100 (CET) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 5F244F80054 for ; Tue, 1 Mar 2022 19:53:44 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 5F244F80054 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="ZEWbFFu3" Received: by mail-lf1-x12e.google.com with SMTP id y24so28483318lfg.1 for ; Tue, 01 Mar 2022 10:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=ZEWbFFu3eWrZxUgaaScwD4ZJ//Z7mV4SGMyACB20WwCKEMFGKIBMMEXVkM4kZXdOyd EokMKBVyAcoYChV/SvtOh5q5h0Yafm3wlsC3jCGOeoM0h4pn550KTbE+/sUn3z3m8p0V ZL0gG9ZTrYCOlyUURTCDAGrluijISoqXbB1wA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=udTzpq7pb3ujprmxGhHCvt6oqVGXsc477S0TPH8ArGbZbhMnbzJ2QeEUk8Yg65jA6W +PECOLoMb4AUDhXtHa9OIraZyQp4wkqvkaUF8fIKCsVKrcmQWfG1GpN07IZEZEnTaZFu FYcf9+U+xhWRwDIyn2qu9MlFd8mKKEqxw0EFDm/er0GaUQoWGNFr8NKBs49vZaxJMv++ lfgX6JqL0wcj+RuizMVb+rWlinLHQQBRI118zUG92CjqF1cGr4A6CJYGCOsdXDWxu0u0 wInovI864jl9WDamNi9YlE7imrvf6fcDKkD0zdCIzvfnPWTLbfErTv7SsdTelKvxtL4X +wkQ== X-Gm-Message-State: AOAM532VRfLr8+F3jnizTmHBNWuD3KMVkNu1mya8o4k5V+Rh2OJpm6qk K/FrH5zhO4wTKlovJfvlTpS6I99h7AB2ZUjN6Hc= X-Google-Smtp-Source: ABdhPJyqAcbA+N2+2u2rctn1h9W/xKCZMgpleT7t8//dkufaMjEHta9altUhHE2XBF6oe58tuONeLA== X-Received: by 2002:a19:710a:0:b0:443:ad21:dcc0 with SMTP id m10-20020a19710a000000b00443ad21dcc0mr16434424lfc.688.1646160822428; Tue, 01 Mar 2022 10:53:42 -0800 (PST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id p1-20020a05651238c100b004437b4e5034sm1620797lft.159.2022.03.01.10.53.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 10:53:42 -0800 (PST) Received: by mail-lj1-f178.google.com with SMTP id y24so4109629ljh.11 for ; Tue, 01 Mar 2022 10:53:42 -0800 (PST) X-Received: by 2002:a05:6512:2033:b0:443:3d49:dac with SMTP id s19-20020a056512203300b004433d490dacmr16440784lfs.52.1646160451271; Tue, 01 Mar 2022 10:47:31 -0800 (PST) MIME-Version: 1.0 References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> <202203011008.AA0B5A2D@keescook> In-Reply-To: <202203011008.AA0B5A2D@keescook> From: Linus Torvalds Date: Tue, 1 Mar 2022 10:47:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr To: Kees Cook Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Wed, 02 Mar 2022 09:33:36 +0100 Cc: linux-wireless , alsa-devel@alsa-project.org, KVM list , "Gustavo A. R. Silva" , linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel , Cristiano Giuffrida , Matthew Wilcox , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , Andy Shevchenko , linux-aspeed@lists.ozlabs.org, linux-scsi , linux-rdma , linux-staging@lists.linux.dev, amd-gfx list , Jason Gunthorpe , intel-wired-lan@lists.osuosl.org, kgdb-bugreport@lists.sourceforge.net, bcm-kernel-feedback-list@broadcom.com, Dan Carpenter , Linux Media Mailing List , Arnd Bergman , Linux PM , intel-gfx , "Bos, H.J." , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , v9fs-developer@lists.sourceforge.net, linux-tegra , Thomas Gleixner , Brian Johannesmeyer , Linux ARM , linux-sgx@vger.kernel.org, linux-block , Netdev , linux-usb@vger.kernel.org, samba-technical@lists.samba.org, Linux Kernel Mailing List , Linux F2FS Dev Mailing List , tipc-discussion@lists.sourceforge.net, Linux Crypto Mailing List , linux-fsdevel , linux-mediatek@lists.infradead.org, Andrew Morton , linuxppc-dev , =?UTF-8?Q?Christian_K=C3=B6nig?= , Mike Rapoport X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a disaster". You looked into the details. > Another way to try to catch misused shadow variables is > -Wunused-but-set-varible, but it, too, has tons of false positives. That on the face of it should be an easy warning to get technically right for a compiler. So I assume the "false positives" are simply because we end up having various variables that really don't end up being used - and "intentionally" so). Or rather, they might only be used under some config option - perhaps the use is even syntactically there and parsed, but the compiler notices that it's turned off under some if (IS_ENABLED(..)) option? Because yeah, we have a lot of those. I think that's a common theme with a lot of compiler warnings: on the face of it they sound "obviously sane" and nobody should ever write code like that. A conditional that is always true? Sounds idiotic, and sounds like a reasonable thing for a compiler to warn about, since why would you have a conditional in the first place for that? But then you realize that maybe the conditional is a build config option, and "always true" suddenly makes sense. Or it's a test for something that is always true on _that_architecture_ but not in some general sense (ie testing "sizeof()"). Or it's a purely syntactic conditional, like "do { } while (0)". It's why I'm often so down on a lot of the odd warnings that are hiding under W=1 and friends. They all may make sense in the trivial case ("That is insane") but then in the end they happen for sane code. And yeah, -Wshadow has had tons of history with macro nesting, and just being badly done in the first place (eg "strlen" can be a perfectly fine local variable). That said, maybe people could ask the gcc and clan people for a way to _mark_ the places where we expect to validly see shadowing. For example, that "local variable in a macro expression statement" thing is absolutely horrendous to fix with preprocessor tricks to try to make for unique identifiers. But I think it would be much more syntactically reasonable to add (for example) a "shadow" attribute to such a variable exactly to tell the compiler "yeah, yeah, I know this identifier could shadow an outer one" and turn it off that way. Linus 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9DBBAC433EF for ; Tue, 1 Mar 2022 18:47:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EF45310E750; Tue, 1 Mar 2022 18:47:45 +0000 (UTC) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4241D10E750 for ; Tue, 1 Mar 2022 18:47:45 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id s24so23256999edr.5 for ; Tue, 01 Mar 2022 10:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=ZEWbFFu3eWrZxUgaaScwD4ZJ//Z7mV4SGMyACB20WwCKEMFGKIBMMEXVkM4kZXdOyd EokMKBVyAcoYChV/SvtOh5q5h0Yafm3wlsC3jCGOeoM0h4pn550KTbE+/sUn3z3m8p0V ZL0gG9ZTrYCOlyUURTCDAGrluijISoqXbB1wA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=s2cLh73HkcofjybAiqj3mebIk3KvzfV1gWphRbO6f7Es0gU8X7bQiqu2IckTg5f263 DPhrY+9regTlPFhwXFj7cAwrFQRiLiEmtDjDWUVmfAQsehZ5YVxo//BE2P9zSifGCxPp EJ4LDhRXwSQTYfBIrnfz6UG18HUlcXB6g6Y5Wf0RG4NVlPUTaXp/IjQyLrRie1OP9uA+ K5yL8Bxr9W7eImAZgrhfo+/2t3gXVkcaI6bLUsssD3FrGMdu3VYkighTjvj2qxPyxzqT g7flzDgrEUn+JWXSv2dA3/m1XJSOfPmTx5hURbx2rK0uByjQ/JRsBtVCkPgmbFI+pJAe prqQ== X-Gm-Message-State: AOAM532SKDccDJ92Jlf4nP6dMfCSjbf7OcLpYoBbN0Sq4pdSFnw5lgS6 BHOz1C9nAGonZoDIhhMy9IKEYUqjni2QIescWJk= X-Google-Smtp-Source: ABdhPJw4FnrxbR7nQ698/PF3iiWDBIA0RzTgvWoHG4sgfzS17h7BxfWh0VscsfhgcBvyZ3j9xQH2jA== X-Received: by 2002:a05:6402:374:b0:413:9b28:2a2c with SMTP id s20-20020a056402037400b004139b282a2cmr15618839edw.83.1646160463499; Tue, 01 Mar 2022 10:47:43 -0800 (PST) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id w14-20020a170906d20e00b006cee22553f7sm5572811ejz.213.2022.03.01.10.47.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 10:47:43 -0800 (PST) Received: by mail-ej1-f48.google.com with SMTP id a23so33330916eju.3 for ; Tue, 01 Mar 2022 10:47:41 -0800 (PST) X-Received: by 2002:a05:6512:2033:b0:443:3d49:dac with SMTP id s19-20020a056512203300b004433d490dacmr16440784lfs.52.1646160451271; Tue, 01 Mar 2022 10:47:31 -0800 (PST) MIME-Version: 1.0 References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> <202203011008.AA0B5A2D@keescook> In-Reply-To: <202203011008.AA0B5A2D@keescook> From: Linus Torvalds Date: Tue, 1 Mar 2022 10:47:14 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Kees Cook Content-Type: text/plain; charset="UTF-8" Subject: Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-wireless , alsa-devel@alsa-project.org, KVM list , "Gustavo A. R. Silva" , linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel , Cristiano Giuffrida , Matthew Wilcox , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , Andy Shevchenko , linux-aspeed@lists.ozlabs.org, linux-scsi , linux-rdma , linux-staging@lists.linux.dev, amd-gfx list , Jason Gunthorpe , intel-wired-lan@lists.osuosl.org, kgdb-bugreport@lists.sourceforge.net, bcm-kernel-feedback-list@broadcom.com, Dan Carpenter , Linux Media Mailing List , Arnd Bergman , Linux PM , intel-gfx , "Bos, H.J." , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , v9fs-developer@lists.sourceforge.net, linux-tegra , Thomas Gleixner , Brian Johannesmeyer , Linux ARM , linux-sgx@vger.kernel.org, linux-block , Netdev , linux-usb@vger.kernel.org, samba-technical@lists.samba.org, Linux Kernel Mailing List , Linux F2FS Dev Mailing List , tipc-discussion@lists.sourceforge.net, Linux Crypto Mailing List , linux-fsdevel , linux-mediatek@lists.infradead.org, Andrew Morton , linuxppc-dev , =?UTF-8?Q?Christian_K=C3=B6nig?= , Mike Rapoport Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a disaster". You looked into the details. > Another way to try to catch misused shadow variables is > -Wunused-but-set-varible, but it, too, has tons of false positives. That on the face of it should be an easy warning to get technically right for a compiler. So I assume the "false positives" are simply because we end up having various variables that really don't end up being used - and "intentionally" so). Or rather, they might only be used under some config option - perhaps the use is even syntactically there and parsed, but the compiler notices that it's turned off under some if (IS_ENABLED(..)) option? Because yeah, we have a lot of those. I think that's a common theme with a lot of compiler warnings: on the face of it they sound "obviously sane" and nobody should ever write code like that. A conditional that is always true? Sounds idiotic, and sounds like a reasonable thing for a compiler to warn about, since why would you have a conditional in the first place for that? But then you realize that maybe the conditional is a build config option, and "always true" suddenly makes sense. Or it's a test for something that is always true on _that_architecture_ but not in some general sense (ie testing "sizeof()"). Or it's a purely syntactic conditional, like "do { } while (0)". It's why I'm often so down on a lot of the odd warnings that are hiding under W=1 and friends. They all may make sense in the trivial case ("That is insane") but then in the end they happen for sane code. And yeah, -Wshadow has had tons of history with macro nesting, and just being badly done in the first place (eg "strlen" can be a perfectly fine local variable). That said, maybe people could ask the gcc and clan people for a way to _mark_ the places where we expect to validly see shadowing. For example, that "local variable in a macro expression statement" thing is absolutely horrendous to fix with preprocessor tricks to try to make for unique identifiers. But I think it would be much more syntactically reasonable to add (for example) a "shadow" attribute to such a variable exactly to tell the compiler "yeah, yeah, I know this identifier could shadow an outer one" and turn it off that way. Linus 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0A142C433EF for ; Tue, 1 Mar 2022 18:55:12 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nP7eT-0001Un-C1; Tue, 01 Mar 2022 18:55:12 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nP7eR-0001Uf-D6 for linux-f2fs-devel@lists.sourceforge.net; Tue, 01 Mar 2022 18:55:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=Z5oJsZ6OHdLmg7UhXoZtcHSF5b ia03QN3m+QbKZ9jrgvyizBa7SHZyL7s1pRg+ZDwzh/NSdLFMJmihHU5CUgmE1/zZnOjsA6Hjiq8cw HarKo++00iBy0w9vdMR9OUThwvQn8YDyz8KldQaMreXU1EX+6fofszFAxPlkjECEnqHY=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=H4M27cW+1uJCSR4iW0vflzk0/7 LMayafBdkfnlo5VAL2ZyOYYwCl2FzK6nkfu33VyT6r7VocLh6/s3SHu9OwtIdgFDqzbBKpyVp4fdb PolIGdN1lq9WMFM4VW/tq0lkC6zEo1+jNe8gaQd3nrBEcKEB1WgiaDPdnPB03/uqGlEw=; Received: from mail-ej1-f50.google.com ([209.85.218.50]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.94.2) id 1nP7eP-001bKr-8Y for linux-f2fs-devel@lists.sourceforge.net; Tue, 01 Mar 2022 18:55:09 +0000 Received: by mail-ej1-f50.google.com with SMTP id qk11so33438000ejb.2 for ; Tue, 01 Mar 2022 10:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=ZEWbFFu3eWrZxUgaaScwD4ZJ//Z7mV4SGMyACB20WwCKEMFGKIBMMEXVkM4kZXdOyd EokMKBVyAcoYChV/SvtOh5q5h0Yafm3wlsC3jCGOeoM0h4pn550KTbE+/sUn3z3m8p0V ZL0gG9ZTrYCOlyUURTCDAGrluijISoqXbB1wA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=NfiI/O5YDNfAtKqemmvkOFO6/Urbxd8yaOfzXXzxBMFeZtwo9pByEwIDdWt4noSdew c14YhR3bIeFa2GNgGdMfJlju8+G0TBoo4xUXUpmmx1b/s5nn3P4/kJ+JSK4NM1SYeyGf ySTVhcbi9BRAbtua/Ao9eQq2OvyzajUh192TIcTJ4dcexr1NBjtIaU5/Se8wdX3+MjJ0 vG2Mixlnztc/rttxw3BbQsRhK31khK3XmhoLiVEkLUd3FCwyXZeC/yF2MZkPD6bYyKJ2 eIr6fRzL+f/DtVpN5eosqhX8iyNG1Kw+aGsOjM4D1m+VqZ4YaIjYoSV07RUuzYc9dOxe 2aMw== X-Gm-Message-State: AOAM5300R9f0flysu9yB2GekFU8Tj5SLs8UO895Wg5wjwx+cpoYDtzen hj+YVSK0XcfQ19sNxkLyfYBKAmXlgDjfqrU3g/g= X-Google-Smtp-Source: ABdhPJzj3mu0H2/rwl6P0cnJZzp33UYJdQH4nL7jmf1NWHDH5/Tdjhy9L5BOpXrKHDhoTUQ4FMGWhw== X-Received: by 2002:a17:906:fa02:b0:6ce:78fb:2b94 with SMTP id lo2-20020a170906fa0200b006ce78fb2b94mr19725070ejb.396.1646160900823; Tue, 01 Mar 2022 10:55:00 -0800 (PST) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com. [209.85.218.52]) by smtp.gmail.com with ESMTPSA id co19-20020a0564020c1300b00412879e4645sm7452177edb.55.2022.03.01.10.55.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 10:55:00 -0800 (PST) Received: by mail-ej1-f52.google.com with SMTP id qk11so33437901ejb.2 for ; Tue, 01 Mar 2022 10:55:00 -0800 (PST) X-Received: by 2002:a05:6512:2033:b0:443:3d49:dac with SMTP id s19-20020a056512203300b004433d490dacmr16440784lfs.52.1646160451271; Tue, 01 Mar 2022 10:47:31 -0800 (PST) MIME-Version: 1.0 References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> <202203011008.AA0B5A2D@keescook> In-Reply-To: <202203011008.AA0B5A2D@keescook> From: Linus Torvalds Date: Tue, 1 Mar 2022 10:47:14 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Kees Cook X-Headers-End: 1nP7eP-001bKr-8Y Subject: Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-wireless , alsa-devel@alsa-project.org, KVM list , "Gustavo A. R. Silva" , linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel , Cristiano Giuffrida , Matthew Wilcox , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , Andy Shevchenko , linux-aspeed@lists.ozlabs.org, linux-scsi , linux-rdma , linux-staging@lists.linux.dev, amd-gfx list , Jason Gunthorpe , intel-wired-lan@lists.osuosl.org, kgdb-bugreport@lists.sourceforge.net, bcm-kernel-feedback-list@broadcom.com, Dan Carpenter , Linux Media Mailing List , Arnd Bergman , Linux PM , intel-gfx , "Bos, H.J." , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , v9fs-developer@lists.sourceforge.net, linux-tegra , Thomas Gleixner , Brian Johannesmeyer , Linux ARM , linux-sgx@vger.kernel.org, linux-block , Netdev , linux-usb@vger.kernel.org, samba-technical@lists.samba.org, Linux Kernel Mailing List , Linux F2FS Dev Mailing List , tipc-discussion@lists.sourceforge.net, Linux Crypto Mailing List , linux-fsdevel , linux-mediatek@lists.infradead.org, Andrew Morton , linuxppc-dev , =?UTF-8?Q?Christian_K=C3=B6nig?= , Mike Rapoport Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a disaster". You looked into the details. > Another way to try to catch misused shadow variables is > -Wunused-but-set-varible, but it, too, has tons of false positives. That on the face of it should be an easy warning to get technically right for a compiler. So I assume the "false positives" are simply because we end up having various variables that really don't end up being used - and "intentionally" so). Or rather, they might only be used under some config option - perhaps the use is even syntactically there and parsed, but the compiler notices that it's turned off under some if (IS_ENABLED(..)) option? Because yeah, we have a lot of those. I think that's a common theme with a lot of compiler warnings: on the face of it they sound "obviously sane" and nobody should ever write code like that. A conditional that is always true? Sounds idiotic, and sounds like a reasonable thing for a compiler to warn about, since why would you have a conditional in the first place for that? But then you realize that maybe the conditional is a build config option, and "always true" suddenly makes sense. Or it's a test for something that is always true on _that_architecture_ but not in some general sense (ie testing "sizeof()"). Or it's a purely syntactic conditional, like "do { } while (0)". It's why I'm often so down on a lot of the odd warnings that are hiding under W=1 and friends. They all may make sense in the trivial case ("That is insane") but then in the end they happen for sane code. And yeah, -Wshadow has had tons of history with macro nesting, and just being badly done in the first place (eg "strlen" can be a perfectly fine local variable). That said, maybe people could ask the gcc and clan people for a way to _mark_ the places where we expect to validly see shadowing. For example, that "local variable in a macro expression statement" thing is absolutely horrendous to fix with preprocessor tricks to try to make for unique identifiers. But I think it would be much more syntactically reasonable to add (for example) a "shadow" attribute to such a variable exactly to tell the compiler "yeah, yeah, I know this identifier could shadow an outer one" and turn it off that way. Linus _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E5DF5C433F5 for ; Wed, 2 Mar 2022 04:57:40 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 135E010EAC3; Wed, 2 Mar 2022 04:57:28 +0000 (UTC) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1389510E72F for ; Tue, 1 Mar 2022 18:54:52 +0000 (UTC) Received: by mail-lj1-x236.google.com with SMTP id 29so23073698ljv.10 for ; Tue, 01 Mar 2022 10:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=ZEWbFFu3eWrZxUgaaScwD4ZJ//Z7mV4SGMyACB20WwCKEMFGKIBMMEXVkM4kZXdOyd EokMKBVyAcoYChV/SvtOh5q5h0Yafm3wlsC3jCGOeoM0h4pn550KTbE+/sUn3z3m8p0V ZL0gG9ZTrYCOlyUURTCDAGrluijISoqXbB1wA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZw99KMpsKBs3Ab/LBNeIPMebXALTITXobBfJpN/EsI=; b=xl2Nzsfno0SGMDjSyLY9mIbvCczCzlMQLnSI0SNnxvidBKtz9DKtBCIGxPSy/dOXDs Id6xps8xzXdPZbyvAL0FuXwX271sU0xD92VUmOhuUxTa+P4VdkjpK5U2kvBQZVGQuYUo qN+MnMIoBRACbs7/o/x+D4G7zduOePGt/i56llMqnpTc18TG1ju6gAAERTO6Yyn4eBLW nCI91CdJqtKVfz94Z+NRMSmGIM/FIkHYvmFj4ng0j7Ui9n7OrJCNm5SdCWgSwxYzmvjZ 5zSq0NYvMWXVLw+mIs0w+r3ze4OZX+K2lFIRuBr96eMUKS8EZWDnvYEQn2oDJ8AZ6Kxc Vkgw== X-Gm-Message-State: AOAM532RdnT3iwIZMnez+zBha8jzk1zFpH6tYrBn4ikhhVEWq7SNKPOZ qYqIDs8oEfng9PEX0JNndkm1UV+KpM8SEXJgbek= X-Google-Smtp-Source: ABdhPJxyfqd6tEXagRa/A0+XiuBbwf7k6pMrvBVyQ1y7RmnrXxWaFNJa8ZYQe5WyDpc8U50fJPN66Q== X-Received: by 2002:a05:651c:178a:b0:231:22f4:23f with SMTP id bn10-20020a05651c178a00b0023122f4023fmr17726365ljb.466.1646160890092; Tue, 01 Mar 2022 10:54:50 -0800 (PST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id a19-20020a2e88d3000000b00246585ccd51sm2114870ljk.14.2022.03.01.10.54.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 10:54:49 -0800 (PST) Received: by mail-lf1-f54.google.com with SMTP id m14so28466556lfu.4 for ; Tue, 01 Mar 2022 10:54:49 -0800 (PST) X-Received: by 2002:a05:6512:2033:b0:443:3d49:dac with SMTP id s19-20020a056512203300b004433d490dacmr16440784lfs.52.1646160451271; Tue, 01 Mar 2022 10:47:31 -0800 (PST) MIME-Version: 1.0 References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> <202203011008.AA0B5A2D@keescook> In-Reply-To: <202203011008.AA0B5A2D@keescook> From: Linus Torvalds Date: Tue, 1 Mar 2022 10:47:14 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Kees Cook Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Wed, 02 Mar 2022 04:57:26 +0000 Subject: Re: [Nouveau] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-wireless , alsa-devel@alsa-project.org, KVM list , "Gustavo A. R. Silva" , linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel , Cristiano Giuffrida , Matthew Wilcox , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , Andy Shevchenko , linux-aspeed@lists.ozlabs.org, linux-scsi , linux-rdma , linux-staging@lists.linux.dev, amd-gfx list , Jason Gunthorpe , intel-wired-lan@lists.osuosl.org, kgdb-bugreport@lists.sourceforge.net, bcm-kernel-feedback-list@broadcom.com, Dan Carpenter , Linux Media Mailing List , Arnd Bergman , Linux PM , intel-gfx , "Bos, H.J." , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , v9fs-developer@lists.sourceforge.net, linux-tegra , Thomas Gleixner , Brian Johannesmeyer , Linux ARM , linux-sgx@vger.kernel.org, linux-block , Netdev , linux-usb@vger.kernel.org, samba-technical@lists.samba.org, Linux Kernel Mailing List , Linux F2FS Dev Mailing List , tipc-discussion@lists.sourceforge.net, Linux Crypto Mailing List , linux-fsdevel , linux-mediatek@lists.infradead.org, Andrew Morton , linuxppc-dev , =?UTF-8?Q?Christian_K=C3=B6nig?= , Mike Rapoport Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a disaster". You looked into the details. > Another way to try to catch misused shadow variables is > -Wunused-but-set-varible, but it, too, has tons of false positives. That on the face of it should be an easy warning to get technically right for a compiler. So I assume the "false positives" are simply because we end up having various variables that really don't end up being used - and "intentionally" so). Or rather, they might only be used under some config option - perhaps the use is even syntactically there and parsed, but the compiler notices that it's turned off under some if (IS_ENABLED(..)) option? Because yeah, we have a lot of those. I think that's a common theme with a lot of compiler warnings: on the face of it they sound "obviously sane" and nobody should ever write code like that. A conditional that is always true? Sounds idiotic, and sounds like a reasonable thing for a compiler to warn about, since why would you have a conditional in the first place for that? But then you realize that maybe the conditional is a build config option, and "always true" suddenly makes sense. Or it's a test for something that is always true on _that_architecture_ but not in some general sense (ie testing "sizeof()"). Or it's a purely syntactic conditional, like "do { } while (0)". It's why I'm often so down on a lot of the odd warnings that are hiding under W=1 and friends. They all may make sense in the trivial case ("That is insane") but then in the end they happen for sane code. And yeah, -Wshadow has had tons of history with macro nesting, and just being badly done in the first place (eg "strlen" can be a perfectly fine local variable). That said, maybe people could ask the gcc and clan people for a way to _mark_ the places where we expect to validly see shadowing. For example, that "local variable in a macro expression statement" thing is absolutely horrendous to fix with preprocessor tricks to try to make for unique identifiers. But I think it would be much more syntactically reasonable to add (for example) a "shadow" attribute to such a variable exactly to tell the compiler "yeah, yeah, I know this identifier could shadow an outer one" and turn it off that way. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Date: Tue, 1 Mar 2022 10:47:14 -0800 Subject: [Intel-wired-lan] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr In-Reply-To: <202203011008.AA0B5A2D@keescook> References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> <202203011008.AA0B5A2D@keescook> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a disaster". You looked into the details. > Another way to try to catch misused shadow variables is > -Wunused-but-set-varible, but it, too, has tons of false positives. That on the face of it should be an easy warning to get technically right for a compiler. So I assume the "false positives" are simply because we end up having various variables that really don't end up being used - and "intentionally" so). Or rather, they might only be used under some config option - perhaps the use is even syntactically there and parsed, but the compiler notices that it's turned off under some if (IS_ENABLED(..)) option? Because yeah, we have a lot of those. I think that's a common theme with a lot of compiler warnings: on the face of it they sound "obviously sane" and nobody should ever write code like that. A conditional that is always true? Sounds idiotic, and sounds like a reasonable thing for a compiler to warn about, since why would you have a conditional in the first place for that? But then you realize that maybe the conditional is a build config option, and "always true" suddenly makes sense. Or it's a test for something that is always true on _that_architecture_ but not in some general sense (ie testing "sizeof()"). Or it's a purely syntactic conditional, like "do { } while (0)". It's why I'm often so down on a lot of the odd warnings that are hiding under W=1 and friends. They all may make sense in the trivial case ("That is insane") but then in the end they happen for sane code. And yeah, -Wshadow has had tons of history with macro nesting, and just being badly done in the first place (eg "strlen" can be a perfectly fine local variable). That said, maybe people could ask the gcc and clan people for a way to _mark_ the places where we expect to validly see shadowing. For example, that "local variable in a macro expression statement" thing is absolutely horrendous to fix with preprocessor tricks to try to make for unique identifiers. But I think it would be much more syntactically reasonable to add (for example) a "shadow" attribute to such a variable exactly to tell the compiler "yeah, yeah, I know this identifier could shadow an outer one" and turn it off that way. Linus