The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Yury Norov <ynorov@nvidia.com>
To: Thorsten Blum <thorsten.blum@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Yury Norov <yury.norov@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 3/3] lib/bitmap: use bytes_to_page_end() helper
Date: Mon, 18 May 2026 11:29:12 -0400	[thread overview]
Message-ID: <agswSOesgrRAO19t@yury> (raw)
In-Reply-To: <20260517123428.1181981-6-thorsten.blum@linux.dev>

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);

  parent reply	other threads:[~2026-05-18 15:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-17 12:34 [PATCH 1/3] mm: move offset_in_page() to page_helpers.h Thorsten Blum
2026-05-17 12:34 ` [PATCH 2/3] mm: add bytes_to_page_end() helper Thorsten Blum
2026-05-17 15:28   ` Yury Norov
2026-05-18  6:48     ` Andy Shevchenko
2026-05-18 10:23       ` Lorenzo Stoakes
2026-05-18 11:53         ` William Kucharski
2026-05-18  9:09     ` David Laight
2026-05-18 10:24       ` Lorenzo Stoakes
2026-05-18 13:06         ` David Hildenbrand (Arm)
2026-05-18 13:15           ` Lorenzo Stoakes
2026-05-18 13:24             ` David Hildenbrand (Arm)
2026-05-18 13:38               ` Lorenzo Stoakes
2026-05-18 14:29             ` Thomas Weißschuh
2026-05-18 14:41               ` David Hildenbrand (Arm)
2026-05-18 14:52                 ` Thomas Weißschuh
2026-05-18 15:32                   ` David Hildenbrand (Arm)
2026-05-18  6:49   ` Andy Shevchenko
2026-05-18 10:24   ` Lorenzo Stoakes
2026-05-17 12:34 ` [PATCH 3/3] lib/bitmap: use " Thorsten Blum
2026-05-18 10:33   ` Lorenzo Stoakes
2026-05-18 15:29   ` Yury Norov [this message]
2026-05-18  6:51 ` [PATCH 1/3] mm: move offset_in_page() to page_helpers.h Andy Shevchenko
2026-05-18 10:02 ` Lorenzo Stoakes
2026-05-18 12:13   ` Thorsten Blum
2026-05-18 12:33     ` Lorenzo Stoakes
2026-05-18 13:36       ` Thorsten Blum
2026-05-18 14:03         ` Lorenzo Stoakes
2026-05-18 12:58     ` David Hildenbrand (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=agswSOesgrRAO19t@yury \
    --to=ynorov@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=david@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=thorsten.blum@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox