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: Tue, 14 May 2024 08:03:12 +0000
From: ran xiaokai <ranxiaokai627@....com>
To: shy828301@...il.com
Cc: akpm@...ux-foundation.org,
	david@...hat.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	willy@...radead.org,
	xu.xin16@....com.cn,
	ziy@...dia.com
Subject: Re:  [PATCH linux-next] mm/huge_memory: mark racy access on huge_anon_orders_always

>>
>> From: Ran Xiaokai <ran.xiaokai@....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@....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)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ