linux-kernel - Re: [RFC PATCH v1 1/2] list: add type-safer list

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Mar 2022 22:15:23 +0000
From:   Barnabás Pőcze <pobrn@...tonmail.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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

Hi


2022. március 11., péntek 6:06 keltezéssel, Linus Torvalds írta:
> On Thu, Mar 10, 2022 at 6:49 PM Barnabás Pőcze <pobrn@...tonmail.com> wrote:
> >
> > 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` member
> > is inside a subobject, for example, so `member` now contains a period.
>
> Ahh, very true. And very annoying. So close, yet so far, and no way I
> can see to really deal with that.
>
> And it's not even really all that rare. It may not be the _common_
> case, but it's still fairly wide-spread and not some "one or two odd
> places" thing.
>
> This grep catches at least a subset of cases:
>
>     git grep '\<list_for_each_entry(.*\.[a-z_0-9]*)'
>
> and it's clearly all over.
>
> As mentioned, I don't think that we have had huge problems with
> getting the member name wrong. We do get a fair amount of checking in
> that it obviously has to be part of the type we iterate over, and even
> if you were to pick the wrong one, the result is a very simple "that
> doesn't work".
>
> But it would still undeniably be very nice to have some automatic
> build-time checking for it.
>

Yes, I think compile-time errors are significantly better than whatever you get
at runtime. So, sorry to be this obtuse, but I gather the proposed interface
is a no-go in all ways, shapes, and forms in your eyes? I am fully aware that it
does not magically solve everything and it does not work in the "interesting"
and "convoluted" cases, but as mentioned in a previous email, I think there are
still a lot of "boring" places where it can be used. But of course I don't want
to bother anyone if it's a definitive no.


> [...]


Regards,
Barnabás Pőcze