[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240817083158.2079-1-hdanton@sina.com>
Date: Sat, 17 Aug 2024 16:31:58 +0800
From: Hillf Danton <hdanton@...a.com>
To: syzbot <syzbot+ca14b36a46a8c541b509@...kaller.appspotmail.com>
Cc: linux-kernel@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [cgroups?] possible deadlock in task_rq_lock
On Fri, 16 Aug 2024 23:52:22 -0700
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 367b5c3d53e5 Add linux-next specific files for 20240816
> git tree: linux-next
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=142413c5980000
#syz test linux-next 367b5c3d53e5
--- x/kernel/sched/deadline.c
+++ y/kernel/sched/deadline.c
@@ -1498,6 +1498,9 @@ static void update_curr_dl_se(struct rq
* starting a new period, pushing the activation.
*/
if (dl_se->dl_defer && dl_se->dl_throttled && dl_runtime_exceeded(dl_se)) {
+ bool lock = rq != dl_se->rq;
+ struct rq_flags rf;
+ struct rq *__rq = dl_se->rq;
/*
* If the server was previously activated - the starving condition
* took place, it this point it went away because the fair scheduler
@@ -1508,7 +1511,11 @@ static void update_curr_dl_se(struct rq
hrtimer_try_to_cancel(&dl_se->dl_timer);
+ if (lock)
+ rq_lock(__rq, &rf);
replenish_dl_new_period(dl_se, dl_se->rq);
+ if (lock)
+ rq_unlock(__rq, &rf);
/*
* Not being able to start the timer seems problematic. If it could not
--
Powered by blists - more mailing lists