[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJuCfpGA5Jy0NmO6oT0Y-KQSPvjj-=pDsM9AiT0vSUUGAM96OA@mail.gmail.com>
Date: Wed, 3 Jul 2024 17:10:03 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, kent.overstreet@...ux.dev,
linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH 1/1] sched.h: always_inline alloc_tag_{save|restore} to
fix modpost warnings
On Wed, Jul 3, 2024 at 4:23 PM Suren Baghdasaryan <surenb@...gle.com> wrote:
>
> On Wed, Jul 3, 2024 at 3:51 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > On Wed, 3 Jul 2024 15:15:20 -0700 Suren Baghdasaryan <surenb@...gle.com> wrote:
> >
> > > Mark alloc_tag_{save|restore} as always_inline to fix the following
> > > modpost warnings:
> > >
> > > WARNING: modpost: vmlinux: section mismatch in reference: alloc_tag_save+0x1c (section: .text.unlikely) -> initcall_level_names (section: .init.data)
> > > WARNING: modpost: vmlinux: section mismatch in reference: alloc_tag_restore+0x3c (section: .text.unlikely) -> initcall_level_names (section: .init.data)
> >
> > Well, is it only about fixing warnings? If the warning is correct then
> > this might be fixing kernel crashes.
> >
> > Do you know where these references are coming from?
>
> I *think* this happens when alloc_tag_save()/alloc_tag_restore() are
> not inlined and are called from an __init function. They access the
> `tag` parameter passed to them and since that tag is a static local
> variable inside an __init function, I assume it gets allocated inside
> __initdata. If so, an example of such case is cma_activate_area()
> which is an __init function and allocates memory using
> bitmap_zalloc():
> https://elixir.bootlin.com/linux/v6.10-rc6/source/mm/cma.c#L97. There
> are likely more cases like that.
Actually, my theory is wrong. Allocation tags are always allocated
from the "alloc_tags" section. This makes me think that it's the
access to current->alloc_tag that causes these warnings. After my
change I actually see another warning like this:
WARNING: modpost: vmlinux: section mismatch in reference:
get_current+0xc (section: .text.unlikely) -> initcall_level_names
(section: .init.data)
get_current()/current_thread_info() for xtensa arch are inline functions:
https://elixir.bootlin.com/linux/v6.10-rc6/source/arch/xtensa/include/asm/current.h#L22
https://elixir.bootlin.com/linux/v6.10-rc6/source/arch/xtensa/include/asm/thread_info.h#L94
and they return a local variable `thread_info`.
Let me dig a bit more to understand what's really happening here.
>
> >
> > I'm curious about the .text.unlikely. Makes me wonder if we should
> > also have .init.unlikely for unlikely() calls which happen from __init
> > code. Maybe we already handle that.
>
> I don't really know.
>
> >
> > > Reported-by: kernel test robot <lkp@...el.com>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202407032306.gi9nZsBi-lkp@intel.com/
> > > Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
> > > Cc: Kent Overstreet <kent.overstreet@...ux.dev>
> >
> > Fixes: 22d407b164ff ("lib: add allocation tagging support for memory allocation profiling")
>
> Yes. Do you want me to post a v2 or will handle that locally?
>
> > Cc: stable
>
> I don't think so. This feature was introduced in 6.10, so no backports
> needed, right?
>
> >
> > yes?
> >
> >
Powered by blists - more mailing lists