linux-kernel - Re: [PATCH v2 2/2] mm: madvise: no-op for MADV

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]

Message-ID: <0856412f-048e-4698-bd9d-83393fe93ec5@os.amperecomputing.com>
Date: Wed, 7 May 2025 08:57:07 -0700
From: Yang Shi <yang@...amperecomputing.com>
To: Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez@...a.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2 2/2] mm: madvise: no-op for MADV_NOHUGEPAGE if THP is
 disabled



On 5/7/25 4:44 AM, Ignacio Moreno Gonzalez wrote:
> This patch resulted from the discussion on [0]. The issue I described there consisted of two aspects:
>
>    - CRIU saw a memory mapping containing the "nh" flag on a !THP kernel. This was addressed by my submission.
>    - CRIU tried to set the "nh" flag with madvise(), which resulted on -EINVAL.
>
> The issue is actually solved with the patch I submitted. But it was also discussed that calling madvise() with VM_NOHUGEPAGE should be a no-op and should not fail. That's why this patch was created.
>
> On 5/7/2025 1:40 AM, Andrew Morton wrote:
>>> +#ifndef CONFIG_TRANSPARENT_HUGEPAGE
>>> +#include <uapi/asm-generic/mman-common.h>
>>> +#endif
>> Why is the #ifndef here?
> Because this is only included for the definition of VM_NOHUGEPAGE, which is only needed for the !THP case.

Can you just simply include <linux/mman.h> ?

Thanks,
Yang

>> This is the only file under include/linux which directly includes
>> something from uapi/asm-generic.  Indicates that we're doing something
>> wrong.
> If we want to differentiate the behavior of hugepage_madvise() depending on the advice, then we need the definitions for the different advices... Maybe this is not the correct place to do this? We could also do that differentiation in madvise.c.
>
>> If this hunk is truly the correct approach then I think we need a
>> comment here fully explaining what is going on.   Because it looks odd!
> To me, differentiating the behaviour of madvise() for MADV_HUGEPAGE and MADV_NOHUGEPAGE seems ok, and that was also the consensus on [0]. However, I lack the expertise to determine if this is the best place in the code to implement this change. Perhaps Lorenzo or Matthew can provide feedback here.
>
>
> [0]: https://lore.kernel.org/linux-mm/20250502-map-map_stack-to-vm_nohugepage-only-if-thp-is-enabled-v1-1-113cc634cd51@kuka.com/