From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 438E1C433EF for ; Fri, 11 Mar 2022 14:28:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4658F8D0002; Fri, 11 Mar 2022 09:28:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 415E38D0001; Fri, 11 Mar 2022 09:28:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B6AC8D0002; Fri, 11 Mar 2022 09:28:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 1D6698D0001 for ; Fri, 11 Mar 2022 09:28:00 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CE59D8A3E5 for ; Fri, 11 Mar 2022 14:27:59 +0000 (UTC) X-FDA: 79232334678.25.239B473 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf03.hostedemail.com (Postfix) with ESMTP id 2B73620028 for ; Fri, 11 Mar 2022 14:27:58 +0000 (UTC) Received: by mail-wm1-f50.google.com with SMTP id v130-20020a1cac88000000b00389d0a5c511so1186419wme.5 for ; Fri, 11 Mar 2022 06:27:57 -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:content-transfer-encoding:in-reply-to; bh=MpXiSYabOrYwVZBoUNg0nqtYEvuBi16Uja5dFf2EH0o=; b=k2nh2gjDZ2GWduILDMTVTdPhwUGy/gKiaKiDAAeWeNvWs+qTTrNrgWKCpvV5YZTUem oS/VqO60ezzCYtbnUQI49E+RYcTTpPSClCwilaRKFbUWSxsD5nb47zN5aSspNsfFktFZ FkbA1p2tgEoHpfs74AHjwcd7z1Fmq06KPg4uI1LJjNZjy+w0+El9JAo7Kd2WQgnuoWT+ HpMizIPvpJ4kBD8vcbDXLo7JWtSiBBROSlbVgdGvOfUJcbc+q2t6xbeJDOeNJ7IgcDkf oPtG5W7BIAAQOD9tgIZbFNVeFcpnIzkbhUQGtMeyPsJMSxGYr8R3kg3jnU3j/sB/SxSq Xk9A== 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:content-transfer-encoding :in-reply-to; bh=MpXiSYabOrYwVZBoUNg0nqtYEvuBi16Uja5dFf2EH0o=; b=ziDqu3SE9R1udfu9AUEqHuqVVD5od+0r5trSE76PZkCyim/wKnQ7QFLQhfihUQPJvm /w+GjBNZlTS5t2lRft0bbzzo4lXY4HXqpaKTb2/zjxgslyOhZh73FAFj7UECvOXBOkM/ dBUBWlyR6B3TTXqeOs621/ZA3qK3EEl6MsEu5zG6gdcW6kJf63+57l8Bnx0fzOc/eu06 w7tUou09lKVxj8prgUWrcDEYqdIUHs2EOsgL96NSfZ+84u7W4FGjRxvSSXHgP4rwYCYD 52VBsXaOyep+aYGUGnMu3O0peYtNrUWDG3iVLoQtTRj3w0Z9DbjsgUF4NLo7C6QlB6I/ RWmw== X-Gm-Message-State: AOAM533lt2vbe2GuhAthLb3lbbNLsCthxt9QTSEqVgRvL5zYxTd8jUfW y28sU5bPmonVZ+shtvOTlm/zbQ== X-Google-Smtp-Source: ABdhPJxQojmr11qBMELiUdbxhAZwsibac1eN9niCtFM0AGC0j84YVyfws1DV7ZJcT9GegkvTIMpT+w== X-Received: by 2002:a1c:f718:0:b0:380:ed20:6557 with SMTP id v24-20020a1cf718000000b00380ed206557mr16407510wmh.53.1647008876745; Fri, 11 Mar 2022 06:27:56 -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 u23-20020a7bcb17000000b0037bdfa1665asm14118274wmj.18.2022.03.11.06.27.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 06:27:56 -0800 (PST) Date: Fri, 11 Mar 2022 14:27:54 +0000 From: Daniel Thompson To: Linus Torvalds Cc: Xiaomeng Tong , Arnd Bergmann , Greg Kroah-Hartman , Jakob Koschel , Jann Horn , Kees Cook , Linux Kbuild mailing list , Linux Kernel Mailing List , Linux-MM , Netdev Subject: Re: [PATCH 2/6] list: add new MACROs to make iterator invisiable outside the loop Message-ID: <20220311142754.a3jnnjqxpok75qgp@maple.lan> References: <20220304025109.15501-1-xiam0nd.tong@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2B73620028 X-Stat-Signature: j7dk59tug79pcj7961eb8pepmhuhfowc X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=k2nh2gjD; spf=pass (imf03.hostedemail.com: domain of daniel.thompson@linaro.org designates 209.85.128.50 as permitted sender) smtp.mailfrom=daniel.thompson@linaro.org; dmarc=pass (policy=none) header.from=linaro.org X-HE-Tag: 1647008878-836614 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Mar 05, 2022 at 04:35:36PM -0800, Linus Torvalds wrote: > On Sat, Mar 5, 2022 at 1:09 PM Linus Torvalds > wrote: > What do people think? Is this clever and useful, or just too > subtle and odd to exist? > NOTE! I decided to add that "name of the target head in the target > type" to the list_traversal_head() macro, but it's not actually used > as is. It's more of a wishful "maybe we could add some sanity checking > of the target list entries later". >=20 > Comments? It is possible simply to use spelling to help uncover errors in list_traverse()? Something like: #define list_traversal_head(type, name, target_member) \ union { \ struct list_head name; \ type *name##_traversal_mismatch_##target_member; \ } And: #define list_traverse(pos, head, member) \ for (typeof(*head##_traversal_mismatch_##member) pos =3D list_first_entr= y(head, typeof(*pos), member); \ !list_entry_is_head(pos, head, member); \ pos =3D list_next_entry(pos, member)) If I deliberately insert an error into your modified exit.c then the resulting errors even make helpful suggestions about what you did wrong: kernel/exit.c:412:32: error: =E2=80=98struct task_struct=E2=80=99 has no = member named =E2=80=98children_traversal_mismatch_children=E2=80=99; did you mean =E2=80=98children_traversal_mismatch_sibling=E2=80=99? The suggestions are not always as good as the above (children_traversal_mismatch_ptrace_entry suggests ptraced_traversal_mismatch_ptrace_entry) but, nevertheless, it does appears to be robust in detecting incorrect traversal. > diff --git a/include/linux/list.h b/include/linux/list.h > index dd6c2041d09c..1e8b3e495b51 100644 > --- a/include/linux/list.h > +++ b/include/linux/list.h > @@ -25,6 +25,9 @@ > #define LIST_HEAD(name) \ > struct list_head name =3D LIST_HEAD_INIT(name) Seeing this in the diff did set me thinking about static/global list heads. For architectures without HAVE_LD_DEAD_CODE_DATA_ELIMINATION then the "obvious" extension of list_traversal_head() ends up occupying bss space. Even replacing the pointer with a zero length array is still provoking gcc-11 (arm64) to allocate a byte from bss (often with a lot of padding added). Perhaps in the grand scheme of things this doesn't matter. Across the whole tree and all architecture I see only ~1200 instances so even in the worst case and with padding everywhere the wasted RAM is only a few kb. Nevertheless I was curious if there is any cunning tricks to avoid this? Naturally LIST_HEAD() could just declare a union but that would require all sites of use to be updated simultaneously and I rather like the way list_traverse_head() is entirely incremental. Daniel.