From: kernel test robot <lkp@intel.com>
To: Yicong Yang <yangyicong@huawei.com>,
catalin.marinas@arm.com, will@kernel.org, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
Cc: oe-kbuild-all@lists.linux.dev, gregkh@linuxfoundation.org,
rafael@kernel.org, jonathan.cameron@huawei.com,
prime.zeng@hisilicon.com, linuxarm@huawei.com,
yangyicong@hisilicon.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arch_topology: Support SMT control on arm64
Date: Wed, 20 Sep 2023 07:30:50 +0800 [thread overview]
Message-ID: <202309200727.CtYl75aH-lkp@intel.com> (raw)
In-Reply-To: <20230919123319.23785-1-yangyicong@huawei.com>
Hi Yicong,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on driver-core/driver-core-testing driver-core/driver-core-next driver-core/driver-core-linus linus/master v6.6-rc2 next-20230919]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Yicong-Yang/arch_topology-Support-SMT-control-on-arm64/20230919-223458
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20230919123319.23785-1-yangyicong%40huawei.com
patch subject: [PATCH] arch_topology: Support SMT control on arm64
config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20230920/202309200727.CtYl75aH-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20230920/202309200727.CtYl75aH-lkp@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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202309200727.CtYl75aH-lkp@intel.com/
All errors (new ones prefixed by >>):
kernel/cpu.c: In function 'cpuhp_get_primary_thread_mask':
kernel/cpu.c:660:16: error: 'cpu_primary_thread_mask' undeclared (first use in this function); did you mean 'cpuhp_get_primary_thread_mask'?
660 | return cpu_primary_thread_mask;
| ^~~~~~~~~~~~~~~~~~~~~~~
| cpuhp_get_primary_thread_mask
kernel/cpu.c:660:16: note: each undeclared identifier is reported only once for each function it appears in
kernel/cpu.c: In function 'cpuhp_smt_disable':
>> kernel/cpu.c:2629:23: error: implicit declaration of function 'cpu_down_maps_locked' [-Werror=implicit-function-declaration]
2629 | ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
| ^~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/cpu_down_maps_locked +2629 kernel/cpu.c
dc8d37ed304eee Arnd Bergmann 2019-12-10 2620
dc8d37ed304eee Arnd Bergmann 2019-12-10 2621 int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
dc8d37ed304eee Arnd Bergmann 2019-12-10 2622 {
dc8d37ed304eee Arnd Bergmann 2019-12-10 2623 int cpu, ret = 0;
dc8d37ed304eee Arnd Bergmann 2019-12-10 2624
dc8d37ed304eee Arnd Bergmann 2019-12-10 2625 cpu_maps_update_begin();
dc8d37ed304eee Arnd Bergmann 2019-12-10 2626 for_each_online_cpu(cpu) {
dc8d37ed304eee Arnd Bergmann 2019-12-10 2627 if (topology_is_primary_thread(cpu))
dc8d37ed304eee Arnd Bergmann 2019-12-10 2628 continue;
dc8d37ed304eee Arnd Bergmann 2019-12-10 @2629 ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
dc8d37ed304eee Arnd Bergmann 2019-12-10 2630 if (ret)
dc8d37ed304eee Arnd Bergmann 2019-12-10 2631 break;
dc8d37ed304eee Arnd Bergmann 2019-12-10 2632 /*
dc8d37ed304eee Arnd Bergmann 2019-12-10 2633 * As this needs to hold the cpu maps lock it's impossible
dc8d37ed304eee Arnd Bergmann 2019-12-10 2634 * to call device_offline() because that ends up calling
dc8d37ed304eee Arnd Bergmann 2019-12-10 2635 * cpu_down() which takes cpu maps lock. cpu maps lock
dc8d37ed304eee Arnd Bergmann 2019-12-10 2636 * needs to be held as this might race against in kernel
dc8d37ed304eee Arnd Bergmann 2019-12-10 2637 * abusers of the hotplug machinery (thermal management).
dc8d37ed304eee Arnd Bergmann 2019-12-10 2638 *
dc8d37ed304eee Arnd Bergmann 2019-12-10 2639 * So nothing would update device:offline state. That would
dc8d37ed304eee Arnd Bergmann 2019-12-10 2640 * leave the sysfs entry stale and prevent onlining after
dc8d37ed304eee Arnd Bergmann 2019-12-10 2641 * smt control has been changed to 'off' again. This is
dc8d37ed304eee Arnd Bergmann 2019-12-10 2642 * called under the sysfs hotplug lock, so it is properly
dc8d37ed304eee Arnd Bergmann 2019-12-10 2643 * serialized against the regular offline usage.
dc8d37ed304eee Arnd Bergmann 2019-12-10 2644 */
dc8d37ed304eee Arnd Bergmann 2019-12-10 2645 cpuhp_offline_cpu_device(cpu);
dc8d37ed304eee Arnd Bergmann 2019-12-10 2646 }
dc8d37ed304eee Arnd Bergmann 2019-12-10 2647 if (!ret)
dc8d37ed304eee Arnd Bergmann 2019-12-10 2648 cpu_smt_control = ctrlval;
dc8d37ed304eee Arnd Bergmann 2019-12-10 2649 cpu_maps_update_done();
dc8d37ed304eee Arnd Bergmann 2019-12-10 2650 return ret;
dc8d37ed304eee Arnd Bergmann 2019-12-10 2651 }
dc8d37ed304eee Arnd Bergmann 2019-12-10 2652
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2023-09-19 23:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 12:33 [PATCH] arch_topology: Support SMT control on arm64 Yicong Yang
2023-09-19 23:30 ` kernel test robot [this message]
2023-09-20 1:36 ` Yicong Yang
2023-09-20 17:08 ` Dietmar Eggemann
2023-09-21 8:56 ` Yicong Yang
2023-09-22 11:13 ` Dietmar Eggemann
2023-09-21 15:03 ` Sudeep Holla
2023-09-22 9:46 ` Yicong Yang
2023-09-27 11:53 ` Yicong Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202309200727.CtYl75aH-lkp@intel.com \
--to=lkp@intel.com \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathan.cameron@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=prime.zeng@hisilicon.com \
--cc=rafael@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=will@kernel.org \
--cc=yangyicong@hisilicon.com \
--cc=yangyicong@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox