[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 24.07.24 08:54, Jan Beulich wrote:
On 24.07.2024 08:07, Juergen Gross wrote:
On 24.07.24 03:08, kernel test robot wrote:
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
head:   368990a7fe30737c990f628a60d26d9854a9e690
commit: 368990a7fe30737c990f628a60d26d9854a9e690 [12/12] xen: fix multicall 
debug data referencing
config: x86_64-randconfig-012-20240724 
(https://download.01.org/0day-ci/archive/20240724/202407240907.u0NJHgTu-lkp@xxxxxxxxx/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240724/202407240907.u0NJHgTu-lkp@xxxxxxxxx/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@xxxxxxxxx>
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202407240907.u0NJHgTu-lkp@xxxxxxxxx/

All warnings (new ones prefixed by >>, old ones prefixed by <<):

WARNING: modpost: vmlinux: section mismatch in reference: mc_debug_data+0x0 
(section: .data) -> mc_debug_data_early (section: .init.data)

With current infrastructure this is not easily fixable, as there is no way
to tag a percpu variable as __refdata.

Would it be an option to drop the static initializer and set CPU0's value
from xen_parse_mc_debug()?

It would hide this warning, yes.

OTOH I have another patch pending which will have the same problem, and this
time the solution would be more ugly, as the code would always be active in
a PV guest (yes, I could add an init function called very early during boot,
but ...).

I'd prefer a general way to handle this problem, like e.g. some kind of
__refdata tagging for percpu variables.


Juergen



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.