Re: linux-next: build warning after merge of the mm tree

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 25 May 2022 06:57:53 -0400 Zi Yan <ziy@nvidia.com> wrote:

> On 25 May 2022, at 1:54, Stephen Rothwell wrote:
> 
> > Hi all,
> >
> > After merging the mm tree, today's linux-next build (sparc64 defconfig)
> > produced this warning:
> >
> > In file included from include/linux/kernel.h:26,
> >                  from include/linux/cpumask.h:10,
> >                  from include/linux/smp.h:13,
> >                  from include/linux/lockdep.h:14,
> >                  from include/linux/spinlock.h:62,
> >                  from include/linux/mmzone.h:8,
> >                  from include/linux/gfp.h:6,
> >                  from include/linux/mm.h:7,
> >                  from mm/page_alloc.c:19:
> > mm/page_alloc.c: In function 'split_free_page':
> > include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast
> >    20 |         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
> >       |                                   ^~
> > include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck'
> >    26 |                 (__typecheck(x, y) && __no_side_effects(x, y))
> >       |                  ^~~~~~~~~~~
> > include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp'
> >    36 |         __builtin_choose_expr(__safe_cmp(x, y), \
> >       |                               ^~~~~~~~~~
> > include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp'
> >    45 | #define min(x, y)       __careful_cmp(x, y, <)
> >       |                         ^~~~~~~~~~~~~
> > mm/page_alloc.c:1138:35: note: in expansion of macro 'min'
> >  1138 |                 free_page_order = min(pfn ? __ffs(pfn) : order, __fls(split_pfn_offset));
> >       |                                   ^~~
> >
> > Introduced by commit
> >
> >   29a8af92b874 ("mm: fix a potential infinite loop in start_isolate_page_range()")
> 

The min() warning says "we screwed up the types", and reexamination is
in order.

> The patch below should fix it:
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6eec0211e0be..dbbfe4a079d3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1123,7 +1123,9 @@ void split_free_page(struct page *free_page,
>              pfn < free_page_pfn + (1UL << order);) {
>                 int mt = get_pfnblock_migratetype(pfn_to_page(pfn), pfn);
> 
> -               free_page_order = min(pfn ? __ffs(pfn) : order, __fls(split_pfn_offset));
> +               free_page_order = min_t(unsigned long,
> +                                       pfn ? __ffs(pfn) : order,
> +                                       __fls(split_pfn_offset));
>                 __free_one_page(pfn_to_page(pfn), pfn, zone, free_page_order,
>                                 mt, FPI_NONE);
>                 pfn += 1UL << free_page_order;

`order' has type `int'.  Inappropriately signed.  It should have been
`unsigned int'.  Too late (or too large) to make that change.

__ffs() and __fls() return `unsigned long'.  Inappropriately wide. 
Should have returned `unsigned int'.  Too late (or too large) to
change.  

So we get to live with the mess we made.  Your proposed change adds
more inappropriateness - why cast to ulong when assigning to an int?

--- a/mm/page_alloc.c~mm-fix-a-potential-infinite-loop-in-start_isolate_page_range-fix
+++ a/mm/page_alloc.c
@@ -1123,7 +1123,9 @@ void split_free_page(struct page *free_p
 	     pfn < free_page_pfn + (1UL << order);) {
 		int mt = get_pfnblock_migratetype(pfn_to_page(pfn), pfn);
 
-		free_page_order = min(pfn ? __ffs(pfn) : order, __fls(split_pfn_offset));
+		free_page_order = min_t(int,
+					pfn ? __ffs(pfn) : order,
+					__fls(split_pfn_offset));
 		__free_one_page(pfn_to_page(pfn), pfn, zone, free_page_order,
 				mt, FPI_NONE);
 		pfn += 1UL << free_page_order;
_