Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Mar 2022 02:49:40 +0000
To:     Linus Torvalds <torvalds@linux-foundation.org>
From:   =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= <pobrn@protonmail.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Xiaomeng Tong <xiam0nd.tong@gmail.com>,
        Kees Cook <keescook@chromium.org>,
        Jakob Koschel <jakobkoschel@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>
Reply-To: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= <pobrn@protonmail.com>
Subject: Re: [RFC PATCH v1 1/2] list: add type-safer list_head wrapper
Message-ID: <wKlkWvCGvBrBjshT6gHT23JY9kWImhFPmTKfZWtN5Bkv_OtIFHTy7thr5SAEL6sYDthMDth-rvFETX-gCZPPCb9t2bO1zilj0Q-OTTSbe00=@protonmail.com>
In-Reply-To: <CAHk-=wjF4d_v5t=ht_vCOHxNDoPvsBuK-2jiEBus-__oPZuPFQ@mail.gmail.com>
References: <20220311013238.3387227-1-pobrn@protonmail.com> <20220311013238.3387227-2-pobrn@protonmail.com> <CAHk-=wjkqz42CNjDgWA9U3uNWa9GriqaCqqKciqm0sZUYjfLQg@mail.gmail.com> <CAHk-=wjF4d_v5t=ht_vCOHxNDoPvsBuK-2jiEBus-__oPZuPFQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi


2022. m=C3=A1rcius 11., p=C3=A9ntek 3:01 keltez=C3=A9ssel, Linus Torvalds =
=C3=ADrta:
> On Thu, Mar 10, 2022 at 5:42 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > That one didn't do the automatic offset thing, but see
> >
> >    https://lore.kernel.org/all/CAADWXX-Pr-D3wSr5wsqTEOBSJzB9k7bSH+7hnCA=
j0AeL0=3DU4mg@mail.gmail.com/
> >
> > on the problems that has.
>
> Note: I think the problems are serious enough that it almost certainly
> isn't worth doing - it makes the code uglier for very little upside.
>
> So I tried to explain how it _could_ be done, but that doesn't mean
> that it _should_ be done.
>
> Having the member name as part of the list traversal macro isn't
> actually generally a real problem.
>
> I added it to the list_traversal_head() macro in that original patch
> because I think we can easily use the member head name to _verify_
> that the declaration and the use match.
>
> Yes, squirrelling  off the offset and not needing the member head name
> at all at when traversing the list is obviously simpler syntax, but
> that part has never been the real problem with list traversal. And
> verifying that the member name that is passed in is the same as in the
> list_traversal_head() would be trivial.
>
> To verify it, we could simply change that type name from:
>
>      type *name##_traversal_type;
>
> to be
>
>      type *name##_traversal_type_##member;
>
> instead, and suddenly the member name in 'list_traverse()' has to
> match that thing that list_traversal_head() created.
>
> So yes, you'd have that third argument in list_traverse(), but it
> would be trivially checked at compile-time.

That is indeed a simpler thing to do, and doesn't need `offsetof()` at the
declaration, but there are places - not many -  where the `list_head` membe=
r
is inside a subobject, for example, so `member` now contains a period.


>
> And you'd avoid all the ugly complexities (described above) with lists
> that are embedded inside data structures that refer to each other)


Regards,
Barnab=C3=A1s P=C5=91cze