On Wed, 15 May 2024 12:48:08 +1000
Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> Hi all,
>
> After merging the ftrace tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
Interesting, as I didn't get reports from it via zero-day bot.
>
> In file included from arch/powerpc/include/asm/page.h:332,
> from arch/powerpc/include/asm/mmu.h:144,
> from arch/powerpc/include/asm/paca.h:18,
> from arch/powerpc/include/asm/current.h:13,
> from include/linux/thread_info.h:23,
> from include/asm-generic/preempt.h:5,
> from ./arch/powerpc/include/generated/asm/preempt.h:1,
> from include/linux/preempt.h:79,
> from include/linux/alloc_tag.h:11,
> from include/linux/percpu.h:5,
> from include/linux/context_tracking_state.h:5,
> from include/linux/hardirq.h:5,
> from include/linux/interrupt.h:11,
> from include/linux/trace_recursion.h:5,
> from kernel/trace/ring_buffer.c:7:
> kernel/trace/ring_buffer.c: In function '__rb_map_vma':
> kernel/trace/ring_buffer.c:6286:72: warning: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion]
> 6286 | struct page *page = virt_to_page(cpu_buffer->subbuf_ids[s]);
> | ~~~~~~~~~~~~~~~~~~~~~~^~~
> | |
> | long unsigned int
> include/asm-generic/memory_model.h:37:45: note: in definition of macro '__pfn_to_page'
> 37 | #define __pfn_to_page(pfn) (vmemmap + (pfn))
> | ^~~
> kernel/trace/ring_buffer.c:6286:37: note: in expansion of macro 'virt_to_page'
> 6286 | struct page *page = virt_to_page(cpu_buffer->subbuf_ids[s]);
> | ^~~~~~~~~~~~
> arch/powerpc/include/asm/page.h:228:53: note: expected 'const void *' but argument is of type 'long unsigned int'
> 228 | static inline unsigned long virt_to_pfn(const void *kaddr)
> | ~~~~~~~~~~~~^~~~~
>
> Introduced by commit
>
> 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions")
>
> My arm multi_v7_defconfig build produced a similar warning.
>
> Is this really intended for v6.10? It seems a bit late.
>
Well, I submitted this for the v6.9 merge window, and Linus had issues
with it. So we've been tweaking it for the entire time and it was ready
a bit earlier, but due to my vacation and traveling I missed pushing it
to next. :-p
Most the code has been well tested, but because it is late, I kept it
as a separate topic branch in case Linus still isn't happy with it.
-- Steve
