Re: [GIT PULL] x86/urgent for v6.3-rc7

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Wed, Apr 19, 2023 at 06:03:53PM +0200, Juergen Gross wrote:
> > However, the only call site is in apic_intr_mode_init() which itself is
> > __init. So yeah, strictly speaking nothing wrong.
> > 
> > *IF* something calls it later, when __init is gone, then boom.
> > 
> > Dunno, maybe
> > 
> > a) track call sites too but maybe expensive and too much

That would indeed be a lot harder to do.

> > or
> > 
> > b) make those warnings debug messages in case someone wants to run objtool
> > in debug mode, feels really bored and wants to fix potential issues.

Possibly, though I suspect nobody's ever going to be that bored ;-)

> > Or someone has a better idea.
> > 
> > > Anyway, this is kind of experimental.  If any of these warnings don't
> > > turn out to be useful I could drop some or all them.
> > 
> > Right, I can certainly see potential and as said, since we're already
> > doing objtool massaging of object files, thought this should be pretty
> > easy to do. As you've shown. ;-)
> 
> What about splitting the function vectors into __init and non-init parts?
> 
> This would solve above problem automatically, as a non-init function couldn't
> deref the __init part of x86_platform.

Right, if we moved the __init parts of x86_platform out into a separate
struct x86_platform_init which is __initdata, that would solve this
particular issue rather cleanly.

Though, more generally, if we make the rule that non-init data can't
contain references to init data, that would be a much bigger patch set.

Which might end up being the reasonable thing to do, but before deciding
whether enforcing such a rule would be worth it, we might want to look
more deeply at the warnings to figure out what percentage of those (if
any) could be real bugs.

-- 
Josh