Re: [PATCH 2/3] mm: add bytes_to_page_end() helper

From: William Kucharski

Date: Mon May 18 2026 - 07:58:16 EST


(My apologies for the earlier HTML encoding.)

As with Lorenzo's concerns, my biggest issue with this change is that it
becomes unclear what "page" means in this context.

Is it a base PAGE_SIZE page? A 2 MB "large" page? A 1 GB "huge" page on
architectures that support it?

The "rest_of_page()" macro masks that distinction, where the current code’s
explicit reference to PAGE_SIZE makes the basis of the calculation obvious.

I don’t see why we would want to obscure that behind a macro, especially
when it makes the code harder to follow.

Thanks,
Bill

> On May 18, 2026, at 04:23, Lorenzo Stoakes <ljs@xxxxxxxxxx> wrote:
>
> On Mon, May 18, 2026 at 09:48:32AM +0300, Andy Shevchenko wrote:
>> On Sun, May 17, 2026 at 11:28:05AM -0400, Yury Norov wrote:
>>> On Sun, May 17, 2026 at 02:34:30PM +0200, Thorsten Blum wrote:
>>
>> ...
>>
>>> I've got a series for this
>>>
>>> https://lore.kernel.org/all/20260303182845.250bb2de@xxxxxxxxxx/
>>>
>>> The feedback is surprisingly negative. Please add people from that
>>> thread. Maybe you'll be more successful convincing them.
>
> There's a cost to adding yet more super-specific headers where stuff gets hidden
> and people don't know where to put what, things quickly become a mess and header
> dependencies are already a nightmare.
>
> Also in the case of this helper, I don't see the value in adding a vague,
> untyped, confusingly-named macro when PAGE_SIZE - offset_in_page() is perfectly
> cromulent and clear in what it's doing?
>
>>
>> We always can simply fork, but I truly do not understand the pushback.
>
> Well, be my guest? This isn't a hugely helpful or friendly comment.
>
>> These are simple macros that are way spread in the kernel, "include everything"
>> kinda linux/mm.h is not needed in vast majority of the users, hence the
>> split is logical step.
>
> Right but that's completely orthogonal to adding this macro?
>
> I'm fine with moving offset_in_page() to e.g. mm_types.h.
>
> But a series that doesn't even give any actual motivation for the change is not
> convicing, and we aren't required to just accept any change.
>
>>
>> I'm in favour of this series.
>
> OK, I'm not :)
>
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>>
>
> Thanks, Lorenzo
>