1. 15 Jul, 2018 2 commits
    • Juri Lelli's avatar
      sched/deadline: Fix switched_from_dl() warning · e117cb52
      Juri Lelli authored
      Mark noticed that syzkaller is able to reliably trigger the following warning:
      
        dl_rq->running_bw > dl_rq->this_bw
        WARNING: CPU: 1 PID: 153 at kernel/sched/deadline.c:124 switched_from_dl+0x454/0x608
        Kernel panic - not syncing: panic_on_warn set ...
      
        CPU: 1 PID: 153 Comm: syz-executor253 Not tainted 4.18.0-rc3+ #29
        Hardware name: linux,dummy-virt (DT)
        Call trace:
         dump_backtrace+0x0/0x458
         show_stack+0x20/0x30
         dump_stack+0x180/0x250
         panic+0x2dc/0x4ec
         __warn_printk+0x0/0x150
         report_bug+0x228/0x2d8
         bug_handler+0xa0/0x1a0
         brk_handler+0x2f0/0x568
         do_debug_exception+0x1bc/0x5d0
         el1_dbg+0x18/0x78
         switched_from_dl+0x454/0x608
         __sched_setscheduler+0x8cc/0x2018
         sys_sched_setattr+0x340/0x758
         el0_svc_naked+0x30/0x34
      
      syzkaller reproducer runs a bunch of threads that constantly switch
      between DEADLINE and NORMAL classes while interacting through futexes.
      
      The splat above is caused by the fact that if a DEADLINE task is setattr
      back to NORMAL while in non_contending state (blocked on a futex -
      inactive timer armed), its contribution to running_bw is not removed
      before sub_rq_bw() gets called (!task_on_rq_queued() branch) and the
      latter sees running_bw > this_bw.
      
      Fix it by removing a task contribution from running_bw if the task is
      not queued and in non_contending state while switched to a different
      class.
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJuri Lelli <juri.lelli@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarDaniel Bristot de Oliveira <bristot@redhat.com>
      Reviewed-by: default avatarLuca Abeni <luca.abeni@santannapisa.it>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: claudio@evidence.eu.com
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/20180711072948.27061-1-juri.lelli@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e117cb52
    • Isaac J. Manjarres's avatar
      stop_machine: Disable preemption when waking two stopper threads · 9fb8d5dc
      Isaac J. Manjarres authored
      When cpu_stop_queue_two_works() begins to wake the stopper threads, it does
      so without preemption disabled, which leads to the following race
      condition:
      
      The source CPU calls cpu_stop_queue_two_works(), with cpu1 as the source
      CPU, and cpu2 as the destination CPU. When adding the stopper threads to
      the wake queue used in this function, the source CPU stopper thread is
      added first, and the destination CPU stopper thread is added last.
      
      When wake_up_q() is invoked to wake the stopper threads, the threads are
      woken up in the order that they are queued in, so the source CPU's stopper
      thread is woken up first, and it preempts the thread running on the source
      CPU.
      
      The stopper thread will then execute on the source CPU, disable preemption,
      and begin executing multi_cpu_stop(), and wait for an ack from the
      destination CPU's stopper thread, with preemption still disabled. Since the
      worker thread that woke up the stopper thread on the source CPU is affine
      to the source CPU, and preemption is disabled on the source CPU, that
      thread will never run to dequeue the destination CPU's stopper thread from
      the wake queue, and thus, the destination CPU's stopper thread will never
      run, causing the source CPU's stopper thread to wait forever, and stall.
      
      Disable preemption when waking the stopper threads in
      cpu_stop_queue_two_works().
      
      Fixes: 0b26351b ("stop_machine, sched: Fix migrate_swap() vs. active_balance() deadlock")
      Co-Developed-by: default avatarPrasad Sodagudi <psodagud@codeaurora.org>
      Signed-off-by: default avatarPrasad Sodagudi <psodagud@codeaurora.org>
      Co-Developed-by: default avatarPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: default avatarPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: default avatarIsaac J. Manjarres <isaacm@codeaurora.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Cc: matt@codeblueprint.co.uk
      Cc: bigeasy@linutronix.de
      Cc: gregkh@linuxfoundation.org
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1530655334-4601-1-git-send-email-isaacm@codeaurora.org
      9fb8d5dc
  2. 14 Jul, 2018 16 commits
  3. 13 Jul, 2018 15 commits
  4. 12 Jul, 2018 7 commits