lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjF4d_v5t=ht_vCOHxNDoPvsBuK-2jiEBus-__oPZuPFQ@mail.gmail.com>
Date:   Thu, 10 Mar 2022 18:01:56 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Barnabás Pőcze <pobrn@...tonmail.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Xiaomeng Tong <xiam0nd.tong@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Jakob Koschel <jakobkoschel@...il.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [RFC PATCH v1 1/2] list: add type-safer list_head wrapper

On Thu, Mar 10, 2022 at 5:42 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> That one didn't do the automatic offset thing, but see
>
>    https://lore.kernel.org/all/CAADWXX-Pr-D3wSr5wsqTEOBSJzB9k7bSH+7hnCAj0AeL0=U4mg@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.

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

                  Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ