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 4DE94C433EF for ; Sat, 5 Mar 2022 08:39:51 +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 948E31B23; Sat, 5 Mar 2022 09:38:59 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 948E31B23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1646469589; bh=hjeB44RUAH6hFyqQcSryTGXbNDvUWAbDNhkGYX16Vso=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=LdJouEf9XVagn7TBrjcJwfBE9xIKXD2FRJ6y0cdUBkZcwNnJFgkuUphcKQulOaT46 vbtSNlcG/3g8gId+SDgc0TEiQkv7hjyn62KRVYLAsjJjWNrMrNlFCznUVbx8Rs9nG7 TbeeezETZEiClVwGMQ2qEn4gVJRMa14yLWDGUcIw= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id A54E2F80529; Sat, 5 Mar 2022 09:36:52 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id BCD64F80152; Thu, 3 Mar 2022 13:18:33 +0100 (CET) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 55A83F80109 for ; Thu, 3 Mar 2022 13:18:29 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 55A83F80109 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="BVoUYAMy" Received: by mail-wr1-x42b.google.com with SMTP id n14so7549353wrq.7 for ; Thu, 03 Mar 2022 04:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=W95klwG+EWnuJlXqfneyIPG4bMJIpYFCGfgCPBAo/s4=; b=BVoUYAMy6igzOx7YCxgmD2obGVeA4FBbFy39UaDXpcyotfQj1WSs4cD2dBmZ3jehpH Xv0H27JfD7LtNc3KTOYt5JsPQaESLbVZdrRIjVdCS/EqEN+LtHV3OI92ZhbhaxnOPsMB zwIbvmQMtvcWtqQz/AOpNYfJzkMTFsv4hojr0PuJEFUbZHgxYNi3BKpDV1mgkUzm+fR0 4lMaaRE5yh5PGutSdpreHiYAqhMDl6KUHTvi2q6aV5S93rhbYz2wGWOzwPq3hB3YVbYG uAhL64o8wkOM/gpLUr2Hb7oB/DraMZLkoBj2jGHmKGFPjyxdoWyrLbd/6WyXGtmMO48w vp2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=W95klwG+EWnuJlXqfneyIPG4bMJIpYFCGfgCPBAo/s4=; b=MGncpelj1ia5/xY/MLnPRuDsYSw+M1aDZ6VC/rS/R3mLS7JBCk9kQ8Yx6uSE/AN5t6 bNGnOf0SsLur0IG56CkoCR407n1XKWLLZpTco+CmfMteddDhhdZnXnDtMYoFSqUfn8DZ ucNX9BLfbsDStMLS9i83QV2024j1oGqXmRLMuCd7Dw3DsWm2+XYcxZ/CDkwhdBXuNimN WEXkGoKhx1n31ayWkfqDpZ41XgEqxUGKAvTi8hHnil9Y16xLNhDUAjiqQowDKhQGIUbw tVwjRf9e0xbQjS1ZEpmGROFZQfTGF0yP+GruuohD+EiPAme6bhY11DE6G7eEc5+xg+Ar IjSg== X-Gm-Message-State: AOAM532x0Eu+NsMhAjiAsZDMKEJxX7Zr9u84lElDtZ3kDfmphW4gecSQ HKdTql5pLLa4e3BHjtFqyZGGAg== X-Google-Smtp-Source: ABdhPJwgYeUN7RS9hQRShRziePljKQd/1cMutSSEkk4MeQ2QRRtTjZSLz5QSndDd2pML49XlqkHAqw== X-Received: by 2002:a5d:6d0d:0:b0:1e8:7b6a:38e7 with SMTP id e13-20020a5d6d0d000000b001e87b6a38e7mr26568054wrq.625.1646309908722; Thu, 03 Mar 2022 04:18:28 -0800 (PST) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id p6-20020a5d4586000000b001f0436cb325sm1774600wrq.52.2022.03.03.04.18.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Mar 2022 04:18:28 -0800 (PST) Date: Thu, 3 Mar 2022 12:18:24 +0000 From: Daniel Thompson To: Xiaomeng Tong Subject: Re: [Kgdb-bugreport] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr Message-ID: <20220303121824.qdyrognluik74iph@maple.lan> References: <39404befad5b44b385698ff65465abe5@AcuMS.aculab.com> <20220303072657.11124-1-xiam0nd.tong@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220303072657.11124-1-xiam0nd.tong@gmail.com> X-Mailman-Approved-At: Sat, 05 Mar 2022 09:36:45 +0100 Cc: linux-wireless@vger.kernel.org, alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, gustavo@embeddedor.com, linux-iio@vger.kernel.org, kgdb-bugreport@lists.sourceforge.net, linux@rasmusvillemoes.dk, dri-devel@lists.freedesktop.org, c.giuffrida@vu.nl, amd-gfx@lists.freedesktop.org, linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch@vger.kernel.org, linux-cifs@vger.kernel.org, kvm@vger.kernel.org, linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, linux-staging@lists.linux.dev, h.j.bos@vu.nl, jgg@ziepe.ca, intel-wired-lan@lists.osuosl.org, nouveau@lists.freedesktop.org, bcm-kernel-feedback-list@broadcom.com, dan.carpenter@oracle.com, linux-media@vger.kernel.org, keescook@chromium.org, arnd@arndb.de, linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linuxppc-dev@lists.ozlabs.org, bjohannesmeyer@gmail.com, linux-block@vger.kernel.org, dmaengine@vger.kernel.org, christophe.jaillet@wanadoo.fr, jakobkoschel@gmail.com, v9fs-developer@lists.sourceforge.net, linux-tegra@vger.kernel.org, tglx@linutronix.de, andriy.shevchenko@linux.intel.com, linux-arm-kernel@lists.infradead.org, linux-sgx@vger.kernel.org, nathan@kernel.org, netdev@vger.kernel.org, linux-usb@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, david.laight@aculab.com, tipc-discussion@lists.sourceforge.net, linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mediatek@lists.infradead.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, christian.koenig@amd.com, rppt@kernel.org 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 Thu, Mar 03, 2022 at 03:26:57PM +0800, Xiaomeng Tong wrote: > On Thu, 3 Mar 2022 04:58:23 +0000, David Laight wrote: > > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote: > > > The problem is the mis-use of iterator outside the loop on exit, and > > > the iterator will be the HEAD's container_of pointer which pointers > > > to a type-confused struct. Sidenote: The *mis-use* here refers to > > > mistakely access to other members of the struct, instead of the > > > list_head member which acutally is the valid HEAD. > > > > The problem is that the HEAD's container_of pointer should never > > be calculated at all. > > This is what is fundamentally broken about the current definition. > > Yes, the rule is "the HEAD's container_of pointer should never be > calculated at all outside the loop", but how do you make sure everyone > follows this rule? Your formulation of the rule is correct: never run container_of() on HEAD pointer. However the rule that is introduced by list_for_each_entry_inside() is *not* this rule. The rule it introduces is: never access the iterator variable outside the loop. Making the iterator NULL on loop exit does follow the rule you proposed but using a different technique: do not allow HEAD to be stored in the iterator variable after loop exit. This also makes it impossible to run container_of() on the HEAD pointer. > Everyone makes mistakes, but we can eliminate them all from the beginning > with the help of compiler which can catch such use-after-loop things. Indeed but if we introduce new interfaces then we don't have to worry about existing usages and silent regressions. Code will have been written knowing the loop can exit with the iterator set to NULL. Sure it is still possible for programmers to make mistakes and dereference the NULL pointer but C programmers are well training w.r.t. NULL pointer checking so such mistakes are much less likely than with the current list_for_each_entry() macro. This risk must be offset against the way a NULLify approach can lead to more elegant code when we are doing a list search. Daniel.