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

[Thomas Weißschuh]

On Mon, May 18, 2026 at 04:41:38PM +0200, David Hildenbrand (Arm) wrote:
> On 5/18/26 16:29, Thomas Weißschuh wrote:
> > On Mon, May 18, 2026 at 02:15:50PM +0100, Lorenzo Stoakes wrote:
> >> On Mon, May 18, 2026 at 03:06:16PM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> I think I'd prefer vdso/page.h for something as basic as that.
> >>>
> >>> But definitely no new header unless really unavoidable :)
> >>
> >> I just find vdso/page.h an extremely weird beast. what does the VDSO have to do
> >> with it and why are we smuggling some basic definitions there...
> > 
> > The idea behind the vdso/ header namespace is that it can be used from
> > vDSO userspace code. A weird middleground between linux/*.h and uapi/linux/*.h.
> > Also in a compat vDSO anything depending on BITS_PER_LONG is wrong, and instead
> > __BITS_PER_LONG needs to be used. A bunch of kconfig settings, like
> > CONFIG_64BIT can also be off. Additionally internal kernel symbols are
> > obviously not reachable from vDSO code.
> > 
> > Regular kernel code should not use the vdso/ namespace but instead use the
> > regular linux/ headers, which in turn include the corresponding vdso/ one.
> 
> offset_in_page() is that trivial that I don't see how it shouldn't just go next
> to PAGE_SIZE / PAGE_MASK, though?

Yes, IMO it could go into vdso/page.h. The related offset_in_folio() which is
defined right next to offset_in_page() however can not go there, as folios do
not exist in the vDSO userspace context.

Personally I don't care about where this goes and just wanted to clarify the
background of the vDSO headers.


Thomas