linux-kernel - Re: [PATCH v1 05/15] mm/rmap: convert RMAP flags to a proper distinct rmap

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]

Date:   Tue, 8 Mar 2022 10:09:00 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nadav Amit <namit@...are.com>
Cc:     David Hildenbrand <david@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        David Rientjes <rientjes@...gle.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        John Hubbard <jhubbard@...dia.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Yang Shi <shy828301@...il.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        Michal Hocko <mhocko@...nel.org>,
        Rik van Riel <riel@...riel.com>,
        Roman Gushchin <guro@...com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Peter Xu <peterx@...hat.com>,
        Donald Dutile <ddutile@...hat.com>,
        Christoph Hellwig <hch@....de>,
        Oleg Nesterov <oleg@...hat.com>, Jan Kara <jack@...e.cz>,
        Liang Zhang <zhangliang5@...wei.com>,
        Pedro Gomes <pedrodemargomes@...il.com>,
        Oded Gabbay <oded.gabbay@...il.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v1 05/15] mm/rmap: convert RMAP flags to a proper distinct
 rmap_t type

On Tue, Mar 8, 2022 at 9:15 AM Nadav Amit <namit@...are.com> wrote:
>
> It would be much easier to read. The last time I made such a suggestion,
> Ingo said "I personally like bitfields in theory … [but] older versions of
> GCC did a really poor job of optimizing them.”

Yeah, even not that old versions had serious issues, iirc.

Bitfields can look nice, but they have some _serious_ syntax issues.
In particular, they are nice when you want to *test* one single field
(ie bit in this case), but basically atrociously bad in almost all
other circumstances.

For example, passing a bitfield aggregate as an argument is just
crazy. Oh, you can do it, with syntax like

    (struct type) { .field1 = 1, .field3 = 1 }

as the argument but when you say "much easier to read" I laugh in your
face and call your mother a hamster.

And that's ignoring all the issues when you want to combine two
bitfields. You can't do it. There is nothing like the binary "or"
operator. Again, it's easy to modify *one* field, but taking two
bitfields and merging them? Not going to happen.

So no. Bitfields have their place, but they are close to useless as
"flags" type things that get passed around as arguments, unless you
have very very specific and limited use.

                              Linus