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 02:45:12 +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 2:42 keltezéssel, Linus Torvalds írta:
> On Thu, Mar 10, 2022 at 5:33 PM Barnabás Pőcze <pobrn@...tonmail.com> wrote:
> >
> > The underlying idea is to define each list head using an anonymous struct:
>
> Why struct? Union is much better, and doesn't pointlessly waste memory
> for members that are only used for their type.

As far as I can tell, zero-sized arrays won't take up any space. It's true
that if the type has excessive alignment requirements, then it may indeed
waste space. Changing it to a pointer+union is a simple change, nonetheless.

>
> Anyway, as far as I can tell, your model is unworkable as-is, since it
> only works for a list that is external to the types in question.
>
> Which is not even remotely the interesting case. All serious list uses
> are inside other types, and refer to each other.
>
> So this seems to be fundamentally broken, in that it only works for
> trivial things, and is not even as good as
>
>    https://lore.kernel.org/all/CAHk-=wiacQM76xec=Hr7cLchVZ8Mo9VDHmXRJzJ_EX4sOsApEA@mail.gmail.com/
>
> that actually converted a real case.
>
> 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.
>
> Again, you avoided those problems by making the use-case a narrow and
> uninteresting one.

Yes, I have mentioned at the end that there are limitations of this approach
(to keep it easy to use and sane) and that it won't work everywhere,
namely where the value type is incomplete. E.g.
  * you cannot have a list of T inside a T;
  * you cannot have a list of B inside A plus a list of A inside B.

Nonetheless, I still think there are legitimate use cases for this, where
the simple, limited interface works fine. And I am by no means suggesting
not going forward with the other ideas that came up. I mostly imagined this
tlist as an "addition" for the simple, trivial cases.

For example, there are currently more than 1000 occurrences of

  static LIST_HEAD(

in the source tree. I did not check, but I think it's very likely that most of
them would satisfy the constraints of the proposed interface. And while I cannot
provide any numbers, I would not be surprised if most list uses in the kernel were
"boring" and "trivial", where this interface would work.

But I understand if you don't want something that doesn't work for every case.

Best regards,
Barnabás Pőcze