linux-kernel - Re: [PATCH] mm: remove offset check on page->compound

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:   Thu, 27 Jan 2022 16:42:10 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Wei Yang <richard.weiyang@...il.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        peterz@...radead.org, will@...nel.org, linyunsheng@...wei.com,
        aarcange@...hat.com, feng.tang@...el.com, ebiederm@...ssion.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: remove offset check on page->compound_head and
 folio->lru

On 1/27/22 02:10, Wei Yang wrote:
> On Tue, Jan 25, 2022 at 11:11:40AM +0100, Vlastimil Babka wrote:
>>On 1/24/22 23:55, Wei Yang wrote:
>>> On Mon, Jan 24, 2022 at 11:30:10AM +0100, Vlastimil Babka wrote:
>>>>On 1/23/22 02:38, Wei Yang wrote:
>>>>
>>>>I can offer my insight (which might be of course wrong). Ideally one day
>>>>page.lru will be gone and only folio will be used for LRU pages. Then there
>>>>won't be a  FOLIO_MATCH(lru, lru); and FOLIO_MATCH(compound_head, lru);
>>>>won't appear to be redundant anymore. lru is list_head so two pointers and
>>> 
>>> Thanks for your comment.
>>> 
>>> I can't imagine the final result. If we would remove page.lru, we could remove
>>> FOLIO_MATCH(lru, lru) and add FOLIO_MATCH(compound_head, lru) at that moment?
>>
>>Yes, or we could forget to do it. Adding it right now is another option that
>>Matthew has chosen and I don't see a strong reason to change it. Can you
>>measure a kernel build speedup thanks to removing the now redundant check?
>>
> 
> If we forget to do it, the compile would fail, right?

No, FOLIO_MATCH is like a build-time assert. It can only fail if the assert
is there, and the condition evaluates to false.
If it's not there and the condition is false, it will instead mysteriously
crash on runtime, which is worse.

> Put it here for a future reason is not persuasive.
> 
>>>>thus valid pointers are aligned in such a way they can't accidentaly set the
>>>>bit 0.
>>>>
>>> 
>