Re: [PATCH v2 2/2] mm: madvise: no-op for MADV_NOHUGEPAGE if THP is disabled

[Yang Shi <yang@os.amperecomputing.com>]

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/