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 AB77FC433F5 for ; Wed, 16 Mar 2022 15:45:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD46E6B0071; Wed, 16 Mar 2022 11:45:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D843F8D0002; Wed, 16 Mar 2022 11:45:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C24D48D0001; Wed, 16 Mar 2022 11:45:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id B2B096B0071 for ; Wed, 16 Mar 2022 11:45:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 80DA01211F0 for ; Wed, 16 Mar 2022 15:45:49 +0000 (UTC) X-FDA: 79250674818.11.EC2759D Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf02.hostedemail.com (Postfix) with ESMTP id 1545280031 for ; Wed, 16 Mar 2022 15:45:48 +0000 (UTC) Received: by mail-wr1-f50.google.com with SMTP id j17so3644838wrc.0 for ; Wed, 16 Mar 2022 08:45:48 -0700 (PDT) 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=wAgk6NoEkSGQYtklkyp/XBe3mmZFGzBwfiqA3+Hd+Uc=; b=UaDuw6uE+eA3eoFtbNNWGH31fmxdFNfCd+8KTwJiz+XVa67E6qGA7rnSF18inN9r7Y qagW0lhTrjPtdLbMts8uQresOtZcaucElVE6QTjJOHL4nHQiHmARLSAiHbxM+ilNC8I9 0pB+mcIYzA8CpBXVvR2Muc6zTjci9aX7iOglulhiX/5PGxKANkvqyGmlBXTy1HgQZtZa dbiMZu3JglXKMidVnZzd7qJ7o28dPtoNgg2mpDLH8lwkr9ymuiri75xLap5GrnGWoiKM 2YmMN97zjLq8pQYxfLoXbmyytnuWDrXDEPJT6p/AzVirsoxEYO2L+1VZIt0QeRwrV5A/ a5Ng== 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=wAgk6NoEkSGQYtklkyp/XBe3mmZFGzBwfiqA3+Hd+Uc=; b=2wDmJZ+ESGbERmiLbLsY72kYsbwNrVntaNOgnJtrIZNMpi1pluCHqtxZYvnooR9cUO Rf9yjVQYz2bwqdc1kfsEshwuhldu14uHqAiNiUPQulHnjS/hOpIxUYxxra50AqNSzV4J cjvQKzHiYLJGlJnhMNkLPSXhKpFyYNFPRnARCFzEM31a3LhPNc6ebEF8PFyr52DpgpJ0 wlucngK7jobeecD3Ytt0y0ltaJ8m9nak9xH9loJ6uPnNrtngg9hyb8a6h64nVLl4/bK1 t99kC4x9d3OpxNEyHT6hLl65wUFPbKgu++1pcXGFHg8rVwXbuVZyh4flcA55pnMlxtcU o/8A== X-Gm-Message-State: AOAM531hmjEih7fAbAsgGwmAmKrFlmDjQJH0YfZK4p/CG9KI8W3WfYbe SawL4JO9x68jOhab1rOwuYYkKA== X-Google-Smtp-Source: ABdhPJyMUpPUtVKC6CCFRGjl7Q7U86a/YVte8/m4ryk1rwUIF5Hpq9WZjwkjrrTrbJgh9LWKNGjfCg== X-Received: by 2002:a5d:4cc1:0:b0:1f0:98e7:6af0 with SMTP id c1-20020a5d4cc1000000b001f098e76af0mr409578wrt.363.1647445547485; Wed, 16 Mar 2022 08:45:47 -0700 (PDT) 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 11-20020a05600c26cb00b0037ff53511f2sm4927285wmv.31.2022.03.16.08.45.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 08:45:46 -0700 (PDT) Date: Wed, 16 Mar 2022 15:45:44 +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 , =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Subject: Re: [PATCH 2/6] list: add new MACROs to make iterator invisiable outside the loop Message-ID: <20220316154544.bfewwi7zseyyja47@maple.lan> References: <20220304025109.15501-1-xiam0nd.tong@gmail.com> <20220311142754.a3jnnjqxpok75qgp@maple.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 1545280031 X-Stat-Signature: q415chrgmaunwijkx7uozb4eiinhqk43 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=UaDuw6uE; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf02.hostedemail.com: domain of daniel.thompson@linaro.org designates 209.85.221.50 as permitted sender) smtp.mailfrom=daniel.thompson@linaro.org X-Rspamd-Server: rspam03 X-HE-Tag: 1647445548-768165 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 Fri, Mar 11, 2022 at 10:41:06AM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2022 at 6:27 AM Daniel Thompson > wrote: > > > > It is possible simply to use spelling to help uncover errors in > > list_traverse()? > > I'd love to, and thought that would be a lovely idea, but in another > thread ("") Barnabás Pőcze pointed out that we actually have a fair > number of cases where the list member entries are embedded in internal > structures and have a '.' in them: > > https://lore.kernel.org/all/wKlkWvCGvBrBjshT6gHT23JY9kWImhFPmTKfZWtN5Bkv_OtIFHTy7thr5SAEL6sYDthMDth-rvFETX-gCZPPCb9t2bO1zilj0Q-OTTSbe00=@protonmail.com/ > > which means that you can't actually append the target_member name > except in the simplest cases, because it wouldn't result in one single > identifier. > > Otherwise it would be a lovely idea. When I prototyped this I did actually include a backdoor to cover situations like this but I ended up (incorrectly at appears) editing it out for simplicity. Basically the union is free so we can have more than one type * member: #define list_traversal_head(type, name, target_member) \ union { \ struct list_head name; \ type *name##_traversal_type; \ type *name##_traversal_mismatch_##target_member; \ } This allows that the single structure cases to be checked whilst nested structures (and array which I noticed also crop up) have a trap door such as list_traverse_unchecked(). I did a quick grep to estimate how many nested/array cases there are and came up with around 2.5% (roughly ~200 in ~8500, counting only the single line users of list_for_each_entry() ). As you say, lovely idea but having to use special API 2.5% of the time seems a bit on the high side. BTW, a complete aside, but whilst I was looking for trouble I also spotted code where the list head is an array which means we are not able to lookup the travesral type correctly: list_for_each_entry(modes[i], &connector->modes, head) However I found only one instance of this so it much more acceptable rate of special cases than the 2.5% above. > > > [this bit used to quote the definition of LIST_HEAD() ;-) ] > > 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). > > I think compilers give objects at least one byte of space, so that two > different objects get different addresses, and don't compare equal. > > That said, I'm not seeing your issue. list_traversal_head() is a > union, and always has that 'struct list_head' in it, and that's the > biggest part of the union. Perhaps its a bit overblown for the safe of a few kilobytes (even if there were two traversal types members) but I was wondering if there is any cunning trick for LIST_HEAD() since we cannot have an anonymous union outside a struct. In short, is this the best we can do for LIST_TRAVERSE_HEAD(): #define LIST_TRAVERSE_HEAD(type, name, target_member) \ type * name##_traversal_type; \ struct list_head name = LIST_HEAD_INIT(name) #define STATIC_LIST_TRAVERSE_HEAD(type, name, target_member) \ static type * name##_traversal_type; \ static list_head name = LIST_HEAD_INIT(name) Daniel.