From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.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 2495A15D3 for ; Mon, 28 Feb 2022 19:56:26 +0000 (UTC) Received: by mail-lj1-f171.google.com with SMTP id u7so18907388ljk.13 for ; Mon, 28 Feb 2022 11:56:25 -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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=Tm2RrZZp9rg85Q2lAdsba4a3IH+hQMy5xZCbUizCCXmPzyfZ+2VRqEslWXZB4tPt3B Xz8lYe63CHEdQCuWSaPC9nNMhFWrnR54Ihwd0u2qPZVZ4zvhHacXKCw+SJS4BR1PfT62 xCFGBc0xrmrOEo0QPHvZeTHUhXNuWYmty+udI= 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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=mJ9EYM0Eciul5M4nFwOCTpDySUau8vQBhwz5XIdlMTPHswCWFaesMIpBAC76id1YHR YQ4LUHtBy8t3o8q4D3njqbKUx35p+I91M1m8OCbglVoWaatQEn4IogU2sEieEbnQR616 tYxBPQ0rivyiyQA7ItnFpzN8qX0yUegGuNfRHukdYx39oMTmz70H29EVcCHC8d/WWhaI GuF++siqfKvdm6or65WusJf5W+OAk9t4/Y417juMKK+XD7+ZYirq04EEQWmDenaA8nfB 2QKjd/Dcb1S00LQ5/Mtxk6zUwiBpl3S9s67yfswjL/5HuCJANpCc9U7n1HNa8k531Uew STrg== X-Gm-Message-State: AOAM532HFfZqiJGlUpNhsNqZDZsfkO9FQu4fj2IeENxgRVQQAhoyR+f3 6ZgUiZSqChWe8j003GS3xJvigsEhuXu4BsshWtw= X-Google-Smtp-Source: ABdhPJxVQD3HsG+13frV2pJgvnm2OZo4Rd5ljChAhqCGXH30YTB8uoY9tZLnzqrbuy+dxHnWvP8wzw== X-Received: by 2002:a05:651c:50a:b0:246:74cb:2222 with SMTP id o10-20020a05651c050a00b0024674cb2222mr11826718ljp.484.1646078184107; Mon, 28 Feb 2022 11:56:24 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id g27-20020ac2539b000000b00443900fca7bsm1113593lfh.120.2022.02.28.11.56.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 11:56:24 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id b9so23280602lfv.7 for ; Mon, 28 Feb 2022 11:56:23 -0800 (PST) X-Received: by 2002:ac2:5313:0:b0:443:99c1:7e89 with SMTP id c19-20020ac25313000000b0044399c17e89mr13183568lfh.531.1646078183366; Mon, 28 Feb 2022 11:56:23 -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> In-Reply-To: <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> From: Linus Torvalds Date: Mon, 28 Feb 2022 11:56:07 -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: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: 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 , Kees Cook , 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: multipart/mixed; boundary="00000000000064a3e305d91971a9" --00000000000064a3e305d91971a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 28, 2022 at 4:19 AM Christian K=C3=B6nig wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=3Dgnu11" that was discussed in the original thread). That will guarantee that the 'pos' parameter of list_for_each_entry() is only updated INSIDE the for_each_list_entry() loop, and can never point to the (wrongly typed) head entry. And I would actually hope that it should actually cause compiler warnings about possibly uninitialized variables if people then use the 'pos' pointer outside the loop. Except (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for inexplicable reasons - possibly because it already expected this behavior (b) when I remove that NULL initializer, I still don't get a warning, because we've disabled -Wno-maybe-uninitialized since it results in so many false positives. Oh well. Anyway, give this patch a look, and at least if it's expanded to do "(pos) =3D NULL" in the entry statement for the for-loop, it will avoid the HEAD type confusion that Jakob is working on. And I think in a cleaner way than the horrid games he plays. (But it won't avoid possible CPU speculation of such type confusion. That, in my opinion, is a completely different issue) I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it. Anybody have any ideas? Linus --00000000000064a3e305d91971a9 Content-Type: application/octet-stream; name=p Content-Disposition: attachment; filename=p Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l073sb6w0 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvbGlzdC5oIGIvaW5jbHVkZS9saW51eC9saXN0LmgK aW5kZXggZGQ2YzIwNDFkMDljLi5iYWI5OTU1OTZhYWEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGlu dXgvbGlzdC5oCisrKyBiL2luY2x1ZGUvbGludXgvbGlzdC5oCkBAIC02MzQsMTAgKzYzNCwxMCBA QCBzdGF0aWMgaW5saW5lIHZvaWQgbGlzdF9zcGxpY2VfdGFpbF9pbml0KHN0cnVjdCBsaXN0X2hl YWQgKmxpc3QsCiAgKiBAaGVhZDoJdGhlIGhlYWQgZm9yIHlvdXIgbGlzdC4KICAqIEBtZW1iZXI6 CXRoZSBuYW1lIG9mIHRoZSBsaXN0X2hlYWQgd2l0aGluIHRoZSBzdHJ1Y3QuCiAgKi8KLSNkZWZp bmUgbGlzdF9mb3JfZWFjaF9lbnRyeShwb3MsIGhlYWQsIG1lbWJlcikJCQkJXAotCWZvciAocG9z ID0gbGlzdF9maXJzdF9lbnRyeShoZWFkLCB0eXBlb2YoKnBvcyksIG1lbWJlcik7CVwKLQkgICAg ICFsaXN0X2VudHJ5X2lzX2hlYWQocG9zLCBoZWFkLCBtZW1iZXIpOwkJCVwKLQkgICAgIHBvcyA9 IGxpc3RfbmV4dF9lbnRyeShwb3MsIG1lbWJlcikpCisjZGVmaW5lIGxpc3RfZm9yX2VhY2hfZW50 cnkocG9zLCBoZWFkLCBtZW1iZXIpCQkJCQlcCisJZm9yICh0eXBlb2YocG9zKSBfX2l0ZXIgPSBs aXN0X2ZpcnN0X2VudHJ5KGhlYWQsIHR5cGVvZigqcG9zKSwgbWVtYmVyKTsJXAorCSAgICAgIWxp c3RfZW50cnlfaXNfaGVhZChfX2l0ZXIsIGhlYWQsIG1lbWJlcikgJiYgKCgocG9zKT1fX2l0ZXIp LDEpOwlcCisJICAgICBfX2l0ZXIgPSBsaXN0X25leHRfZW50cnkoX19pdGVyLCBtZW1iZXIpKQog CiAvKioKICAqIGxpc3RfZm9yX2VhY2hfZW50cnlfcmV2ZXJzZSAtIGl0ZXJhdGUgYmFja3dhcmRz IG92ZXIgbGlzdCBvZiBnaXZlbiB0eXBlLgo= --00000000000064a3e305d91971a9-- 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.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 8357EC433EF for ; Mon, 28 Feb 2022 19:57:21 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4K6rkk5bhpz3bk2 for ; Tue, 1 Mar 2022 06:57:18 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=linux-foundation.org header.i=@linux-foundation.org header.a=rsa-sha256 header.s=google header.b=Tm2RrZZp; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=2a00:1450:4864:20::536; helo=mail-ed1-x536.google.com; envelope-from=torvalds@linuxfoundation.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linux-foundation.org header.i=@linux-foundation.org header.a=rsa-sha256 header.s=google header.b=Tm2RrZZp; dkim-atps=neutral Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4K6rjz4ywzz2yK2 for ; Tue, 1 Mar 2022 06:56:37 +1100 (AEDT) Received: by mail-ed1-x536.google.com with SMTP id s1so19111109edd.13 for ; Mon, 28 Feb 2022 11:56:38 -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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=Tm2RrZZp9rg85Q2lAdsba4a3IH+hQMy5xZCbUizCCXmPzyfZ+2VRqEslWXZB4tPt3B Xz8lYe63CHEdQCuWSaPC9nNMhFWrnR54Ihwd0u2qPZVZ4zvhHacXKCw+SJS4BR1PfT62 xCFGBc0xrmrOEo0QPHvZeTHUhXNuWYmty+udI= 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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=fDBuChevCQmfkASIQPTrce8s1IGJAC0DqKKfrg7ADvQ4/PTbiOxRKC69oylL4C0WVm vRkBJ4kU4ric2G2VkFyyvxTQHiMatML5reM+07Y5HpVei/pQ0uPA3Lhju72ooNk3Jwtb dfkcdtAYVnZdMaFI22vccdzT4/zX/h3TGclzl/gQQiORIIhCzcToB98n01Ux1PBsf9jM vranDhKH6hZUIEoTWnvFEmjjy/c6/7+z+lbdMjw6OCKGNmwtaDU6Mbmy+uw83D7L/azJ dAzYLoM1SmEtZ0YIw6yBiMb2Kx6NXIM+XJCPpaNpdp408T6hX2t/tEC4OCB0w4QpNKXa EyOQ== X-Gm-Message-State: AOAM5316uwjtG7174+G/st91zdx4dxe7FsIylQy8u+zBlK5U9tpjtbdX Ukee/0ARZJQEAVBaLohZvr9A05oPtTIdovyyyBc= X-Google-Smtp-Source: ABdhPJyQmrMEh1CvqXBJysT20KfRJNXO5C0nVnXT/WQrjhOu+z0bnYy4ItRz7xTpEkIA+q6IxK8h6Q== X-Received: by 2002:aa7:dbd6:0:b0:408:4a31:97a5 with SMTP id v22-20020aa7dbd6000000b004084a3197a5mr21640974edt.186.1646078194268; Mon, 28 Feb 2022 11:56:34 -0800 (PST) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id u10-20020a50d94a000000b004131aa2525esm6518148edj.49.2022.02.28.11.56.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 11:56:34 -0800 (PST) Received: by mail-ej1-f45.google.com with SMTP id qa43so503882ejc.12 for ; Mon, 28 Feb 2022 11:56:33 -0800 (PST) X-Received: by 2002:ac2:5313:0:b0:443:99c1:7e89 with SMTP id c19-20020ac25313000000b0044399c17e89mr13183568lfh.531.1646078183366; Mon, 28 Feb 2022 11:56:23 -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> In-Reply-To: <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> From: Linus Torvalds Date: Mon, 28 Feb 2022 11:56:07 -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: =?UTF-8?Q?Christian_K=C3=B6nig?= Content-Type: multipart/mixed; boundary="00000000000064a3e305d91971a9" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail 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 , "Bos, H.J." , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , 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 , Kees Cook , Arnd Bergman , Linux PM , intel-gfx , Brian Johannesmeyer , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , 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, 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 , Mike Rapoport Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" --00000000000064a3e305d91971a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 28, 2022 at 4:19 AM Christian K=C3=B6nig wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=3Dgnu11" that was discussed in the original thread). That will guarantee that the 'pos' parameter of list_for_each_entry() is only updated INSIDE the for_each_list_entry() loop, and can never point to the (wrongly typed) head entry. And I would actually hope that it should actually cause compiler warnings about possibly uninitialized variables if people then use the 'pos' pointer outside the loop. Except (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for inexplicable reasons - possibly because it already expected this behavior (b) when I remove that NULL initializer, I still don't get a warning, because we've disabled -Wno-maybe-uninitialized since it results in so many false positives. Oh well. Anyway, give this patch a look, and at least if it's expanded to do "(pos) =3D NULL" in the entry statement for the for-loop, it will avoid the HEAD type confusion that Jakob is working on. And I think in a cleaner way than the horrid games he plays. (But it won't avoid possible CPU speculation of such type confusion. That, in my opinion, is a completely different issue) I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it. Anybody have any ideas? Linus --00000000000064a3e305d91971a9 Content-Type: application/octet-stream; name=p Content-Disposition: attachment; filename=p Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l073sb6w0 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvbGlzdC5oIGIvaW5jbHVkZS9saW51eC9saXN0LmgK aW5kZXggZGQ2YzIwNDFkMDljLi5iYWI5OTU1OTZhYWEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGlu dXgvbGlzdC5oCisrKyBiL2luY2x1ZGUvbGludXgvbGlzdC5oCkBAIC02MzQsMTAgKzYzNCwxMCBA QCBzdGF0aWMgaW5saW5lIHZvaWQgbGlzdF9zcGxpY2VfdGFpbF9pbml0KHN0cnVjdCBsaXN0X2hl YWQgKmxpc3QsCiAgKiBAaGVhZDoJdGhlIGhlYWQgZm9yIHlvdXIgbGlzdC4KICAqIEBtZW1iZXI6 CXRoZSBuYW1lIG9mIHRoZSBsaXN0X2hlYWQgd2l0aGluIHRoZSBzdHJ1Y3QuCiAgKi8KLSNkZWZp bmUgbGlzdF9mb3JfZWFjaF9lbnRyeShwb3MsIGhlYWQsIG1lbWJlcikJCQkJXAotCWZvciAocG9z ID0gbGlzdF9maXJzdF9lbnRyeShoZWFkLCB0eXBlb2YoKnBvcyksIG1lbWJlcik7CVwKLQkgICAg ICFsaXN0X2VudHJ5X2lzX2hlYWQocG9zLCBoZWFkLCBtZW1iZXIpOwkJCVwKLQkgICAgIHBvcyA9 IGxpc3RfbmV4dF9lbnRyeShwb3MsIG1lbWJlcikpCisjZGVmaW5lIGxpc3RfZm9yX2VhY2hfZW50 cnkocG9zLCBoZWFkLCBtZW1iZXIpCQkJCQlcCisJZm9yICh0eXBlb2YocG9zKSBfX2l0ZXIgPSBs aXN0X2ZpcnN0X2VudHJ5KGhlYWQsIHR5cGVvZigqcG9zKSwgbWVtYmVyKTsJXAorCSAgICAgIWxp c3RfZW50cnlfaXNfaGVhZChfX2l0ZXIsIGhlYWQsIG1lbWJlcikgJiYgKCgocG9zKT1fX2l0ZXIp LDEpOwlcCisJICAgICBfX2l0ZXIgPSBsaXN0X25leHRfZW50cnkoX19pdGVyLCBtZW1iZXIpKQog CiAvKioKICAqIGxpc3RfZm9yX2VhY2hfZW50cnlfcmV2ZXJzZSAtIGl0ZXJhdGUgYmFja3dhcmRz IG92ZXIgbGlzdCBvZiBnaXZlbiB0eXBlLgo= --00000000000064a3e305d91971a9-- 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 00CDEC433F5 for ; Mon, 28 Feb 2022 19:56:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 50A2B10E76B; Mon, 28 Feb 2022 19:56:41 +0000 (UTC) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 29E7910E76B for ; Mon, 28 Feb 2022 19:56:39 +0000 (UTC) Received: by mail-lf1-x136.google.com with SMTP id m14so23260327lfu.4 for ; Mon, 28 Feb 2022 11:56:39 -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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=Tm2RrZZp9rg85Q2lAdsba4a3IH+hQMy5xZCbUizCCXmPzyfZ+2VRqEslWXZB4tPt3B Xz8lYe63CHEdQCuWSaPC9nNMhFWrnR54Ihwd0u2qPZVZ4zvhHacXKCw+SJS4BR1PfT62 xCFGBc0xrmrOEo0QPHvZeTHUhXNuWYmty+udI= 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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=0rO5rIqDEm5/P7hNdXBCPgyY48LTfKcF2MnNJT8bD/eoG/BXpfbD27Fj0Yc0xH8Y0/ KUft16yErKKf0L7Rx9d0mUVUbUz+njtRikUFpYkj/N+5uKWx+DycRKHPLTZYUQUlSks2 Y8wmxYQwItvKrrMcMzqE1NBPgWhhmF4Y7RP7n0+eRhGiZ0o0BloaDl8qtWQEK7F5Iot9 gWE2NELRJt87T0fpU31fGf7ERHX+RaIWTcwOs64fX+oMeVjgdmrgTdvOc+Vl+akATrkM S050lySfHDE8MkBy7swcWLZ+Kjy6CiNDuAUXFjP8g93GVhInEksV53xhTxc7SZrHPYHl T0mQ== X-Gm-Message-State: AOAM5332wRQgbAMcKZ6UB6UpntdZeuQuCLiMq5+NWHSAzEhNndKc90i7 cE5nCrb2uNrdvZ26ySjon+U7qTxFZFGSDO3fqu0= X-Google-Smtp-Source: ABdhPJz9GvD8AeFUoLuOd+/YKcx6a+5v6AA5MdJljTNoGE7qUt/HoLezCkw1764dVAparTLMw/P//Q== X-Received: by 2002:ac2:4e52:0:b0:443:b1a0:1c2 with SMTP id f18-20020ac24e52000000b00443b1a001c2mr14069579lfr.444.1646078196954; Mon, 28 Feb 2022 11:56:36 -0800 (PST) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id t25-20020a2e7819000000b00244bc4dc84esm1444071ljc.105.2022.02.28.11.56.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 11:56:35 -0800 (PST) Received: by mail-lf1-f51.google.com with SMTP id j7so23251784lfu.6 for ; Mon, 28 Feb 2022 11:56:34 -0800 (PST) X-Received: by 2002:ac2:5313:0:b0:443:99c1:7e89 with SMTP id c19-20020ac25313000000b0044399c17e89mr13183568lfh.531.1646078183366; Mon, 28 Feb 2022 11:56:23 -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> In-Reply-To: <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> From: Linus Torvalds Date: Mon, 28 Feb 2022 11:56:07 -0800 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_K=C3=B6nig?= Content-Type: multipart/mixed; boundary="00000000000064a3e305d91971a9" 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 , "Bos, H.J." , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , 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 , Kees Cook , Arnd Bergman , Linux PM , intel-gfx , Brian Johannesmeyer , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , 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, 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 , Mike Rapoport Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --00000000000064a3e305d91971a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 28, 2022 at 4:19 AM Christian K=C3=B6nig wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=3Dgnu11" that was discussed in the original thread). That will guarantee that the 'pos' parameter of list_for_each_entry() is only updated INSIDE the for_each_list_entry() loop, and can never point to the (wrongly typed) head entry. And I would actually hope that it should actually cause compiler warnings about possibly uninitialized variables if people then use the 'pos' pointer outside the loop. Except (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for inexplicable reasons - possibly because it already expected this behavior (b) when I remove that NULL initializer, I still don't get a warning, because we've disabled -Wno-maybe-uninitialized since it results in so many false positives. Oh well. Anyway, give this patch a look, and at least if it's expanded to do "(pos) =3D NULL" in the entry statement for the for-loop, it will avoid the HEAD type confusion that Jakob is working on. And I think in a cleaner way than the horrid games he plays. (But it won't avoid possible CPU speculation of such type confusion. That, in my opinion, is a completely different issue) I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it. Anybody have any ideas? Linus --00000000000064a3e305d91971a9 Content-Type: application/octet-stream; name=p Content-Disposition: attachment; filename=p Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l073sb6w0 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvbGlzdC5oIGIvaW5jbHVkZS9saW51eC9saXN0LmgK aW5kZXggZGQ2YzIwNDFkMDljLi5iYWI5OTU1OTZhYWEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGlu dXgvbGlzdC5oCisrKyBiL2luY2x1ZGUvbGludXgvbGlzdC5oCkBAIC02MzQsMTAgKzYzNCwxMCBA QCBzdGF0aWMgaW5saW5lIHZvaWQgbGlzdF9zcGxpY2VfdGFpbF9pbml0KHN0cnVjdCBsaXN0X2hl YWQgKmxpc3QsCiAgKiBAaGVhZDoJdGhlIGhlYWQgZm9yIHlvdXIgbGlzdC4KICAqIEBtZW1iZXI6 CXRoZSBuYW1lIG9mIHRoZSBsaXN0X2hlYWQgd2l0aGluIHRoZSBzdHJ1Y3QuCiAgKi8KLSNkZWZp bmUgbGlzdF9mb3JfZWFjaF9lbnRyeShwb3MsIGhlYWQsIG1lbWJlcikJCQkJXAotCWZvciAocG9z ID0gbGlzdF9maXJzdF9lbnRyeShoZWFkLCB0eXBlb2YoKnBvcyksIG1lbWJlcik7CVwKLQkgICAg ICFsaXN0X2VudHJ5X2lzX2hlYWQocG9zLCBoZWFkLCBtZW1iZXIpOwkJCVwKLQkgICAgIHBvcyA9 IGxpc3RfbmV4dF9lbnRyeShwb3MsIG1lbWJlcikpCisjZGVmaW5lIGxpc3RfZm9yX2VhY2hfZW50 cnkocG9zLCBoZWFkLCBtZW1iZXIpCQkJCQlcCisJZm9yICh0eXBlb2YocG9zKSBfX2l0ZXIgPSBs aXN0X2ZpcnN0X2VudHJ5KGhlYWQsIHR5cGVvZigqcG9zKSwgbWVtYmVyKTsJXAorCSAgICAgIWxp c3RfZW50cnlfaXNfaGVhZChfX2l0ZXIsIGhlYWQsIG1lbWJlcikgJiYgKCgocG9zKT1fX2l0ZXIp LDEpOwlcCisJICAgICBfX2l0ZXIgPSBsaXN0X25leHRfZW50cnkoX19pdGVyLCBtZW1iZXIpKQog CiAvKioKICAqIGxpc3RfZm9yX2VhY2hfZW50cnlfcmV2ZXJzZSAtIGl0ZXJhdGUgYmFja3dhcmRz IG92ZXIgbGlzdCBvZiBnaXZlbiB0eXBlLgo= --00000000000064a3e305d91971a9-- 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 7DC68C433F5 for ; Mon, 28 Feb 2022 20:02:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Cc:To:Subject: Message-ID:Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ORqp7nUTUD82L2IegJzXkoUovpTfQTQ0WO0KfO6SZBU=; b=ZxK9v/Mhj85inddHmEz/SA0QWV PcP5dZh4/GJt4i6bSitPyJFvOy71DDGNf/r+IKe/d1Az106TW/C/ZAhIQNaiYvRq8gsH11f5YCbNl ff0yrxs23QD0qUziSTpEDP1S6j15D2jHcmM8wK4OK19oDfYtiVjOE4C+NXW63fFlh4IvzTF10gtDq x1zNVwEwX7U/TBExojkeLh9f5DcV+MajbdO2a6+OaGZ+qXgXDbOzwZ4IXRdVjEDDoeF9WowidBDMa GKs5PGvwcXPV5+xixdNgFMvRpJSO5GmSgPcu3mdloskfM6G71Vkc/CaTi9UyOcyExgpj3wSBLnlK0 jxuTldpg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOmDv-00Dwe0-4r; Mon, 28 Feb 2022 20:02:23 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOmDs-00DwcK-Bt for linux-mediatek@lists.infradead.org; Mon, 28 Feb 2022 20:02:21 +0000 Received: by mail-lj1-x236.google.com with SMTP id l12so7085263ljh.12 for ; Mon, 28 Feb 2022 12:02:19 -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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=Tm2RrZZp9rg85Q2lAdsba4a3IH+hQMy5xZCbUizCCXmPzyfZ+2VRqEslWXZB4tPt3B Xz8lYe63CHEdQCuWSaPC9nNMhFWrnR54Ihwd0u2qPZVZ4zvhHacXKCw+SJS4BR1PfT62 xCFGBc0xrmrOEo0QPHvZeTHUhXNuWYmty+udI= 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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=BSf3TSG8xZmd6lkqtTsmsHVxFL2pWzEpKdlxJoiU2H+TE96/dQkE3mW/jYnJEEmBQB g6cov5Fr/kJ+JXmEAuMTbIbB648YukGX+1l6kphnEh3bf05trTVdIG4s6Z57oxNnlM1P UsbfvtaDuqZYssiZTY9FQX4nJOxsUOoVRa7Dn/Vb8zZ6sCp8UUffGti+r0iTLIe92Wx+ IAXgfzXh7H74qIXJv+eKxzGS9hk8FDnWwEpWLa/ZntbacdKUQjVK4GAKvS5Dv5JYskZ9 MG4mLBYsP8pppXoZNBY0wfDnsfsv7fzwWrHWKoxo6/P9hiuUyPhnTNnY2ApCugfKbV8I vGLw== X-Gm-Message-State: AOAM530xuUDEcuwCjY2gqEslYUbiVzrvREvRPMndi9sTFh1KPXmKW65c iHCF6Lc07YBu3Td4Suapps0IhreO+zyPmudV9ao= X-Google-Smtp-Source: ABdhPJwH5pLUt405Onf2xhQ2E2pT8gHHKMj4oVubwnjUL1SPSO0pKg4ELUsu8FibhPTpx85HPHF9Bg== X-Received: by 2002:a2e:b90e:0:b0:239:3332:c83c with SMTP id b14-20020a2eb90e000000b002393332c83cmr14691853ljb.426.1646078538045; Mon, 28 Feb 2022 12:02:18 -0800 (PST) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id p1-20020a05651238c100b004437b4e5034sm1111711lft.159.2022.02.28.12.02.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 12:02:17 -0800 (PST) Received: by mail-lj1-f170.google.com with SMTP id o6so18962500ljp.3 for ; Mon, 28 Feb 2022 12:02:17 -0800 (PST) X-Received: by 2002:ac2:5313:0:b0:443:99c1:7e89 with SMTP id c19-20020ac25313000000b0044399c17e89mr13183568lfh.531.1646078183366; Mon, 28 Feb 2022 11:56:23 -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> In-Reply-To: <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> From: Linus Torvalds Date: Mon, 28 Feb 2022 11:56:07 -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: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: 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 , Kees Cook , 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: multipart/mixed; boundary="00000000000064a3e305d91971a9" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220228_120220_422301_3190793C X-CRM114-Status: GOOD ( 20.90 ) 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: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org --00000000000064a3e305d91971a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 28, 2022 at 4:19 AM Christian K=C3=B6nig wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=3Dgnu11" that was discussed in the original thread). That will guarantee that the 'pos' parameter of list_for_each_entry() is only updated INSIDE the for_each_list_entry() loop, and can never point to the (wrongly typed) head entry. And I would actually hope that it should actually cause compiler warnings about possibly uninitialized variables if people then use the 'pos' pointer outside the loop. Except (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for inexplicable reasons - possibly because it already expected this behavior (b) when I remove that NULL initializer, I still don't get a warning, because we've disabled -Wno-maybe-uninitialized since it results in so many false positives. Oh well. Anyway, give this patch a look, and at least if it's expanded to do "(pos) =3D NULL" in the entry statement for the for-loop, it will avoid the HEAD type confusion that Jakob is working on. And I think in a cleaner way than the horrid games he plays. (But it won't avoid possible CPU speculation of such type confusion. That, in my opinion, is a completely different issue) I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it. Anybody have any ideas? Linus --00000000000064a3e305d91971a9 Content-Type: application/octet-stream; name=p Content-Disposition: attachment; filename=p Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l073sb6w0 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvbGlzdC5oIGIvaW5jbHVkZS9saW51eC9saXN0LmgK aW5kZXggZGQ2YzIwNDFkMDljLi5iYWI5OTU1OTZhYWEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGlu dXgvbGlzdC5oCisrKyBiL2luY2x1ZGUvbGludXgvbGlzdC5oCkBAIC02MzQsMTAgKzYzNCwxMCBA QCBzdGF0aWMgaW5saW5lIHZvaWQgbGlzdF9zcGxpY2VfdGFpbF9pbml0KHN0cnVjdCBsaXN0X2hl YWQgKmxpc3QsCiAgKiBAaGVhZDoJdGhlIGhlYWQgZm9yIHlvdXIgbGlzdC4KICAqIEBtZW1iZXI6 CXRoZSBuYW1lIG9mIHRoZSBsaXN0X2hlYWQgd2l0aGluIHRoZSBzdHJ1Y3QuCiAgKi8KLSNkZWZp bmUgbGlzdF9mb3JfZWFjaF9lbnRyeShwb3MsIGhlYWQsIG1lbWJlcikJCQkJXAotCWZvciAocG9z ID0gbGlzdF9maXJzdF9lbnRyeShoZWFkLCB0eXBlb2YoKnBvcyksIG1lbWJlcik7CVwKLQkgICAg ICFsaXN0X2VudHJ5X2lzX2hlYWQocG9zLCBoZWFkLCBtZW1iZXIpOwkJCVwKLQkgICAgIHBvcyA9 IGxpc3RfbmV4dF9lbnRyeShwb3MsIG1lbWJlcikpCisjZGVmaW5lIGxpc3RfZm9yX2VhY2hfZW50 cnkocG9zLCBoZWFkLCBtZW1iZXIpCQkJCQlcCisJZm9yICh0eXBlb2YocG9zKSBfX2l0ZXIgPSBs aXN0X2ZpcnN0X2VudHJ5KGhlYWQsIHR5cGVvZigqcG9zKSwgbWVtYmVyKTsJXAorCSAgICAgIWxp c3RfZW50cnlfaXNfaGVhZChfX2l0ZXIsIGhlYWQsIG1lbWJlcikgJiYgKCgocG9zKT1fX2l0ZXIp LDEpOwlcCisJICAgICBfX2l0ZXIgPSBsaXN0X25leHRfZW50cnkoX19pdGVyLCBtZW1iZXIpKQog CiAvKioKICAqIGxpc3RfZm9yX2VhY2hfZW50cnlfcmV2ZXJzZSAtIGl0ZXJhdGUgYmFja3dhcmRz IG92ZXIgbGlzdCBvZiBnaXZlbiB0eXBlLgo= --00000000000064a3e305d91971a9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek --00000000000064a3e305d91971a9-- 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 A1F70C433FE for ; Tue, 1 Mar 2022 04:37:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E3EE210EB5F; Tue, 1 Mar 2022 04:37:24 +0000 (UTC) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8738810E76B for ; Mon, 28 Feb 2022 19:56:29 +0000 (UTC) Received: by mail-lf1-x12f.google.com with SMTP id f37so23202920lfv.8 for ; Mon, 28 Feb 2022 11:56:29 -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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=Tm2RrZZp9rg85Q2lAdsba4a3IH+hQMy5xZCbUizCCXmPzyfZ+2VRqEslWXZB4tPt3B Xz8lYe63CHEdQCuWSaPC9nNMhFWrnR54Ihwd0u2qPZVZ4zvhHacXKCw+SJS4BR1PfT62 xCFGBc0xrmrOEo0QPHvZeTHUhXNuWYmty+udI= 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=gT/mxIYbzDn15+z84Rt0/ZmLFqIl34ZjMPCseIzUB9o=; b=DvGKr2xm1zVR309jg6z0/M8yOTzPLHppKo/SDecssrCGjSrYgOXARb5yEOMHqnJktR eeIxsbpgd2ar4tDFtv3xtq7Dr7AbyiWp1PPKOs2hx2r1E9Oq/qyvo+1ivk80Dfa2HzoL lZbpVgNOSjwnH9zLYkme9fvREBuC+IvkBw+K15Vxpd70jxzgxorZ3Ppwaq1j3t8IAr17 YAZoJcLBXf55WSiZdsZjkBN040Jq3lAXmtcy1vcE3c72kn6LFGGy7YeVQeTL9iIqIULt BzMN8/KMpvx0/fhS8uR2OT8YvTpztW7UwDOE+x8dbcHLSb4fjBZBuhQEwxCip3p1ht2h lT2Q== X-Gm-Message-State: AOAM5337x+bBQ0RWAz5jvkooC+UboSspN7M7iDcNFRYYXQwVbssBVjfo 2w+x2PrtO+9m7dOCBi22thw5VeK0xoWrPfuRo4M= X-Google-Smtp-Source: ABdhPJzZbckRTYe5dXEElf6k+gYqJzXGVlW+PRUoxrGYhc50vbkHjuh2jfEFmMmgaz5vysZwjUGs5w== X-Received: by 2002:a05:6512:2109:b0:443:b538:b866 with SMTP id q9-20020a056512210900b00443b538b866mr13678127lfr.487.1646078187466; Mon, 28 Feb 2022 11:56:27 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id a23-20020ac25057000000b00443974b9bffsm1106291lfm.218.2022.02.28.11.56.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 11:56:25 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id y24so23274154lfg.1 for ; Mon, 28 Feb 2022 11:56:23 -0800 (PST) X-Received: by 2002:ac2:5313:0:b0:443:99c1:7e89 with SMTP id c19-20020ac25313000000b0044399c17e89mr13183568lfh.531.1646078183366; Mon, 28 Feb 2022 11:56:23 -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> In-Reply-To: <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> From: Linus Torvalds Date: Mon, 28 Feb 2022 11:56:07 -0800 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_K=C3=B6nig?= Content-Type: multipart/mixed; boundary="00000000000064a3e305d91971a9" X-Mailman-Approved-At: Tue, 01 Mar 2022 04:37:20 +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 , "Bos, H.J." , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , 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 , Kees Cook , Arnd Bergman , Linux PM , intel-gfx , Brian Johannesmeyer , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , 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, 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 , Mike Rapoport Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" --00000000000064a3e305d91971a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 28, 2022 at 4:19 AM Christian K=C3=B6nig wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=3Dgnu11" that was discussed in the original thread). That will guarantee that the 'pos' parameter of list_for_each_entry() is only updated INSIDE the for_each_list_entry() loop, and can never point to the (wrongly typed) head entry. And I would actually hope that it should actually cause compiler warnings about possibly uninitialized variables if people then use the 'pos' pointer outside the loop. Except (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for inexplicable reasons - possibly because it already expected this behavior (b) when I remove that NULL initializer, I still don't get a warning, because we've disabled -Wno-maybe-uninitialized since it results in so many false positives. Oh well. Anyway, give this patch a look, and at least if it's expanded to do "(pos) =3D NULL" in the entry statement for the for-loop, it will avoid the HEAD type confusion that Jakob is working on. And I think in a cleaner way than the horrid games he plays. (But it won't avoid possible CPU speculation of such type confusion. That, in my opinion, is a completely different issue) I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it. Anybody have any ideas? Linus --00000000000064a3e305d91971a9 Content-Type: application/octet-stream; name=p Content-Disposition: attachment; filename=p Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l073sb6w0 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvbGlzdC5oIGIvaW5jbHVkZS9saW51eC9saXN0LmgK aW5kZXggZGQ2YzIwNDFkMDljLi5iYWI5OTU1OTZhYWEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGlu dXgvbGlzdC5oCisrKyBiL2luY2x1ZGUvbGludXgvbGlzdC5oCkBAIC02MzQsMTAgKzYzNCwxMCBA QCBzdGF0aWMgaW5saW5lIHZvaWQgbGlzdF9zcGxpY2VfdGFpbF9pbml0KHN0cnVjdCBsaXN0X2hl YWQgKmxpc3QsCiAgKiBAaGVhZDoJdGhlIGhlYWQgZm9yIHlvdXIgbGlzdC4KICAqIEBtZW1iZXI6 CXRoZSBuYW1lIG9mIHRoZSBsaXN0X2hlYWQgd2l0aGluIHRoZSBzdHJ1Y3QuCiAgKi8KLSNkZWZp bmUgbGlzdF9mb3JfZWFjaF9lbnRyeShwb3MsIGhlYWQsIG1lbWJlcikJCQkJXAotCWZvciAocG9z ID0gbGlzdF9maXJzdF9lbnRyeShoZWFkLCB0eXBlb2YoKnBvcyksIG1lbWJlcik7CVwKLQkgICAg ICFsaXN0X2VudHJ5X2lzX2hlYWQocG9zLCBoZWFkLCBtZW1iZXIpOwkJCVwKLQkgICAgIHBvcyA9 IGxpc3RfbmV4dF9lbnRyeShwb3MsIG1lbWJlcikpCisjZGVmaW5lIGxpc3RfZm9yX2VhY2hfZW50 cnkocG9zLCBoZWFkLCBtZW1iZXIpCQkJCQlcCisJZm9yICh0eXBlb2YocG9zKSBfX2l0ZXIgPSBs aXN0X2ZpcnN0X2VudHJ5KGhlYWQsIHR5cGVvZigqcG9zKSwgbWVtYmVyKTsJXAorCSAgICAgIWxp c3RfZW50cnlfaXNfaGVhZChfX2l0ZXIsIGhlYWQsIG1lbWJlcikgJiYgKCgocG9zKT1fX2l0ZXIp LDEpOwlcCisJICAgICBfX2l0ZXIgPSBsaXN0X25leHRfZW50cnkoX19pdGVyLCBtZW1iZXIpKQog CiAvKioKICAqIGxpc3RfZm9yX2VhY2hfZW50cnlfcmV2ZXJzZSAtIGl0ZXJhdGUgYmFja3dhcmRz IG92ZXIgbGlzdCBvZiBnaXZlbiB0eXBlLgo= --00000000000064a3e305d91971a9-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Date: Mon, 28 Feb 2022 11:56:07 -0800 Subject: [Intel-wired-lan] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr In-Reply-To: <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> 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 Mon, Feb 28, 2022 at 4:19 AM Christian K?nig wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=gnu11" that was discussed in the original thread). That will guarantee that the 'pos' parameter of list_for_each_entry() is only updated INSIDE the for_each_list_entry() loop, and can never point to the (wrongly typed) head entry. And I would actually hope that it should actually cause compiler warnings about possibly uninitialized variables if people then use the 'pos' pointer outside the loop. Except (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for inexplicable reasons - possibly because it already expected this behavior (b) when I remove that NULL initializer, I still don't get a warning, because we've disabled -Wno-maybe-uninitialized since it results in so many false positives. Oh well. Anyway, give this patch a look, and at least if it's expanded to do "(pos) = NULL" in the entry statement for the for-loop, it will avoid the HEAD type confusion that Jakob is working on. And I think in a cleaner way than the horrid games he plays. (But it won't avoid possible CPU speculation of such type confusion. That, in my opinion, is a completely different issue) I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it. Anybody have any ideas? Linus -------------- next part -------------- A non-text attachment was scrubbed... Name: p Type: application/octet-stream Size: 881 bytes Desc: not available URL: