[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8d89245-bcd2-41a7-9543-e517766900ba@suse.com>
Date: Thu, 27 Mar 2025 16:15:11 +0100
From: Jürgen Groß <jgross@...e.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Jan Beulich <jbeulich@...e.com>, oe-kbuild-all@...ts.linux.dev,
xen-devel@...ts.xenproject.org, Boris Ostrovsky
<boris.ostrovsky@...cle.com>, kernel test robot <lkp@...el.com>,
x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [xen-tip:linux-next 12/12] WARNING: modpost: vmlinux: section
mismatch in reference: mc_debug_data+0x0 (section: .data) ->
mc_debug_data_early (section: .init.data)
On 27.03.25 15:40, Borislav Petkov wrote:
> On Thu, Mar 27, 2025 at 03:21:45PM +0100, Jürgen Groß wrote:
>> Well, that is wasting nearly 3kB of the data section.
>>
>> Maybe not a big deal, but still...
>
> We could do it until the proper fix is in place, no?
>
> 3K is meh, especially for the hypervisor kernel, I'd say...
>
Yeah, that was my thinking.
Another approach could be to have:
-static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data) =
- &mc_debug_data_early;
+static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data);
and to use an inline access function returning &mc_debug_data_early
if the percpu variable is NULL. This access function could be __ref.
It is a debug feature after all, so having a few additional instructions
isn't the end of the world.
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists