Re: [PATCH v5] ksm: use range-walk function to jump over holes in scan_get_next_rmap_item

[Pedro Demarchi Gomes]

On 10/23/25 07:13, David Hildenbrand wrote:
> As a note, we have similar code that should probably be doing a range walk instead: unmerge_ksm_pages()->break_ksm().
>
> It can be triggered on a range through unmerge_ksm_pages(), which gets called from:
>
> * ksm_madvise() through madvise(MADV_UNMERGEABLE).  There are not a lot of users of that function.
>
> * __ksm_del_vma() through ksm_del_vmas(). Effectively called when disabling KSM for a process either through the sysctl or from s390x gmap code when enabling storage keys for a VM.
>
> In both cases, it's not ksmd that's blocked, it's just that the operation (trigger by the app) takes longer.
>
> So both are not as critical as this thing here, but likely we should take care of it at some point.
>
> Interestingly, I converted that from a walk_page_range_vma() to folio_walk_start() after converting it from follow_page() to walk_page_range_vma().
>
> But we never did a range walk, we just walked individual addresses, because that's what break_ksm() does.
>
> We could effectively revert e317a8d8b4f600fc7ec9725e26417030ee594f52 and adjust it to perform an actual range walk by passing a range to break_ksm(). 


Thanks for letting me know. I will send a patch fixing this issue.