linux-kernel - Re: ksm: initialize rmap values directly and make them const

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: <e1c00847-0f97-4ef2-9d7b-5ffaaff62c0c@kernel.org>
Date: Fri, 6 Feb 2026 09:46:40 +0100
From: "David Hildenbrand (Arm)" <david@...nel.org>
To: xu.xin16@....com.cn
Cc: akpm@...ux-foundation.org, chengming.zhou@...ux.dev, hughd@...gle.com,
 wang.yaxin@....com.cn, yang.yang29@....com.cn, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: ksm: initialize rmap values directly and make them const

On 2/6/26 09:38, xu.xin16@....com.cn wrote:
>>> Considering that commit 06fbd555dea8 ("ksm: optimize rmap_walk_ksm by passing
>>> a suitable addressrange") seems to have already been merged, this new patch is
>>> proposed to address the issue raised by David at:
>>>
>>> https://lore.kernel.org/all/ba03780a-fd65-4a03-97de-bc0905106260@kernel.org/
>>>
>>> This initialize rmap values (addr, pgoff_start, pgoff_end) directly and
>>> make them const to make code more robust. Besides, since KSM folios are always
>>> order-0, so folio_nr_pages(KSM folio) is always 1, so the line:
>>>
>>> 	"pgoff_end = pgoff_start + folio_nr_pages(folio) - 1;"
>>>
>>> becomes directly:
>>>
>>> 	"pgoff_end = pgoff_start;"
>>>
>>> The test reproducer of rmap_walk_ksm can be found at:
>>> https://lore.kernel.org/all/20260206151424734QIyWL_pA-1QeJPbJlUxsO@zte.com.cn/
>>
>> Thanks!
>>
>>>
>>> Fixes: 06fbd555dea8 ("ksm: optimize rmap_walk_ksm by passing a suitable addressrange")
>>> Signed-off-by: xu xin <xu.xin16@....com.cn>
>>
>> The patch does not seem to be upstream / in mm-stable yet.
>>
>> Can you resend the original patch with these changes included and the
>> reproducer referenced in the updated patch description?
> 
> Sure, I thought the original patch was merged in linux-next.

linux-next is just an integration tree.

What you want to look out for is whether the patch ended up in mm-stable 
or mm-hotfixes-stable

	git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git

As long as it's not in there (1) the commit id is not stable; and (2) we 
can still modify it.

-- 
Cheers,

David