* 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) [not found] ` <3a847f18-750f-4bd2-9cac-37c4b9bdc84b@suse.com> @ 2025-03-27 14:13 ` Borislav Petkov 2025-03-27 14:21 ` Jürgen Groß 0 siblings, 1 reply; 5+ messages in thread From: Borislav Petkov @ 2025-03-27 14:13 UTC (permalink / raw) To: Jürgen Groß Cc: Jan Beulich, oe-kbuild-all, xen-devel, Boris Ostrovsky, kernel test robot, x86-ml, lkml On Wed, Jul 24, 2024 at 11:55:39AM +0200, Jürgen Groß wrote: > I'd prefer a general way to handle this problem, like e.g. some kind of > __refdata tagging for percpu variables. Any reason for not doing the trivial thing? diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c index 10c660fae8b3..100bfaba3f4d 100644 --- a/arch/x86/xen/multicalls.c +++ b/arch/x86/xen/multicalls.c @@ -53,7 +53,7 @@ struct mc_debug_data { }; static DEFINE_PER_CPU(struct mc_buffer, mc_buffer); -static struct mc_debug_data mc_debug_data_early __initdata; +static struct mc_debug_data mc_debug_data_early; static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data) = &mc_debug_data_early; static struct mc_debug_data __percpu *mc_debug_data_ptr; --- since this breaks randbuilds: WARNING: modpost: vmlinux: section mismatch in reference: mc_debug_data+0x0 (section: .data) -> mc_debug_data_early (section: .init.data) ERROR: modpost: Section mismatches detected. Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them. make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1 make[2]: *** Deleting file 'Module.symvers' make[1]: *** [/mnt/kernel/kernel/linux/Makefile:1947: modpost] Error 2 make: *** [Makefile:251: __sub-make] Error 2 ? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 5+ messages in thread
* 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) 2025-03-27 14:13 ` [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) Borislav Petkov @ 2025-03-27 14:21 ` Jürgen Groß 2025-03-27 14:40 ` Borislav Petkov 0 siblings, 1 reply; 5+ messages in thread From: Jürgen Groß @ 2025-03-27 14:21 UTC (permalink / raw) To: Borislav Petkov Cc: Jan Beulich, oe-kbuild-all, xen-devel, Boris Ostrovsky, kernel test robot, x86-ml, lkml [-- Attachment #1.1.1: Type: text/plain, Size: 965 bytes --] On 27.03.25 15:13, Borislav Petkov wrote: > On Wed, Jul 24, 2024 at 11:55:39AM +0200, Jürgen Groß wrote: >> I'd prefer a general way to handle this problem, like e.g. some kind of >> __refdata tagging for percpu variables. > > Any reason for not doing the trivial thing? > > diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c > index 10c660fae8b3..100bfaba3f4d 100644 > --- a/arch/x86/xen/multicalls.c > +++ b/arch/x86/xen/multicalls.c > @@ -53,7 +53,7 @@ struct mc_debug_data { > }; > > static DEFINE_PER_CPU(struct mc_buffer, mc_buffer); > -static struct mc_debug_data mc_debug_data_early __initdata; > +static struct mc_debug_data mc_debug_data_early; > static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data) = > &mc_debug_data_early; > static struct mc_debug_data __percpu *mc_debug_data_ptr; Well, that is wasting nearly 3kB of the data section. Maybe not a big deal, but still... Juergen [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3743 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* 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) 2025-03-27 14:21 ` Jürgen Groß @ 2025-03-27 14:40 ` Borislav Petkov 2025-03-27 15:15 ` Jürgen Groß 0 siblings, 1 reply; 5+ messages in thread From: Borislav Petkov @ 2025-03-27 14:40 UTC (permalink / raw) To: Jürgen Groß Cc: Jan Beulich, oe-kbuild-all, xen-devel, Boris Ostrovsky, kernel test robot, x86-ml, lkml 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... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 5+ messages in thread
* 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) 2025-03-27 14:40 ` Borislav Petkov @ 2025-03-27 15:15 ` Jürgen Groß 2025-03-27 15:24 ` Borislav Petkov 0 siblings, 1 reply; 5+ messages in thread From: Jürgen Groß @ 2025-03-27 15:15 UTC (permalink / raw) To: Borislav Petkov Cc: Jan Beulich, oe-kbuild-all, xen-devel, Boris Ostrovsky, kernel test robot, x86-ml, lkml [-- Attachment #1.1.1: Type: text/plain, Size: 825 bytes --] 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 [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3743 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* 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) 2025-03-27 15:15 ` Jürgen Groß @ 2025-03-27 15:24 ` Borislav Petkov 0 siblings, 0 replies; 5+ messages in thread From: Borislav Petkov @ 2025-03-27 15:24 UTC (permalink / raw) To: Jürgen Groß Cc: Jan Beulich, oe-kbuild-all, xen-devel, Boris Ostrovsky, kernel test robot, x86-ml, lkml On Thu, Mar 27, 2025 at 04:15:11PM +0100, Jürgen Groß wrote: > 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. Yap, makes sense to me too. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-03-27 15:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <202407240907.u0NJHgTu-lkp@intel.com>
[not found] ` <a9b1e875-5bf8-4755-ad2e-78ab2eb02c97@suse.com>
[not found] ` <fc4b5a0c-19dc-4741-b184-08b704444a1b@suse.com>
[not found] ` <3a847f18-750f-4bd2-9cac-37c4b9bdc84b@suse.com>
2025-03-27 14:13 ` [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) Borislav Petkov
2025-03-27 14:21 ` Jürgen Groß
2025-03-27 14:40 ` Borislav Petkov
2025-03-27 15:15 ` Jürgen Groß
2025-03-27 15:24 ` Borislav Petkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®