Files
odroid-linux/include/linux
Juri Lelli 2279f540ea sched/deadline: Fix priority inheritance with multiple scheduling classes
Glenn reported that "an application [he developed produces] a BUG in
deadline.c when a SCHED_DEADLINE task contends with CFS tasks on nested
PTHREAD_PRIO_INHERIT mutexes.  I believe the bug is triggered when a CFS
task that was boosted by a SCHED_DEADLINE task boosts another CFS task
(nested priority inheritance).

 ------------[ cut here ]------------
 kernel BUG at kernel/sched/deadline.c:1462!
 invalid opcode: 0000 [#1] PREEMPT SMP
 CPU: 12 PID: 19171 Comm: dl_boost_bug Tainted: ...
 Hardware name: ...
 RIP: 0010:enqueue_task_dl+0x335/0x910
 Code: ...
 RSP: 0018:ffffc9000c2bbc68 EFLAGS: 00010002
 RAX: 0000000000000009 RBX: ffff888c0af94c00 RCX: ffffffff81e12500
 RDX: 000000000000002e RSI: ffff888c0af94c00 RDI: ffff888c10b22600
 RBP: ffffc9000c2bbd08 R08: 0000000000000009 R09: 0000000000000078
 R10: ffffffff81e12440 R11: ffffffff81e1236c R12: ffff888bc8932600
 R13: ffff888c0af94eb8 R14: ffff888c10b22600 R15: ffff888bc8932600
 FS:  00007fa58ac55700(0000) GS:ffff888c10b00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007fa58b523230 CR3: 0000000bf44ab003 CR4: 00000000007606e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  ? intel_pstate_update_util_hwp+0x13/0x170
  rt_mutex_setprio+0x1cc/0x4b0
  task_blocks_on_rt_mutex+0x225/0x260
  rt_spin_lock_slowlock_locked+0xab/0x2d0
  rt_spin_lock_slowlock+0x50/0x80
  hrtimer_grab_expiry_lock+0x20/0x30
  hrtimer_cancel+0x13/0x30
  do_nanosleep+0xa0/0x150
  hrtimer_nanosleep+0xe1/0x230
  ? __hrtimer_init_sleeper+0x60/0x60
  __x64_sys_nanosleep+0x8d/0xa0
  do_syscall_64+0x4a/0x100
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
 RIP: 0033:0x7fa58b52330d
 ...
 ---[ end trace 0000000000000002 ]—

He also provided a simple reproducer creating the situation below:

 So the execution order of locking steps are the following
 (N1 and N2 are non-deadline tasks. D1 is a deadline task. M1 and M2
 are mutexes that are enabled * with priority inheritance.)

 Time moves forward as this timeline goes down:

 N1              N2               D1
 |               |                |
 |               |                |
 Lock(M1)        |                |
 |               |                |
 |             Lock(M2)           |
 |               |                |
 |               |              Lock(M2)
 |               |                |
 |             Lock(M1)           |
 |             (!!bug triggered!) |

Daniel reported a similar situation as well, by just letting ksoftirqd
run with DEADLINE (and eventually block on a mutex).

Problem is that boosted entities (Priority Inheritance) use static
DEADLINE parameters of the top priority waiter. However, there might be
cases where top waiter could be a non-DEADLINE entity that is currently
boosted by a DEADLINE entity from a different lock chain (i.e., nested
priority chains involving entities of non-DEADLINE classes). In this
case, top waiter static DEADLINE parameters could be null (initialized
to 0 at fork()) and replenish_dl_entity() would hit a BUG().

Fix this by keeping track of the original donor and using its parameters
when a task is boosted.

Reported-by: Glenn Elliott <glenn@aurora.tech>
Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Link: https://lkml.kernel.org/r/20201117061432.517340-1-juri.lelli@redhat.com
2020-11-17 13:15:28 +01:00
..
2020-08-03 18:19:23 -07:00
2019-12-11 09:12:38 +01:00
2019-11-12 11:43:29 -05:00
2020-06-25 22:25:13 -07:00
2020-06-16 14:19:57 +02:00
2020-07-27 14:55:22 +01:00
2020-05-24 20:48:11 +02:00
2020-07-21 08:24:52 -05:00
2020-07-08 10:48:35 -07:00
2020-07-21 13:26:26 -07:00
2020-04-10 15:36:21 -07:00
2020-06-24 17:08:31 +02:00
2019-10-09 19:33:43 -07:00
2020-03-09 11:12:19 +01:00
2019-12-03 11:20:37 +01:00
2020-06-16 19:25:20 +02:00
2020-07-27 14:29:23 -04:00
2020-05-04 11:19:58 -07:00
2020-01-18 09:19:18 -05:00
2020-06-17 00:07:38 +02:00
2020-03-06 11:06:15 +01:00
2020-08-14 19:56:56 -07:00
2020-05-28 07:59:45 -07:00
2020-07-24 17:12:41 -07:00
2020-04-30 12:54:01 -07:00
2020-08-04 21:02:38 -04:00
2019-10-04 12:31:46 -07:00
2019-10-15 13:34:25 +02:00
2020-07-24 17:12:41 -07:00
2020-05-18 10:30:21 +01:00
2020-08-26 12:41:56 +02:00
2019-12-04 19:44:14 -08:00
2020-06-02 15:15:46 +01:00
2019-12-11 09:12:38 +01:00
2020-09-04 09:25:20 -07:00
2020-05-08 18:18:11 +01:00
2020-05-08 00:12:42 +02:00
2020-05-28 10:31:09 +02:00
2020-03-06 11:56:59 +01:00
2020-09-04 12:46:07 +01:00
2019-08-14 15:30:35 +02:00
2020-07-31 18:08:59 +10:00
2019-11-14 19:06:47 -08:00
2020-05-09 13:57:12 +02:00
2020-07-01 10:49:02 +02:00
2020-07-23 17:34:18 +10:00
2020-04-02 09:35:27 -07:00
2020-09-04 12:46:06 +01:00
2020-05-15 13:51:28 -07:00
2020-05-09 13:57:12 +02:00
2020-08-18 17:06:15 +02:00
2020-07-16 23:19:51 +02:00
2020-02-21 10:31:18 +01:00
2020-08-07 11:33:24 -07:00
2020-05-17 14:10:07 -06:00
2020-05-14 16:44:24 +02:00
2020-05-04 09:16:37 -07:00
2020-07-04 09:35:36 -05:00
2020-01-14 12:20:48 +01:00
2020-07-07 11:58:59 -05:00
2020-08-01 11:28:17 +02:00
2020-04-01 12:06:26 -04:00
2020-04-17 06:05:30 -04:00
2020-06-26 00:27:38 -07:00
2019-11-14 12:20:02 +08:00