include/linux/huge_mm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
huge_anon_orders_always and huge_anon_orders_always are accessed
lockless, it is better to use the READ_ONCE() wrapper.
This is not fixing any visible bug, hopefully this can cease some
KCSAN complains in the future.
Also do that for huge_anon_orders_madvise.
Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
---
include/linux/huge_mm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index de0c89105076..6573430ea600 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -122,8 +122,8 @@ static inline bool hugepage_flags_enabled(void)
* So we don't need to look at huge_anon_orders_inherit.
*/
return hugepage_global_enabled() ||
- huge_anon_orders_always ||
- huge_anon_orders_madvise;
+ READ_ONCE(huge_anon_orders_always) ||
+ READ_ONCE(huge_anon_orders_madvise);
}
static inline int highest_order(unsigned long orders)
--
2.15.2
On Sat, May 11, 2024 at 12:44 AM <xu.xin16@zte.com.cn> wrote: > > From: Ran Xiaokai <ran.xiaokai@zte.com.cn> > > huge_anon_orders_always and huge_anon_orders_always are accessed > lockless, it is better to use the READ_ONCE() wrapper. > This is not fixing any visible bug, hopefully this can cease some > KCSAN complains in the future. A little bit confused here. Did you see complaints from KCSAN? > Also do that for huge_anon_orders_madvise. > > Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn> > --- > include/linux/huge_mm.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index de0c89105076..6573430ea600 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -122,8 +122,8 @@ static inline bool hugepage_flags_enabled(void) > * So we don't need to look at huge_anon_orders_inherit. > */ > return hugepage_global_enabled() || > - huge_anon_orders_always || > - huge_anon_orders_madvise; > + READ_ONCE(huge_anon_orders_always) || > + READ_ONCE(huge_anon_orders_madvise); > } > > static inline int highest_order(unsigned long orders) > -- > 2.15.2
>> >> From: Ran Xiaokai <ran.xiaokai@zte.com.cn> >> >> huge_anon_orders_always and huge_anon_orders_always are accessed >> lockless, it is better to use the READ_ONCE() wrapper. >> This is not fixing any visible bug, hopefully this can cease some >> KCSAN complains in the future. > > A little bit confused here. Did you see complaints from KCSAN? Not yet. The only written access to huge_anon_orders_always is when changing the mTHP sysfs "enabled" knob, I think peple do not change the mTHP settings frequently. But the possibility is not zero, please refer to the cgroup related knobs, I think wde'd better do the same and this annotation wont lead to any performance issue, right? >> Also do that for huge_anon_orders_madvise. >> >> Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn> >> --- >> include/linux/huge_mm.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >> index de0c89105076..6573430ea600 100644 >> --- a/include/linux/huge_mm.h >> +++ b/include/linux/huge_mm.h >> @@ -122,8 +122,8 @@ static inline bool hugepage_flags_enabled(void) >> * So we don't need to look at huge_anon_orders_inherit. >> */ >> return hugepage_global_enabled() || >> - huge_anon_orders_always || >> - huge_anon_orders_madvise; >> + READ_ONCE(huge_anon_orders_always) || >> + READ_ONCE(huge_anon_orders_madvise); >> } >> >> static inline int highest_order(unsigned long orders)
On 11.05.24 08:44, xu.xin16@zte.com.cn wrote: > From: Ran Xiaokai <ran.xiaokai@zte.com.cn> > > huge_anon_orders_always and huge_anon_orders_always are accessed "huge_anon_orders_always" mentioned twice. > lockless, it is better to use the READ_ONCE() wrapper. > This is not fixing any visible bug, hopefully this can cease some > KCSAN complains in the future. > Also do that for huge_anon_orders_madvise. > > Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn> > --- > include/linux/huge_mm.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index de0c89105076..6573430ea600 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -122,8 +122,8 @@ static inline bool hugepage_flags_enabled(void) > * So we don't need to look at huge_anon_orders_inherit. > */ > return hugepage_global_enabled() || > - huge_anon_orders_always || > - huge_anon_orders_madvise; > + READ_ONCE(huge_anon_orders_always) || > + READ_ONCE(huge_anon_orders_madvise); Don't mess up the alignment please. > } > > static inline int highest_order(unsigned long orders) Acked-by: David Hildenbrand <david@redhat.com> -- Cheers, David / dhildenb
Hi, David Thanks for taking time to review! >> From: Ran Xiaokai <ran.xiaokai@zte.com.cn> >> >> huge_anon_orders_always and huge_anon_orders_always are accessed > > "huge_anon_orders_always" mentioned twice. yes, my mistake. >> lockless, it is better to use the READ_ONCE() wrapper. >> This is not fixing any visible bug, hopefully this can cease some >> KCSAN complains in the future. >> Also do that for huge_anon_orders_madvise. >> >> Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn> >> --- >> include/linux/huge_mm.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >> index de0c89105076..6573430ea600 100644 >> --- a/include/linux/huge_mm.h >> +++ b/include/linux/huge_mm.h >> @@ -122,8 +122,8 @@ static inline bool hugepage_flags_enabled(void) >> * So we don't need to look at huge_anon_orders_inherit. >> */ >> return hugepage_global_enabled() || >> - huge_anon_orders_always || >> - huge_anon_orders_madvise; >> + READ_ONCE(huge_anon_orders_always) || >> + READ_ONCE(huge_anon_orders_madvise); > > Don't mess up the alignment please. yes. I will wait for other feedbacks and then send out a v2 version. >> } >> >> static inline int highest_order(unsigned long orders) > > Acked-by: David Hildenbrand <david@redhat.com>
© 2016 - 2025 Red Hat, Inc.