[PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[Thorsten Blum]

Move offset_in_page() out of linux/mm.h so users that only need page
offset calculations can include this lightweight header instead of
pulling in all of linux/mm.h.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 include/linux/mm.h           |  2 +-
 include/linux/page_helpers.h | 10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/page_helpers.h

diff --git a/include/linux/mm.h b/include/linux/mm.h
index af23453e9dbd..bf49e52f749a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -17,6 +17,7 @@
 #include <linux/mm_types.h>
 #include <linux/mmap_lock.h>
 #include <linux/range.h>
+#include <linux/page_helpers.h>
 #include <linux/pfn.h>
 #include <linux/percpu-refcount.h>
 #include <linux/bit_spinlock.h>
@@ -3033,7 +3034,6 @@ static inline void clear_page_pfmemalloc(struct page *page)
  */
 extern void pagefault_out_of_memory(void);
 
-#define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)
 #define offset_in_folio(folio, p) ((unsigned long)(p) & (folio_size(folio) - 1))
 
 /*
diff --git a/include/linux/page_helpers.h b/include/linux/page_helpers.h
new file mode 100644
index 000000000000..102a4f3c3868
--- /dev/null
+++ b/include/linux/page_helpers.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_PAGE_HELPERS_H
+#define _LINUX_PAGE_HELPERS_H
+
+#include <asm/page.h>
+
+#define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)
+
+#endif /* _LINUX_PAGE_HELPERS_H */

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

[Thorsten Blum]

Add bytes_to_page_end() for the common PAGE_SIZE - offset_in_page()
calculation.

Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 include/linux/page_helpers.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/page_helpers.h b/include/linux/page_helpers.h
index 102a4f3c3868..981731faa1fc 100644
--- a/include/linux/page_helpers.h
+++ b/include/linux/page_helpers.h
@@ -6,5 +6,6 @@
 #include <asm/page.h>
 
 #define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)
+#define bytes_to_page_end(p)	(PAGE_SIZE - offset_in_page(p))
 
 #endif /* _LINUX_PAGE_HELPERS_H */

[PATCH 3/3] lib/bitmap: use bytes_to_page_end() helper

[Thorsten Blum]

bitmap-str.c includes linux/mm.h for offset_in_page() and kfree().
Instead, include linux/page_helpers.h and linux/slab.h directly, and
use bytes_to_page_end() to simplify the code.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 lib/bitmap-str.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/bitmap-str.c b/lib/bitmap-str.c
index be745209507a..bf245a3eae4a 100644
--- a/lib/bitmap-str.c
+++ b/lib/bitmap-str.c
@@ -7,7 +7,8 @@
 #include <linux/export.h>
 #include <linux/hex.h>
 #include <linux/kernel.h>
-#include <linux/mm.h>
+#include <linux/page_helpers.h>
+#include <linux/slab.h>
 #include <linux/string.h>
 
 #include "kstrtox.h"
@@ -58,7 +59,7 @@ EXPORT_SYMBOL(bitmap_parse_user);
 int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
 			    int nmaskbits)
 {
-	ptrdiff_t len = PAGE_SIZE - offset_in_page(buf);
+	ptrdiff_t len = bytes_to_page_end(buf);
 
 	return list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) :
 		      scnprintf(buf, len, "%*pb\n", nmaskbits, maskp);

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

[Yury Norov]

On Sun, May 17, 2026 at 02:34:30PM +0200, Thorsten Blum wrote:
> Add bytes_to_page_end() for the common PAGE_SIZE - offset_in_page()
> calculation.
> 
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  include/linux/page_helpers.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/page_helpers.h b/include/linux/page_helpers.h
> index 102a4f3c3868..981731faa1fc 100644
> --- a/include/linux/page_helpers.h
> +++ b/include/linux/page_helpers.h
> @@ -6,5 +6,6 @@
>  #include <asm/page.h>
>  
>  #define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)
> +#define bytes_to_page_end(p)	(PAGE_SIZE - offset_in_page(p))
>  
>  #endif /* _LINUX_PAGE_HELPERS_H */

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.

Thanks,
Yury

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

[Andy Shevchenko]

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.

We always can simply fork, but I truly do not understand the pushback.
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.

I'm in favour of this series.

-- 
With Best Regards,
Andy Shevchenko

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

[Andy Shevchenko]

On Sun, May 17, 2026 at 02:34:30PM +0200, Thorsten Blum wrote:
> Add bytes_to_page_end() for the common PAGE_SIZE - offset_in_page()
> calculation.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[Andy Shevchenko]

On Sun, May 17, 2026 at 02:34:29PM +0200, Thorsten Blum wrote:
> Move offset_in_page() out of linux/mm.h so users that only need page
> offset calculations can include this lightweight header instead of
> pulling in all of linux/mm.h.

Yep, the whole mm.h is rarely used in the cases where this and a new one
(next patch) are being (going to be) used.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

(Do we need to update MAINTAINERS / Documentation parts anywhere?)

-- 
With Best Regards,
Andy Shevchenko

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

[David Laight]

On Sun, 17 May 2026 11:28:05 -0400
Yury Norov <ynorov@nvidia.com> wrote:

> On Sun, May 17, 2026 at 02:34:30PM +0200, Thorsten Blum wrote:
> > Add bytes_to_page_end() for the common PAGE_SIZE - offset_in_page()
> > calculation.
> > 
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > ---
> >  include/linux/page_helpers.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/linux/page_helpers.h b/include/linux/page_helpers.h
> > index 102a4f3c3868..981731faa1fc 100644
> > --- a/include/linux/page_helpers.h
> > +++ b/include/linux/page_helpers.h
> > @@ -6,5 +6,6 @@
> >  #include <asm/page.h>
> >  
> >  #define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)
> > +#define bytes_to_page_end(p)	(PAGE_SIZE - offset_in_page(p))
> >  
> >  #endif /* _LINUX_PAGE_HELPERS_H */  
> 
> 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.

I don't think you need a another new header.
There is already vdso/page.h which is where PAGE_MASK comes from.

-- David

> 
> Thanks,
> Yury
> 

Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[Lorenzo Stoakes]

Seriously, please resend this.

This is 3 patches with 2 in-reply-to 1/3, that's not how we do series in mm,
take a look around :)

Write a cover letter, and have all the patches in-reply-to that.

Was there not previous versions of this? I _seem_ to remember that, but might be
misremembering :)

Also I'm really questioning the value of this, you've not sold why we should
take this whatsoever.

'Add a random new header file we have to maintain because it's smaller' is not
really hugely compelling.

Also a _lot_ of stuff in the kernel ultimately pulls in mm.h. So what exactly
has the specific requirement of both needing this define and (somehow) doesn't
use mm?

On Sun, May 17, 2026 at 02:34:29PM +0200, Thorsten Blum wrote:
> Move offset_in_page() out of linux/mm.h so users that only need page
> offset calculations can include this lightweight header instead of
> pulling in all of linux/mm.h.

What's the motivation? What caused you to want to do this? Why should we have a
new tiny header with only this define? What makes that important?

Why is pulling in a 'big' header file such an issue?

This commit message is pretty useless right now, you're just saying what you're
doing, yeah I can see that from the diff.

You should use the commit message to explain why and what for etc.

>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  include/linux/mm.h           |  2 +-
>  include/linux/page_helpers.h | 10 ++++++++++

You've added a new file and not updated MAINTAINERS, nor indicated that it will
be caught by a glob?

Also super super restrictive to have 'page helpers', that's likely to be tiny
forever, why not just move this macro to mm_types.h and import that instead?
It's highly likely it's already imported wherever you need it, anyway.

>  2 files changed, 11 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/page_helpers.h
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index af23453e9dbd..bf49e52f749a 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -17,6 +17,7 @@
>  #include <linux/mm_types.h>
>  #include <linux/mmap_lock.h>
>  #include <linux/range.h>
> +#include <linux/page_helpers.h>
>  #include <linux/pfn.h>
>  #include <linux/percpu-refcount.h>
>  #include <linux/bit_spinlock.h>
> @@ -3033,7 +3034,6 @@ static inline void clear_page_pfmemalloc(struct page *page)
>   */
>  extern void pagefault_out_of_memory(void);
>
> -#define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)
>  #define offset_in_folio(folio, p) ((unsigned long)(p) & (folio_size(folio) - 1))
>
>  /*
> diff --git a/include/linux/page_helpers.h b/include/linux/page_helpers.h
> new file mode 100644
> index 000000000000..102a4f3c3868
> --- /dev/null
> +++ b/include/linux/page_helpers.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

No description of what this is for?

> +
> +#ifndef _LINUX_PAGE_HELPERS_H
> +#define _LINUX_PAGE_HELPERS_H
> +
> +#include <asm/page.h>
> +
> +#define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)

Why are you only porting the page version when ostensibly folios are more likely
to be the unit-of-operation in future?

> +
> +#endif /* _LINUX_PAGE_HELPERS_H */

Thanks, Lorenzo

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

[Lorenzo Stoakes]

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

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

[Lorenzo Stoakes]

Why is this a separate commit? It's tiny, I don't think it needs to be separated
at all.

On Sun, May 17, 2026 at 02:34:30PM +0200, Thorsten Blum wrote:
> Add bytes_to_page_end() for the common PAGE_SIZE - offset_in_page()
> calculation.

This is a totally useless commit message. Again you're not indicating why it's
needed. Please look around mm to get a sense of how commit messages should look.

Also it's so common that you have exactly zero callers updated here or
elsewhere?

I see uses which are all pretty specific. I wonder if it's really useful to make
this its own thing?

And it's untyped and etc. etc. yeah, it's a no really to this.

>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>

Was there a previous discussion that led to this series? You should really give
some background somewhere (like a cover letter, and if previous revisions were
sent, a history of them below the ---)

> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>

Again I'm really unconvinced you need to do any of this.

> ---
>  include/linux/page_helpers.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/page_helpers.h b/include/linux/page_helpers.h
> index 102a4f3c3868..981731faa1fc 100644
> --- a/include/linux/page_helpers.h
> +++ b/include/linux/page_helpers.h
> @@ -6,5 +6,6 @@
>  #include <asm/page.h>
>
>  #define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)

I mean another thing about this (and yes this was existing but since you're
proposing making this rather special it's worth raising) is that it's enormously
un-typesafe and 'p' is vague, what if somebody put a (struct page *) here?

It'd be better if it was a static inline function, maybe there's places which
use this already that require it to be a macro but perhaps not.

> +#define bytes_to_page_end(p)	(PAGE_SIZE - offset_in_page(p))

Here, since, you're adding it, there's no excuse at all for it being a
macro. And you're implementing something just as horribly vague as the other
form, it's not obvious 'p' is meant to be a pointer. Page begins with p too :)

Anyway I'm not really convinced this is useful.

>
>  #endif /* _LINUX_PAGE_HELPERS_H */

Thanks, Lorenzo

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

[Lorenzo Stoakes]

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@nvidia.com> wrote:
>
> > On Sun, May 17, 2026 at 02:34:30PM +0200, Thorsten Blum wrote:
> > > Add bytes_to_page_end() for the common PAGE_SIZE - offset_in_page()
> > > calculation.
> > >
> > > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > > ---
> > >  include/linux/page_helpers.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/include/linux/page_helpers.h b/include/linux/page_helpers.h
> > > index 102a4f3c3868..981731faa1fc 100644
> > > --- a/include/linux/page_helpers.h
> > > +++ b/include/linux/page_helpers.h
> > > @@ -6,5 +6,6 @@
> > >  #include <asm/page.h>
> > >
> > >  #define offset_in_page(p)	((unsigned long)(p) & ~PAGE_MASK)
> > > +#define bytes_to_page_end(p)	(PAGE_SIZE - offset_in_page(p))
> > >
> > >  #endif /* _LINUX_PAGE_HELPERS_H */
> >
> > 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.
>
> 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.

>
> -- David
>
> >
> > Thanks,
> > Yury
> >
>

Thanks, Lorenzo

Re: [PATCH 3/3] lib/bitmap: use bytes_to_page_end() helper

[Lorenzo Stoakes]

On Sun, May 17, 2026 at 02:34:31PM +0200, Thorsten Blum wrote:
> bitmap-str.c includes linux/mm.h for offset_in_page() and kfree().

I'd specifically say that it's including linux/mm.h which in turn includes
linux/slab.h and that you're fixing this, because saying you include mm.h for
kfree() is a little confusing.

> Instead, include linux/page_helpers.h and linux/slab.h directly, and
> use bytes_to_page_end() to simplify the code.

This is again, a useless commit message. You're not explaining why what for, how
etc., you're putting in words what the code is doing.

And I'm still very confused as to what the motive is here overall. What's so
problematic about including that header? Longer compile times, somehow? If so,
what are the measurements before/after this change? What was the problem that
led to it? Etc.

We could end up with hundreds of super specific headers files for things, so
there really has to be a good reason for it.


>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  lib/bitmap-str.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/bitmap-str.c b/lib/bitmap-str.c
> index be745209507a..bf245a3eae4a 100644
> --- a/lib/bitmap-str.c
> +++ b/lib/bitmap-str.c
> @@ -7,7 +7,8 @@
>  #include <linux/export.h>
>  #include <linux/hex.h>
>  #include <linux/kernel.h>
> -#include <linux/mm.h>
> +#include <linux/page_helpers.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>
>  #include "kstrtox.h"
> @@ -58,7 +59,7 @@ EXPORT_SYMBOL(bitmap_parse_user);
>  int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
>  			    int nmaskbits)
>  {
> -	ptrdiff_t len = PAGE_SIZE - offset_in_page(buf);
> +	ptrdiff_t len = bytes_to_page_end(buf);

yeah this is kind of nasty, going from a clear thing to a 'I wonder how that is
implemented' mystery meat function. I think the original is better.

>
>  	return list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) :
>  		      scnprintf(buf, len, "%*pb\n", nmaskbits, maskp);

Thanks, Lorenzo

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

[William Kucharski]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

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.


> On May 18, 2026, at 04:28, 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
> 

[-- Attachment #2: Type: text/html, Size: 4738 bytes --]

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

[William Kucharski]

(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
> 

Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[Thorsten Blum]

Hi Lorenzo,

On Mon, May 18, 2026 at 11:02:10AM +0100, Lorenzo Stoakes wrote:
> Seriously, please resend this.
> 
> This is 3 patches with 2 in-reply-to 1/3, that's not how we do series in mm,
> take a look around :)
> 
> Write a cover letter, and have all the patches in-reply-to that.

A cover letter seemed unnecessary for such a seemingly trivial 3-patch
series, but this thread [1] might have been helpful for context.

[1] https://lore.kernel.org/lkml/CAHp75VfQNkqEYsO4Uup0c-uiYuVyAWit=tmCz2BsYLp-sjXsZw@mail.gmail.com/

> Was there not previous versions of this? I _seem_ to remember that, but might be
> misremembering :)

I only know about the one Yury mentioned. This is v1 of my series.

> Also I'm really questioning the value of this, you've not sold why we should
> take this whatsoever.
> 
> 'Add a random new header file we have to maintain because it's smaller' is not
> really hugely compelling.
> 
> Also a _lot_ of stuff in the kernel ultimately pulls in mm.h. So what exactly
> has the specific requirement of both needing this define and (somehow) doesn't
> use mm?

Patch 3/3 is one of many examples that pulls in all of mm.h just for
offset_in_page(). lib/string.c from the same thread [1] is another
example that would need to include mm.h just for offset_in_page().

Many other files (hundreds) don't use offset_in_page(), but open-code it
in many different ways instead:

	(unsigned long)p & ~PAGE_MASK
	(unsigned long)p & (PAGE_SIZE - 1)
	(long)p & (PAGE_SIZE - 1)
	...

I can't tell whether they didn't know about offset_in_page(), or
deliberately chose not to include mm.h.

Thanks,
Thorsten

Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[Lorenzo Stoakes]

On Mon, May 18, 2026 at 02:13:54PM +0200, Thorsten Blum wrote:
> Hi Lorenzo,
>
> On Mon, May 18, 2026 at 11:02:10AM +0100, Lorenzo Stoakes wrote:
> > Seriously, please resend this.
> >
> > This is 3 patches with 2 in-reply-to 1/3, that's not how we do series in mm,
> > take a look around :)
> >
> > Write a cover letter, and have all the patches in-reply-to that.
>
> A cover letter seemed unnecessary for such a seemingly trivial 3-patch
> series, but this thread [1] might have been helpful for context.

OK, but this is how we do multi-patch series in mm, as I said. It's always a
good idea to look around a subsystem to get a sense of how things are done as a
courtesy.

So politely request you do this :) though as I said I question this being broken
out into as many patches as it is.

>
> [1] https://lore.kernel.org/lkml/CAHp75VfQNkqEYsO4Uup0c-uiYuVyAWit=tmCz2BsYLp-sjXsZw@mail.gmail.com/
>
> > Was there not previous versions of this? I _seem_ to remember that, but might be
> > misremembering :)
>
> I only know about the one Yury mentioned. This is v1 of my series.
>
> > Also I'm really questioning the value of this, you've not sold why we should
> > take this whatsoever.
> >
> > 'Add a random new header file we have to maintain because it's smaller' is not
> > really hugely compelling.
> >
> > Also a _lot_ of stuff in the kernel ultimately pulls in mm.h. So what exactly
> > has the specific requirement of both needing this define and (somehow) doesn't
> > use mm?
>
> Patch 3/3 is one of many examples that pulls in all of mm.h just for
> offset_in_page(). lib/string.c from the same thread [1] is another
> example that would need to include mm.h just for offset_in_page().

And that's a problem why? Compile time? Somehow binary bloat? Conflicts?
Confusion?

>
> Many other files (hundreds) don't use offset_in_page(), but open-code it
> in many different ways instead:
>
> 	(unsigned long)p & ~PAGE_MASK
> 	(unsigned long)p & (PAGE_SIZE - 1)
> 	(long)p & (PAGE_SIZE - 1)
> 	...
>
> I can't tell whether they didn't know about offset_in_page(), or
> deliberately chose not to include mm.h.

OK but this series doesn't address any of that? It just adds a new header, a
questionable macro and uses it in one place? So those justifications are rather
moot here.

>
> Thanks,
> Thorsten

Cheers, Lorenzo

Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[David Hildenbrand (Arm)]

On 5/18/26 14:13, Thorsten Blum wrote:
> Hi Lorenzo,
> 
> On Mon, May 18, 2026 at 11:02:10AM +0100, Lorenzo Stoakes wrote:
>> Seriously, please resend this.
>>
>> This is 3 patches with 2 in-reply-to 1/3, that's not how we do series in mm,
>> take a look around :)
>>
>> Write a cover letter, and have all the patches in-reply-to that.
> 
> A cover letter seemed unnecessary for such a seemingly trivial 3-patch
> series, but this thread [1] might have been helpful for context.

And that's, for example, something to point out in a very basic cover letter.

b4 and git-send-mail can automate the creation of a cover letter for you.

-- 
Cheers,

David

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

[David Hildenbrand (Arm)]

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@nvidia.com> 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.
>>
>> 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 :)

-- 
Cheers,

David

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

[Lorenzo Stoakes]

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@nvidia.com> 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.
> >>
> >> 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...

I'm still waiting for an explanation as to why this series is necessary, I'm
guessing build times (though I wonder what the actual delta is).

But yeah, I mean if you're fine with something else going there then fine, that
or mm_types.h or some existing header, the new header is the nope thing here.

>
> --
> Cheers,
>
> David

Thanks, Lorenzo

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

[David Hildenbrand (Arm)]

On 5/18/26 15:15, 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:
>>>
>>> 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...

Yeah, I don't know the history of all that, but I know that BIT(), ALIGN() etc
are also in vdso/ ... and confused me in the past.

So as long as PAGE_MASK etc is in there, I guess adding simple helpers in there
as well is the right thing to do. (I don't know if the defines could be
reasonably moved at this point)

-- 
Cheers,

David

Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[Thorsten Blum]

On Mon, May 18, 2026 at 01:33:54PM +0100, Lorenzo Stoakes wrote:
> On Mon, May 18, 2026 at 02:13:54PM +0200, Thorsten Blum wrote:
> > [...]
> > Patch 3/3 is one of many examples that pulls in all of mm.h just for
> > offset_in_page(). lib/string.c from the same thread [1] is another
> > example that would need to include mm.h just for offset_in_page().
> 
> And that's a problem why? Compile time? Somehow binary bloat? Conflicts?
> Confusion?

This is more about separation of concerns than about compile time, which
can still matter here, since mm.h is large, pulls in many other headers,
and any changes to those can cause unrelated files to be recompiled.

I don't mind including mm.h where the code already depends on MM
interfaces, but offset_in_page() itself is a small page-arithmetic
helper. Having it buried 3000+ lines into mm.h also makes it less
discoverable, which may be one reason it's not used more often.

> > Many other files (hundreds) don't use offset_in_page(), but open-code it
> > in many different ways instead:
> >
> > 	(unsigned long)p & ~PAGE_MASK
> > 	(unsigned long)p & (PAGE_SIZE - 1)
> > 	(long)p & (PAGE_SIZE - 1)
> > 	...
> >
> > I can't tell whether they didn't know about offset_in_page(), or
> > deliberately chose not to include mm.h.
> 
> OK but this series doesn't address any of that? It just adds a new header, a
> questionable macro and uses it in one place? So those justifications are rather
> moot here.

My intent was to make the helper available from a smaller header first,
and to use patch 3/3 as a concrete example where including all of mm.h
is unnecessary. Other call sites can then be converted incrementally
over time, rather than sending a tree-wide conversion in the same
series.

Thanks,
Thorsten

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

[Lorenzo Stoakes]

On Mon, May 18, 2026 at 03:24:15PM +0200, David Hildenbrand (Arm) wrote:
> On 5/18/26 15:15, 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:
> >>>
> >>> 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...
>
> Yeah, I don't know the history of all that, but I know that BIT(), ALIGN() etc
> are also in vdso/ ... and confused me in the past.
>
> So as long as PAGE_MASK etc is in there, I guess adding simple helpers in there
> as well is the right thing to do. (I don't know if the defines could be
> reasonably moved at this point)

OK then begrudgingly I guess that's fine :) (don't get me started on
linux/sched/mm.h btw, in the same vein as this file :)

Thorsten - this might be the easiest solution here. Then the series becomes move
the helper macro there (I don't love the new one so would rather you didn't add
that) as 1 patch, and updating the bitmap code as a 2nd patch (with a cover
letter obviously :)

>
> --
> Cheers,
>
> David

Thanks, Lorenzo

Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h

[Lorenzo Stoakes]

On Mon, May 18, 2026 at 03:36:14PM +0200, Thorsten Blum wrote:
> On Mon, May 18, 2026 at 01:33:54PM +0100, Lorenzo Stoakes wrote:
> > On Mon, May 18, 2026 at 02:13:54PM +0200, Thorsten Blum wrote:
> > > [...]
> > > Patch 3/3 is one of many examples that pulls in all of mm.h just for
> > > offset_in_page(). lib/string.c from the same thread [1] is another
> > > example that would need to include mm.h just for offset_in_page().
> >
> > And that's a problem why? Compile time? Somehow binary bloat? Conflicts?
> > Confusion?
>
> This is more about separation of concerns than about compile time, which
> can still matter here, since mm.h is large, pulls in many other headers,
> and any changes to those can cause unrelated files to be recompiled.
>
> I don't mind including mm.h where the code already depends on MM
> interfaces, but offset_in_page() itself is a small page-arithmetic
> helper. Having it buried 3000+ lines into mm.h also makes it less
> discoverable, which may be one reason it's not used more often.

See the side thread with David, putting it in vdso/page.h is fine, and should
achieve your aims.

>
> > > Many other files (hundreds) don't use offset_in_page(), but open-code it
> > > in many different ways instead:
> > >
> > > 	(unsigned long)p & ~PAGE_MASK
> > > 	(unsigned long)p & (PAGE_SIZE - 1)
> > > 	(long)p & (PAGE_SIZE - 1)
> > > 	...
> > >
> > > I can't tell whether they didn't know about offset_in_page(), or
> > > deliberately chose not to include mm.h.
> >
> > OK but this series doesn't address any of that? It just adds a new header, a
> > questionable macro and uses it in one place? So those justifications are rather
> > moot here.
>
> My intent was to make the helper available from a smaller header first,
> and to use patch 3/3 as a concrete example where including all of mm.h
> is unnecessary. Other call sites can then be converted incrementally
> over time, rather than sending a tree-wide conversion in the same
> series.

Yeah I'm not sure it's at all clear anybody will pay attention to that (by not
sure I mean - happy to bet a beer or 2 against :)

Anyway I'm not going to demand that you update all the callsites, if you split
this into 2 patches as per above + send w/cover letter this is fine.

>
> Thanks,
> Thorsten

Thanks, Lorenzo

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@nvidia.com> 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.
> > >>
> > >> 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.


(...)

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

[David Hildenbrand (Arm)]

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?

In any case, a new header for this feels very wrong.

-- 
Cheers,

David

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

Re: [PATCH 3/3] lib/bitmap: use bytes_to_page_end() helper

[Yury Norov]

On Sun, May 17, 2026 at 02:34:31PM +0200, Thorsten Blum wrote:
> bitmap-str.c includes linux/mm.h for offset_in_page() and kfree().

And there's nothing wrong with that because it's a .c file, right?

> Instead, include linux/page_helpers.h and linux/slab.h directly, and
> use bytes_to_page_end() to simplify the code.

I'm OK about narrowing down inclusions in broadly-used headers. But
here in a regular .c file it doesn't look like it fixes anything.
Maybe some circular dependency you've not mentioned?

> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  lib/bitmap-str.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/bitmap-str.c b/lib/bitmap-str.c
> index be745209507a..bf245a3eae4a 100644
> --- a/lib/bitmap-str.c
> +++ b/lib/bitmap-str.c
> @@ -7,7 +7,8 @@
>  #include <linux/export.h>
>  #include <linux/hex.h>
>  #include <linux/kernel.h>
> -#include <linux/mm.h>
> +#include <linux/page_helpers.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>  
>  #include "kstrtox.h"
> @@ -58,7 +59,7 @@ EXPORT_SYMBOL(bitmap_parse_user);
>  int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
>  			    int nmaskbits)
>  {
> -	ptrdiff_t len = PAGE_SIZE - offset_in_page(buf);
> +	ptrdiff_t len = bytes_to_page_end(buf);

Don't worry about this function - it's on a schedule for deletion in
this cycle. Now that you're fixing the only user that is going to
disappear anyways, this new macro is going to become a dead code.

Can you please check the other ~90 users over the kernel. I already
mentioned the series taking care of them. 

https://lore.kernel.org/all/20260304012717.201797-1-ynorov@nvidia.com/

Maybe just start from there?

Thanks,
Yury
 
>  	return list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) :
>  		      scnprintf(buf, len, "%*pb\n", nmaskbits, maskp);

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

[David Hildenbrand (Arm)]

On 5/18/26 16:52, Thomas Weißschuh wrote:
> On Mon, May 18, 2026 at 04:41:38PM +0200, David Hildenbrand (Arm) wrote:
>> On 5/18/26 16:29, Thomas Weißschuh wrote:
>>>
>>> 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.

yes, folio stuff should not go in there indeed.

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

Yes, thanks!

-- 
Cheers,

David