1. Feb 01, 2017
  2. Jan 31, 2017
  3. Jan 30, 2017
    • Sebastian Andrzej Siewior's avatar
      sched/rt: Add a missing rescheduling point · 619bd4a7
      Sebastian Andrzej Siewior authored
      Since the change in commit:
      
        fd7a4bed
      
       ("sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks")
      
      ... we don't reschedule a task under certain circumstances:
      
      Lets say task-A, SCHED_OTHER, is running on CPU0 (and it may run only on
      CPU0) and holds a PI lock. This task is removed from the CPU because it
      used up its time slice and another SCHED_OTHER task is running. Task-B on
      CPU1 runs at RT priority and asks for the lock owned by task-A. This
      results in a priority boost for task-A. Task-B goes to sleep until the
      lock has been made available. Task-A is already runnable (but not active),
      so it receives no wake up.
      
      The reality now is that task-A gets on the CPU once the scheduler decides
      to remove the current task despite the fact that a high priority task is
      enqueued and waiting. This may take a long time.
      
      The desired behaviour is that CPU0 immediately reschedules after the
      priority boost which made task-A the task with the lowest priority.
      
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: fd7a4bed ("sched, rt: Convert switched_{from, to}_rt() prio_changed_rt() to balance callbacks")
      Link: http://lkml.kernel.org/r/20170124144006.29821-1-bigeasy@linutronix.de
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      619bd4a7
    • Mathieu Poirier's avatar
      sched/core: Fix &rd->cpudl memory leak · 4b12db93
      Mathieu Poirier authored
      
      
      While in the process of initialising a root domain, if function
      cpupri_init() fails the memory allocated in cpudl_init() is not
      reclaimed.
      
      Adding a new goto target to cleanup the previous initialistion of
      the root_domain's dl_bw structure reclaims said memory.
      
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1485292295-21298-2-git-send-email-mathieu.poirier@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4b12db93
    • Mathieu Poirier's avatar
      sched/core: Fix &rd->rto_mask memory leak · 92c99ac8
      Mathieu Poirier authored
      
      
      If function cpudl_init() fails the memory allocated for &rd->rto_mask
      needs to be freed, something this patch is addressing.
      
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1485292295-21298-1-git-send-email-mathieu.poirier@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      92c99ac8
    • Matt Fleming's avatar
      sched/fair: Restore previous rq_flags when migrating tasks in hotplug · 4d25b35e
      Matt Fleming authored
      
      
      __migrate_task() can return with a different runqueue locked than the
      one we passed as an argument. So that we can repin the lock in
      migrate_tasks() (and keep the update_rq_clock() bit) we need to
      restore the old rq_flags before repinning.
      
      Note that it wouldn't be correct to change move_queued_task() to repin
      because of the change of runqueue and the fact that having an
      up-to-date clock on the initial rq doesn't mean the new rq has one
      too.
      
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4d25b35e
    • Peter Zijlstra's avatar
      sched/core: Add missing update_rq_clock() call in sched_move_task() · 1b1d6225
      Peter Zijlstra authored
      
      
      Bug was noticed via this warning:
      
        WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80
        rq->clock_update_flags < RQCF_ACT_SKIP
        Modules linked in:
        CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1
        Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014
        Call Trace:
         dump_stack+0x4d/0x65
         __warn+0xcb/0xf0
         warn_slowpath_fmt+0x5f/0x80
         detach_task_cfs_rq+0x8e8/0xb80
         ? allocate_cgrp_cset_links+0x59/0x80
         task_change_group_fair+0x27/0x150
         sched_change_group+0x48/0xf0
         sched_move_task+0x53/0x150
         cpu_cgroup_attach+0x36/0x70
         cgroup_taskset_migrate+0x175/0x300
         cgroup_migrate+0xab/0xd0
         cgroup_attach_task+0xf0/0x190
         __cgroup_procs_write+0x1ed/0x2f0
         cgroup_procs_write+0x14/0x20
         cgroup_file_write+0x3f/0x100
         kernfs_fop_write+0x104/0x180
         __vfs_write+0x37/0x140
         vfs_write+0xb8/0x1b0
         SyS_write+0x55/0xc0
         do_syscall_64+0x61/0x170
         entry_SYSCALL64_slow_path+0x25/0x25
      
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1b1d6225
    • Peter Zijlstra's avatar
      sched/core: Optimize pick_next_task() for idle_sched_class · 49ee5768
      Peter Zijlstra authored
      
      
      Steve noticed that when we switch from IDLE to SCHED_OTHER we fail to
      take the shortcut, even though all runnable tasks are of the fair
      class, because prev->sched_class != &fair_sched_class.
      
      Since I reworked the put_prev_task() stuff, we don't really care about
      prev->class here, so removing that condition will allow this case.
      
      This increases the likely case from 78% to 98% correct for Steve's
      workload.
      
      Reported-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Tested-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170119174408.GN6485@twins.programming.kicks-ass.net
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      49ee5768
    • Linus Torvalds's avatar
      Linux 4.10-rc6 · 566cf877
      Linus Torvalds authored
      566cf877
    • Linus Torvalds's avatar
      drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj() · 39cb2c9a
      Linus Torvalds authored
      I've seen this trigger twice now, where the i915_gem_object_to_ggtt()
      call in intel_unpin_fb_obj() returns NULL, resulting in an oops
      immediately afterwards as the (inlined) call to i915_vma_unpin_fence()
      tries to dereference it.
      
      It seems to be some race condition where the object is going away at
      shutdown time, since both times happened when shutting down the X
      server.  The call chains were different:
      
       - VT ioctl(KDSETMODE, KD_TEXT):
      
          intel_cleanup_plane_fb+0x5b/0xa0 [i915]
          drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper]
          intel_atomic_commit_tail+0x749/0xfe0 [i915]
          intel_atomic_commit+0x3cb/0x4f0 [i915]
          drm_atomic_commit+0x4b/0x50 [drm]
          restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper]
          drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
          drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
          intel_fbdev_set_par+0x18/0x70 [i915]
          fb_set_var+0x236/0x460
          fbcon_blank+0x30f/0x350
          do_unblank_screen+0xd2/0x1a0
          vt_ioctl+0x507/0x12a0
          tty_ioctl+0x355/0xc30
          do_vfs_ioctl+0xa3/0x5e0
          SyS_ioctl+0x79/0x90
          entry_SYSCALL_64_fastpath+0x13/0x94
      
       - i915 unpin_work workqueue:
      
          intel_unpin_work_fn+0x58/0x140 [i915]
          process_one_work+0x1f1/0x480
          worker_thread+0x48/0x4d0
          kthread+0x101/0x140
      
      and this patch purely papers over the issue by adding a NULL pointer
      check and a WARN_ON_ONCE() to avoid the oops that would then generally
      make the machine unresponsive.
      
      Other callers of i915_gem_object_to_ggtt() seem to also check for the
      returned pointer being NULL and warn about it, so this clearly has
      happened before in other places.
      
      [ Reported it originally to the i915 developers on Jan 8, applying the
        ugly workaround on my own now after triggering the problem for the
        second time with no feedback.
      
        This is likely to be the same bug reported as
      
           https://bugs.freedesktop.org/show_bug.cgi?id=98829
           https://bugs.freedesktop.org/show_bug.cgi?id=99134
      
      
      
        which has a patch for the underlying problem, but it hasn't gotten to
        me, so I'm applying the workaround. ]
      
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Imre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      39cb2c9a
    • Linus Torvalds's avatar
      Merge branch 'parisc-4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 2c5d9555
      Linus Torvalds authored
      Pull two parisc fixes from Helge Deller:
       "One fix to avoid usage of BITS_PER_LONG in user-space exported swab.h
        header which breaks compiling qemu, and one trivial fix for printk
        continuation in the parisc parport driver"
      
      * 'parisc-4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Don't use BITS_PER_LONG in userspace-exported swab.h header
        parisc, parport_gsc: Fixes for printk continuation lines
      2c5d9555
  4. Jan 29, 2017