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

[William Kucharski <william.kucharski@linux.dev>]

(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@kernel.org> 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@kernel.org/
>>> 
>>> 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
>