linux-kernel - Re: THP backed thread stacks

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:   Fri, 10 Mar 2023 12:25:38 +0100
From:   David Hildenbrand <david@...hat.com>
To:     William Kucharski <william.kucharski@...cle.com>,
        Zach O'Keefe <zokeefe@...gle.com>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        Peter Xu <peterx@...hat.com>, Rik van Riel <riel@...riel.com>,
        Mike Rapoport <rppt@...nel.org>, Linux-MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: THP backed thread stacks

On 10.03.23 02:40, William Kucharski wrote:
> 
> 
>> On Mar 9, 2023, at 17:05, Zach O'Keefe <zokeefe@...gle.com> wrote:
>>
>>> I think the hugepage alignment in their environment was somewhat luck.
>>> One suggestion made was to change stack size to avoid alignment and
>>> hugepage usage.  That 'works' but seems kind of hackish.
>>
>> That was my first thought, if the alignment was purely due to luck,
>> and not somebody manually specifying it. Agreed it's kind of hackish
>> if anyone can get bit by this by sheer luck.
> 
> I don't agree it's "hackish" at all, but I go more into that below.
> 
>>
>>> Also, David H pointed out the somewhat recent commit to align sufficiently
>>> large mappings to THP boundaries.  This is going to make all stacks huge
>>> page aligned.
>>
>> I think that change was reverted by Linus in commit 0ba09b173387
>> ("Revert "mm: align larger anonymous mappings on THP boundaries""),
>> until it's perf regressions were better understood -- and I haven't
>> seen a revamp of it.
> 
> It's too bad it was reverted, though I understand the concerns regarding it.
> 
>  From my point of view, if an address is properly aligned and a caller is
> asking for 2M+ to be mapped, it's going to be advantageous from a purely
> system-focused point of view to do that mapping with a THP. 

Just noting that, if user space requests multiple smaller mappings, and 
the kernel decides to all place them in the same PMD, all VMAs might get 
merged and you end up with a properly aligned VMA where khugepaged would 
happily place a THP.

That case is, of course, different to the "user space asks for 2M+" 
mapping case, but from khugepaged perspective they might look alike -- 
and it might be unclear if a THP is valuable or not (IOW maybe that THP 
could be better used somewhere else).

-- 
Thanks,

David / dhildenb