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

[Thomas Weißschuh]

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:
> > On 5/18/26 12:24, Lorenzo Stoakes wrote:
> > > On Mon, May 18, 2026 at 10:09:33AM +0100, David Laight wrote:
> > >> On Sun, 17 May 2026 11:28:05 -0400
> > >> Yury Norov <ynorov@xxxxxxxxxx> 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.
> > >>
> > >> I don't think you need a another new header.
> > >> There is already vdso/page.h which is where PAGE_MASK comes from.
> > >
> > > Yeah please don't, that's already a weird situation I don't really love the idea
> > > of extending that.
> > >
> > > mm_types.h seems the more appropriate place.
> >
> > 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.


(...)