From: Usama Arif <usamaarif642@gmail.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
david@redhat.com, linux-mm@kvack.org, hannes@cmpxchg.org,
shakeel.butt@linux.dev, riel@surriel.com, ziy@nvidia.com,
laoar.shao@gmail.com, baolin.wang@linux.alibaba.com,
Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com,
vbabka@suse.cz, jannh@google.com, Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH v3 1/7] mm: khugepaged: extract vm flag setting outside of hugepage_madvise
Date: Tue, 20 May 2025 16:13:27 +0100 [thread overview]
Message-ID: <fbff5bdb-989f-471a-9793-934aef4f8c71@gmail.com> (raw)
In-Reply-To: <ad5b93bf-24e6-4b15-9c0d-5c501c74de86@gmail.com>
On 20/05/2025 15:57, Usama Arif wrote:
>
>
> On 20/05/2025 15:43, Lorenzo Stoakes wrote:
>> This commit message is really poor. You're also not mentioning that you're
>> changing s390 behaviour?
>>
>> On Mon, May 19, 2025 at 11:29:53PM +0100, Usama Arif wrote:
>>> This is so that flag setting can be resused later in other functions,
>>
>> Typo.
>>
>>> to reduce code duplication (including the s390 exception).
>>>
>>> No functional change intended with this patch.
>>
>> I'm pretty sure somebody reviewed that this should just be merged with whatever
>> uses this? I'm not sure this is all that valuable as you're not really changing
>> this structurally very much.
>>
>
So I unfortunately never tested s390 build which the kernel bot is complaining.
So If I want to reuse hugepage_set_vmflags in patch 2 and 3 for the prctls,
the fix over here would be at the end.
If you don't like the approach of trying to abstract the flag setting away
and reusing it in prctl in this patch I can change it to the way in previous
revision and just do something like below. Happy with either approach and
can drop patch 1 if you prefer.
+ case PR_SET_THP_POLICY:
+ if (arg3 || arg4 || arg5)
+ return -EINVAL;
+ if (mmap_write_lock_killable(me->mm))
+ return -EINTR;
+ switch (arg2) {
+ case PR_DEFAULT_MADV_HUGEPAGE:
+ if (!hugepage_global_enabled())
+ error = -EPERM;
+#ifdef CONFIG_S390
+ /*
+ * qemu blindly sets MADV_HUGEPAGE on all allocations, but s390
+ * can't handle this properly after s390_enable_sie, so we simply
+ * ignore the madvise to prevent qemu from causing a SIGSEGV.
+ */
+ else if (mm_has_pgste(vma->vm_mm))
+ error = -EPERM;
+#endif
+ else {
+ me->mm->def_flags &= ~VM_NOHUGEPAGE;
+ me->mm->def_flags |= VM_HUGEPAGE;
+ process_default_madv_hugepage(me->mm, MADV_HUGEPAGE);
+ }
+ break;
+ default:
+ error = -EINVAL;
+ }
+ mmap_write_unlock(me->mm);
+ break;
Thanks!
diff for fixing this patch:
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index b24a2e0ae642..e5176afaaffe 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -432,7 +432,7 @@ change_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
} while (0)
void process_default_madv_hugepage(struct mm_struct *mm, int advice);
-int hugepage_set_vmflags(unsigned long *vm_flags, int advice);
+int hugepage_set_vmflags(struct mm_struct* mm, unsigned long *vm_flags, int advice);
int hugepage_madvise(struct vm_area_struct *vma, unsigned long *vm_flags,
int advice);
int madvise_collapse(struct vm_area_struct *vma,
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index ab3427c87422..b6c9ed6bb442 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -346,7 +346,7 @@ struct attribute_group khugepaged_attr_group = {
};
#endif /* CONFIG_SYSFS */
-int hugepage_set_vmflags(unsigned long *vm_flags, int advice)
+int hugepage_set_vmflags(struct mm_struct * mm, unsigned long *vm_flags, int advice)
{
switch (advice) {
case MADV_HUGEPAGE:
@@ -356,8 +356,8 @@ int hugepage_set_vmflags(unsigned long *vm_flags, int advice)
* can't handle this properly after s390_enable_sie, so we simply
* ignore the madvise to prevent qemu from causing a SIGSEGV.
*/
- if (mm_has_pgste(vma->vm_mm))
- return -EPERM;
+ if (mm_has_pgste(mm))
+ return 0;
#endif
*vm_flags &= ~VM_NOHUGEPAGE;
*vm_flags |= VM_HUGEPAGE;
@@ -373,13 +373,14 @@ int hugepage_set_vmflags(unsigned long *vm_flags, int advice)
break;
}
- return 0;
+ return 1;
}
int hugepage_madvise(struct vm_area_struct *vma,
unsigned long *vm_flags, int advice)
{
- if (advice == MADV_HUGEPAGE && !hugepage_set_vmflags(vm_flags, advice)) {
+ if (hugepage_set_vmflags(vma->vm_mm, vm_flags, advice)
+ && advice == MADV_HUGEPAGE) {
/*
* If the vma become good for khugepaged to scan,
* register it here without waiting a page fault that
next prev parent reply other threads:[~2025-05-20 15:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 22:29 [PATCH v3 0/7] prctl: introduce PR_SET/GET_THP_POLICY Usama Arif
2025-05-19 22:29 ` [PATCH v3 1/7] mm: khugepaged: extract vm flag setting outside of hugepage_madvise Usama Arif
2025-05-20 9:51 ` kernel test robot
2025-05-20 14:43 ` Lorenzo Stoakes
2025-05-20 14:57 ` Usama Arif
2025-05-20 15:13 ` Usama Arif [this message]
2025-05-20 15:31 ` Lorenzo Stoakes
2025-05-19 22:29 ` [PATCH v3 2/7] prctl: introduce PR_DEFAULT_MADV_HUGEPAGE for the process Usama Arif
2025-05-19 23:01 ` Jann Horn
2025-05-20 5:23 ` Lorenzo Stoakes
2025-05-20 9:09 ` David Hildenbrand
2025-05-20 9:16 ` Lorenzo Stoakes
2025-05-20 8:48 ` kernel test robot
2025-05-19 22:29 ` [PATCH v3 3/7] prctl: introduce PR_DEFAULT_MADV_NOHUGEPAGE " Usama Arif
2025-05-19 22:29 ` [PATCH v3 4/7] prctl: introduce PR_THP_POLICY_SYSTEM " Usama Arif
2025-05-19 22:29 ` [PATCH v3 5/7] selftests: prctl: introduce tests for PR_DEFAULT_MADV_NOHUGEPAGE Usama Arif
2025-05-19 22:29 ` [PATCH v3 6/7] selftests: prctl: introduce tests for PR_THP_POLICY_DEFAULT_HUGE Usama Arif
2025-05-19 22:29 ` [PATCH v3 7/7] docs: transhuge: document process level THP controls Usama Arif
2025-05-20 5:14 ` [PATCH v3 0/7] prctl: introduce PR_SET/GET_THP_POLICY Lorenzo Stoakes
2025-05-20 7:46 ` Usama Arif
2025-05-20 8:51 ` Lorenzo Stoakes
2025-05-21 2:33 ` Liam R. Howlett
2025-05-21 9:31 ` Usama Arif
2025-05-21 16:37 ` Liam R. Howlett
2025-05-22 12:10 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fbff5bdb-989f-471a-9793-934aef4f8c71@gmail.com \
--to=usamaarif642@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=jannh@google.com \
--cc=kernel-team@meta.com \
--cc=laoar.shao@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=npache@redhat.com \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=vbabka@suse.cz \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).