Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [tip:sched/core 8/10] kernel/sched/deadline.c:1441:16: error: use of undeclared identifier 'd_se'; did you mean 'dl_se'?
Date: Tue, 11 Nov 2025 21:27:12 +0800	[thread overview]
Message-ID: <202511112120.vStICnyl-lkp@intel.com> (raw)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
head:   46f61fb2e7678daae743d601efac3b957041ed56
commit: b75a19b9d73e0deb5f761884228b8b15694e2858 [8/10] sched/deadline: Document dl_server
config: loongarch-allnoconfig (https://download.01.org/0day-ci/archive/20251111/202511112120.vStICnyl-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 996639d6ebb86ff15a8c99b67f1c2e2117636ae7)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251111/202511112120.vStICnyl-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/202511112120.vStICnyl-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from kernel/sched/build_policy.c:58:
>> kernel/sched/deadline.c:1441:16: error: use of undeclared identifier 'd_se'; did you mean 'dl_se'?
    1441 |         if (dl_server(d_se) && dl_se->dl_throttled && !dl_se->dl_defer)
         |                       ^~~~
         |                       dl_se
   kernel/sched/deadline.c:1430:70: note: 'dl_se' declared here
    1430 | static void update_curr_dl_se(struct rq *rq, struct sched_dl_entity *dl_se, s64 delta_exec)
         |                                                                      ^
   1 error generated.


vim +1441 kernel/sched/deadline.c

  1429	
  1430	static void update_curr_dl_se(struct rq *rq, struct sched_dl_entity *dl_se, s64 delta_exec)
  1431	{
  1432		bool idle = rq->curr == rq->idle;
  1433		s64 scaled_delta_exec;
  1434	
  1435		if (unlikely(delta_exec <= 0)) {
  1436			if (unlikely(dl_se->dl_yielded))
  1437				goto throttle;
  1438			return;
  1439		}
  1440	
> 1441		if (dl_server(d_se) && dl_se->dl_throttled && !dl_se->dl_defer)
  1442			return;
  1443	
  1444		if (dl_entity_is_special(dl_se))
  1445			return;
  1446	
  1447		scaled_delta_exec = delta_exec;
  1448		if (!dl_server(dl_se))
  1449			scaled_delta_exec = dl_scaled_delta_exec(rq, dl_se, delta_exec);
  1450	
  1451		dl_se->runtime -= scaled_delta_exec;
  1452	
  1453		if (dl_se->dl_defer_idle && !idle)
  1454			dl_se->dl_defer_idle = 0;
  1455	
  1456		/*
  1457		 * The fair server can consume its runtime while throttled (not queued/
  1458		 * running as regular CFS).
  1459		 *
  1460		 * If the server consumes its entire runtime in this state. The server
  1461		 * is not required for the current period. Thus, reset the server by
  1462		 * starting a new period, pushing the activation.
  1463		 */
  1464		if (dl_se->dl_defer && dl_se->dl_throttled && dl_runtime_exceeded(dl_se)) {
  1465			/*
  1466			 * Non-servers would never get time accounted while throttled.
  1467			 */
  1468			WARN_ON_ONCE(!dl_server(dl_se));
  1469	
  1470			/*
  1471			 * While the server is marked idle, do not push out the
  1472			 * activation further, instead wait for the period timer
  1473			 * to lapse and stop the server.
  1474			 */
  1475			if (dl_se->dl_defer_idle && idle) {
  1476				/*
  1477				 * The timer is at the zero-laxity point, this means
  1478				 * dl_server_stop() / dl_server_start() can happen
  1479				 * while now < deadline. This means update_dl_entity()
  1480				 * will not replenish. Additionally start_dl_timer()
  1481				 * will be set for 'deadline - runtime'. Negative
  1482				 * runtime will not do.
  1483				 */
  1484				dl_se->runtime = 0;
  1485				return;
  1486			}
  1487	
  1488			/*
  1489			 * If the server was previously activated - the starving condition
  1490			 * took place, it this point it went away because the fair scheduler
  1491			 * was able to get runtime in background. So return to the initial
  1492			 * state.
  1493			 */
  1494			dl_se->dl_defer_running = 0;
  1495	
  1496			hrtimer_try_to_cancel(&dl_se->dl_timer);
  1497	
  1498			replenish_dl_new_period(dl_se, dl_se->rq);
  1499	
  1500			if (idle)
  1501				dl_se->dl_defer_idle = 1;
  1502	
  1503			/*
  1504			 * Not being able to start the timer seems problematic. If it could not
  1505			 * be started for whatever reason, we need to "unthrottle" the DL server
  1506			 * and queue right away. Otherwise nothing might queue it. That's similar
  1507			 * to what enqueue_dl_entity() does on start_dl_timer==0. For now, just warn.
  1508			 */
  1509			WARN_ON_ONCE(!start_dl_timer(dl_se));
  1510	
  1511			return;
  1512		}
  1513	
  1514	throttle:
  1515		if (dl_runtime_exceeded(dl_se) || dl_se->dl_yielded) {
  1516			dl_se->dl_throttled = 1;
  1517	
  1518			/* If requested, inform the user about runtime overruns. */
  1519			if (dl_runtime_exceeded(dl_se) &&
  1520			    (dl_se->flags & SCHED_FLAG_DL_OVERRUN))
  1521				dl_se->dl_overrun = 1;
  1522	
  1523			dequeue_dl_entity(dl_se, 0);
  1524			if (!dl_server(dl_se)) {
  1525				update_stats_dequeue_dl(&rq->dl, dl_se, 0);
  1526				dequeue_pushable_dl_task(rq, dl_task_of(dl_se));
  1527			}
  1528	
  1529			if (unlikely(is_dl_boosted(dl_se) || !start_dl_timer(dl_se))) {
  1530				if (dl_server(dl_se)) {
  1531					replenish_dl_new_period(dl_se, rq);
  1532					start_dl_timer(dl_se);
  1533				} else {
  1534					enqueue_task_dl(rq, dl_task_of(dl_se), ENQUEUE_REPLENISH);
  1535				}
  1536			}
  1537	
  1538			if (!is_leftmost(dl_se, &rq->dl))
  1539				resched_curr(rq);
  1540		}
  1541	
  1542		/*
  1543		 * The fair server (sole dl_server) does not account for real-time
  1544		 * workload because it is running fair work.
  1545		 */
  1546		if (dl_se == &rq->fair_server)
  1547			return;
  1548	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

             reply	other threads:[~2025-11-11 13:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 13:27 kernel test robot [this message]
2025-11-11 16:29 ` [tip:sched/core 8/10] kernel/sched/deadline.c:1441:16: error: use of undeclared identifier 'd_se'; did you mean 'dl_se'? Peter Zijlstra

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=202511112120.vStICnyl-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /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