From: Christian Loehle <christian.loehle@arm.com>
To: kernel test robot <lkp@intel.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: kernel/sched/core.c:1361:21: warning: 'uclamp_mutex' defined but not used
Date: Mon, 7 Oct 2024 11:08:36 +0100 [thread overview]
Message-ID: <7d19367b-a4ac-4c65-a543-9a4d614bec44@arm.com> (raw)
In-Reply-To: <202410060258.bPl2ZoUo-lkp@intel.com>
On 10/5/24 19:58, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 27cc6fdf720183dce1dbd293483ec5a9cb6b595e
> commit: d2d6422f8bd17c6bb205133e290625a564194496 x86: Allow to enable PREEMPT_RT.
> date: 3 weeks ago
> config: x86_64-buildonly-randconfig-002-20241006 (https://download.01.org/0day-ci/archive/20241006/202410060258.bPl2ZoUo-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241006/202410060258.bPl2ZoUo-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/202410060258.bPl2ZoUo-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> In file included from include/linux/seqlock.h:19,
> from include/linux/dcache.h:11,
> from include/linux/fs.h:8,
> from include/linux/highmem.h:5,
> from kernel/sched/core.c:10:
>>> kernel/sched/core.c:1361:21: warning: 'uclamp_mutex' defined but not used [-Wunused-variable]
> 1361 | static DEFINE_MUTEX(uclamp_mutex);
> | ^~~~~~~~~~~~
> include/linux/mutex.h:101:22: note: in definition of macro 'DEFINE_MUTEX'
> 101 | struct mutex mutexname = __MUTEX_INITIALIZER(mutexname)
> | ^~~~~~~~~
>
>
> vim +/uclamp_mutex +1361 kernel/sched/core.c
>
> 71f8bd4600521f kernel/sched.c Ingo Molnar 2007-07-09 1349
> 69842cba9ace84 kernel/sched/core.c Patrick Bellasi 2019-06-21 1350 #ifdef CONFIG_UCLAMP_TASK
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1351 /*
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1352 * Serializes updates of utilization clamp values
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1353 *
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1354 * The (slow-path) user-space triggers utilization clamp value updates which
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1355 * can require updates on (fast-path) scheduler's data structures used to
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1356 * support enqueue/dequeue operations.
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1357 * While the per-CPU rq lock protects fast-path update operations, user-space
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1358 * requests are serialized using a mutex to reduce the risk of conflicting
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1359 * updates or API abuses.
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1360 */
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 @1361 static DEFINE_MUTEX(uclamp_mutex);
> 2480c093130f64 kernel/sched/core.c Patrick Bellasi 2019-08-22 1362
>
> :::::: The code at line 1361 was first introduced by commit
> :::::: 2480c093130f64ac3a410504fa8b3db1fc4b87ce sched/uclamp: Extend CPU's cgroup controller
>
> :::::: TO: Patrick Bellasi <patrick.bellasi@arm.com>
> :::::: CC: Ingo Molnar <mingo@kernel.org>
>
Please allow me a day to walk through the code just to double-check, but
the obvious fixes are either letting UCLAMP_TASK depend on SYSCTL or:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 43e453ab7e20..18d9622eac8d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1394,7 +1394,9 @@ void set_load_weight(struct task_struct *p, bool update_load)
* requests are serialized using a mutex to reduce the risk of conflicting
* updates or API abuses.
*/
+#if defined(CONFIG_UCLAMP_TASK_GROUP) || defined(CONFIG_SYSCTL)
static DEFINE_MUTEX(uclamp_mutex);
+#endif
/* Max allowed minimum utilization */
static unsigned int __maybe_unused sysctl_sched_uclamp_util_min = SCHED_CAPACITY_SCALE;
next prev parent reply other threads:[~2024-10-07 10:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-05 18:58 kernel test robot
2024-10-07 10:08 ` Christian Loehle [this message]
2024-10-25 6:32 ` Sebastian Andrzej Siewior
2024-10-25 9:58 ` Christian Loehle
2024-10-24 20:34 kernel test robot
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=7d19367b-a4ac-4c65-a543-9a4d614bec44@arm.com \
--to=christian.loehle@arm.com \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®