Hi Suren
On 2026/11/12 08:16, Suren Baghdasaryan wrote:
> On Tue, Nov 10, 2026 at 11:24 AM Hao Ge <[email protected]> wrote:
>>
>> The pte loop of vmap_pages_pte_range() maps whole pages and stops
>> only when addr lands exactly on end. An unaligned end lets addr
>> jump over it and the loop keeps mapping into whatever follows the
>> range. An unaligned start maps the page below the range with its
>> first pte. That corruption is impossible to debug afterwards, so
>> bug out on addr and end at the entry of
>> vmap_pages_range_noflush_walk().
>>
>> Reported-by: Sashiko <[email protected]>
>> Signed-off-by: Hao Ge <[email protected]>
>> ---
>> mm/vmalloc.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index 27f2674a5556..86fbb1d2b27a 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -698,6 +698,8 @@ static int vmap_pages_range_noflush_walk(unsigned long
>> addr, unsigned long end,
>> pgtbl_mod_mask mask = 0;
>>
>> BUG_ON(addr >= end);
>> + BUG_ON(!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(end));
>
> Instead of BUG_ON() here can we error out early in this function's
> callers (with or without a warning)? This is a static function with
> only 2 callers. vmap_pages_range_batched() uses it in a loop but I
> believe if we check the original address alignment then consequent
> calls are guaranteed to have aligned addresses.
>
One thing that worries me about checking in the callers, a new caller
of the walk can simply forget.
If we take the approach raised after my patch 3, handling the
unaligned range with WARN instead of BUG, I am happy to do the WARN
here. Even the BUG_ON(addr >= end) above it can become WARN, because
it only fails this mapping. If the module is not that important, we
can ignore it and let the system keep going.
Thanks
Best Regards
Hao
>> +
>> pgd = pgd_offset_k(addr);
>> do {
>> next = pgd_addr_end(addr, end);
>> --
>> 2.25.1
>>
