Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3517241pxm; Mon, 28 Feb 2022 23:06:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJyAe6v+xoqZAqn4FcwYsmeehrpIk68k65/b2V1scu5AE0KdMMa98UoSWVoOGe6pPDhiTWq4 X-Received: by 2002:a17:906:a145:b0:6ae:e45d:15b6 with SMTP id bu5-20020a170906a14500b006aee45d15b6mr18150542ejb.714.1646118376734; Mon, 28 Feb 2022 23:06:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646118376; cv=none; d=google.com; s=arc-20160816; b=m6bvfT9E62A/MfzYvO2xubYwOjfWXv69pEEMQYvNgqzmsMGOlvPYMX2VrnzLytmeUE fabbBpxi/MiSFLESndruXrFMbY5UA16mO0KN/y2/e7xtXJFz5oKeKTMaqC8vz0mfiswE LOe6kUQBh/rhVYWCDmLP5UK0/Zsg4jLEpBrT55YENUFIUifzbdQsHdP2bpRmezlNJMcI vvETwWbvqZHT0F1KkOwno71BZpcYFYvB2LwtgNqa3vmxRsm2opl7sXX1gNkPDSfQRsFx sKJFNqyEovxMM49jjEUjUoV1R4o8OMuQKuEIE60ArQKsdg1yXWjUcorcVXachUSsL7Vo 0H0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=BD0HfQAXvpDPERbGhTosyshXg4AiQkDbtPk6kOOGIFM=; b=BgWel9yhKphmToBuj94gwCbYI53wlxYLFn2gHUvDon+DpPFbPnPj2xU3nzqV4l2hVZ KrmDhFDIDGbGBARMbDEiHFLau940dO+RFJRCKPS1lCvFGQ3m3p2xwZ5gSoN78B73kwEs /MI1D3Nt4fdx/VhnQa7Ly/jyL8p5If8R8C3ho747xPRCUHrg07eQh3FbufImFfaCFwJM lU0P17wNgGc3EeEeqfO4nceTCe23X+m0L0gtu7AwTglPoZg4BCy0zOS51QK4RXLiz5i6 64NMslyyVPAYVBOfcTUUZ7rd33CHhHPdDrZTZ+gEEFF+tV90KsC3L7tw/hVddQVd8S57 dplA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="VNHL/rpf"; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f18-20020a50a6d2000000b0040aa9eefc2dsi8055887edc.310.2022.02.28.23.05.53; Mon, 28 Feb 2022 23:06:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="VNHL/rpf"; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232658AbiCAGdU (ORCPT + 72 others); Tue, 1 Mar 2022 01:33:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232494AbiCAGdP (ORCPT ); Tue, 1 Mar 2022 01:33:15 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45B68E0C3; Mon, 28 Feb 2022 22:32:32 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 75B876119B; Tue, 1 Mar 2022 06:32:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDB1BC340F0; Tue, 1 Mar 2022 06:32:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646116351; bh=/Yg/Wtj2qqC5DtZph9xh9a5I6i9ac63I49JjnGAnbz0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VNHL/rpf4xC8OfR4t6vo9UDhccraY87hqDEaB5+IcVN4t3xSDpu027UghrvvyPQSS 4QuUBVLbP+fb/wau99bJi4r7o82Cq8bpmARbff3Kmy/AtDhoQCnd/xuFpD/mZTaTLe NB4lRdgymAA7RGUyYzHE9lasNH7iZMQkKEkyzKBO3tOdshLibbcwpXFMt0/8PjfBOI eBOAlJkJQ4cQoPLzxj+EO1bIuaMcgSLjX7K2SicEKpT/LLsGPP1i6N98tAlqdrYU3i Kp9mElgbXeQQFbCmQa35pv8BJ12s3DBVkk5Xbz9WcUOYNg9YRr2X/a7+Y15htjkLBQ B1WsfW9PNeplw== Date: Mon, 28 Feb 2022 22:32:28 -0800 From: Jakub Kicinski To: Linus Torvalds Cc: Jakob Koschel , Christian =?UTF-8?B?S8O2bmln?= , 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 Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr Message-ID: <20220228223228.24cf3fd4@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> In-Reply-To: References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 28 Feb 2022 16:41:04 -0800 Linus Torvalds wrote: > So yes, initially my idea had been to just move the iterator entirely > inside the macro. But specifying the type got so ugly that I think > that > > typeof (pos) pos > > trick inside the macro really ends up giving us the best of all worlds: > > (a) let's us keep the existing syntax and code for all the nice cases > that did everything inside the loop anyway > > (b) gives us a nice warning for any normal use-after-loop case > (unless you explicitly initialized it like that > sgx_mmu_notifier_release() function did for no good reason > > (c) also guarantees that even if you don't get a warning, > non-converted (or newly written) bad code won't actually _work_ > > so you end up getting the new rules without any ambiguity or mistaken I presume the goal is that we can do this without changing existing code? Otherwise actually moving the iterator into the loop body would be an option, by creating a different hidden variable: #define list_iter(head) \ for (struct list head *_l = (head)->next; _l != (head); _l = _l->next) #define list_iter_entry(var, member) \ list_entry(_l, typeof(*var), member) list_iter(&p->a_head) { struct entry *e = list_iter_entry(e, a_member); /* use e->... */ } Or we can slide into soft insanity and exploit one of Kees'es tricks to encode the type of the entries "next to" the head: #define LIST_HEAD_MEM(name, type) \ union { \ struct list_head name; \ type *name ## _entry; \ } struct entry { struct list_head a_member; }; struct parent { LIST_HEAD_MEM(a_head, struct entry); }; #define list_for_each_magic(pos, head, member) \ for (typeof(**(head ## _entry)) *pos = list_first_entry(head, typeof(**(head ## _entry)), member); \ &pos->member != (head); \ pos = list_next_entry(pos, member)) list_for_each_magic(e, &p->a_head, a_member) { /* use e->... */ } I'll show myself out...