Hi Juri, [FYI, it's a private test report for your RFC patch.] [auto build test WARNING on tip/sched/core] [also build test WARNING on v5.8 next-20200806] [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] url: https://github.com/0day-ci/linux/commits/Juri-Lelli/SCHED_DEADLINE-server... base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 949bcb8135a96a6923e676646bd29cbe69e8350f compiler: alpha-linux-gcc (GCC) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com&gt; cppcheck warnings: (new ones prefixed by >>) struct rq *rq = rq_of_dl_se(dl_se); ^ kernel/sched/deadline.c:1067:13: note: Shadowed declaration struct rq *rq; ^ kernel/sched/deadline.c:1070:14: note: Shadow variable struct rq *rq = rq_of_dl_se(dl_se); ^ struct rq_flags rf; ^ kernel/sched/deadline.c:1066:18: note: Shadowed declaration struct rq_flags rf; ^ kernel/sched/deadline.c:1071:19: note: Shadow variable struct rq_flags rf; ^ vim +1070 kernel/sched/deadline.c 1046 1047 /* 1048 * This is the bandwidth enforcement timer callback. If here, we know 1049 * a task is not on its dl_rq, since the fact that the timer was running 1050 * means the task is throttled and needs a runtime replenishment. 1051 * 1052 * However, what we actually do depends on the fact the task is active, 1053 * (it is on its rq) or has been removed from there by a call to 1054 * dequeue_task_dl(). In the former case we must issue the runtime 1055 * replenishment and add the task back to the dl_rq; in the latter, we just 1056 * do nothing but clearing dl_throttled, so that runtime and deadline 1057 * updating (and the queueing back to dl_rq) will be done by the 1058 * next call to enqueue_task_dl(). 1059 */ 1060 static enum hrtimer_restart dl_task_timer(struct hrtimer *timer) 1061 { 1062 struct sched_dl_entity *dl_se = container_of(timer, 1063 struct sched_dl_entity, 1064 dl_timer); 1065 struct task_struct *p; 1066 struct rq_flags rf; 1067 struct rq *rq; 1068 1069 if (dl_server(dl_se)) { 1072 1073 rq_lock(rq, &rf); 1074 if (dl_se->dl_throttled) { 1075 sched_clock_tick(); 1076 update_rq_clock(rq); 1077 1078 if (dl_se->server_has_tasks(dl_se)) { 1079 enqueue_dl_entity(dl_se, dl_se, ENQUEUE_REPLENISH); 1080 resched_curr(rq); 1081 __push_dl_task(rq, &rf); 1082 } else { 1083 replenish_dl_entity(dl_se, dl_se); 1084 } 1085 1086 } 1087 rq_unlock(rq, &rf); 1088 1089 return HRTIMER_NORESTART; 1090 } 1091 1092 p = dl_task_of(dl_se); 1093 rq = task_rq_lock(p, &rf); 1094 1095 /* 1096 * The task might have changed its scheduling policy to something 1097 * different than SCHED_DEADLINE (through switched_from_dl()). 1098 */ 1099 if (!dl_task(p)) 1100 goto unlock; 1101 1102 /* 1103 * The task might have been boosted by someone else and might be in the 1104 * boosting/deboosting path, its not throttled. 1105 */ 1106 if (dl_se->dl_boosted) 1107 goto unlock; 1108 1109 /* 1110 * Spurious timer due to start_dl_timer() race; or we already received 1111 * a replenishment from rt_mutex_setprio(). 1112 */ 1113 if (!dl_se->dl_throttled) 1114 goto unlock; 1115 1116 sched_clock_tick(); 1117 update_rq_clock(rq); 1118 1119 /* 1120 * If the throttle happened during sched-out; like: 1121 * 1122 * schedule() 1123 * deactivate_task() 1124 * dequeue_task_dl() 1125 * update_curr_dl() 1126 * start_dl_timer() 1127 * __dequeue_task_dl() 1128 * prev->on_rq = 0; 1129 * 1130 * We can be both throttled and !queued. Replenish the counter 1131 * but do not enqueue -- wait for our wakeup to do that. 1132 */ 1133 if (!task_on_rq_queued(p)) { 1134 replenish_dl_entity(dl_se, dl_se); 1135 goto unlock; 1136 } 1137 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org