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-...@intel.com/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-...@intel.com/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 <l...@intel.com>
| Closes:
https://lore.kernel.org/oe-kbuild-all/202407240907.u0njhgtu-...@intel.com/
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
