1. 18 Apr, 2017 14 commits
    • Vishal Thanki's avatar
      rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB · 31c576a5
      Vishal Thanki authored
      commit a083c8fd upstream.
      
      In device removal routine, usage of "#ifdef CONFIG_RT2X00_LIB_USB"
      will not cover the case when it is configured as module. This will
      omit the entire if-block which does cleanup of URBs and cancellation
      of pending work. Changing the #ifdef to #if IS_ENABLED() to fix it.
      Signed-off-by: default avatarVishal Thanki <vishalthanki@gmail.com>
      Acked-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31c576a5
    • Stanislaw Gruszka's avatar
      rt2x00usb: do not anchor rx and tx urb's · f0df317b
      Stanislaw Gruszka authored
      commit 93c7018e upstream.
      
      We might kill TX or RX urb during rt2x00usb_flush_entry(), what can
      cause anchor list corruption like shown below:
      
      [ 2074.035633] WARNING: CPU: 2 PID: 14480 at lib/list_debug.c:33 __list_add+0xac/0xc0
      [ 2074.035634] list_add corruption. prev->next should be next (ffff88020f362c28), but was dead000000000100. (prev=ffff8801d161bb70).
      <snip>
      [ 2074.035670] Call Trace:
      [ 2074.035672]  [<ffffffff813bde47>] dump_stack+0x63/0x8c
      [ 2074.035674]  [<ffffffff810a2231>] __warn+0xd1/0xf0
      [ 2074.035676]  [<ffffffff810a22af>] warn_slowpath_fmt+0x5f/0x80
      [ 2074.035678]  [<ffffffffa073855d>] ? rt2x00usb_register_write_lock+0x3d/0x60 [rt2800usb]
      [ 2074.035679]  [<ffffffff813dbe4c>] __list_add+0xac/0xc0
      [ 2074.035681]  [<ffffffff81591c6c>] usb_anchor_urb+0x4c/0xa0
      [ 2074.035683]  [<ffffffffa07322af>] rt2x00usb_kick_rx_entry+0xaf/0x100 [rt2x00usb]
      [ 2074.035684]  [<ffffffffa0732322>] rt2x00usb_clear_entry+0x22/0x30 [rt2x00usb]
      
      To fix do not anchor TX and RX urb's, it is not needed as during
      shutdown we kill those urbs in rt2x00usb_free_entries().
      
      Cc: Vishal Thanki <vishalthanki@gmail.com>
      Fixes: 8b4c0009 ("rt2x00usb: Use usb anchor to manage URB")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0df317b
    • Stanislaw Gruszka's avatar
      rt2x00usb: fix anchor initialization · cb794d57
      Stanislaw Gruszka authored
      commit 0488a612 upstream.
      
      If device fail to initialize we can OOPS in rt2x00lib_remove_dev(), due
      to using uninitialized usb_anchor structure:
      
      [  855.435820] ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1000 with error -19
      [  855.435826] ieee80211 phy3: rt2800_probe_rt: Error - Invalid RT chipset 0x0000, rev 0000 detected
      [  855.435829] ieee80211 phy3: rt2x00lib_probe_dev: Error - Failed to allocate device
      [  855.435845] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      [  855.435900] IP: _raw_spin_lock_irq+0xd/0x30
      [  855.435926] PGD 0
      [  855.435953] Oops: 0002 [#1] SMP
      <snip>
      [  855.437011] Call Trace:
      [  855.437029]  ? usb_kill_anchored_urbs+0x27/0xc0
      [  855.437061]  rt2x00lib_remove_dev+0x190/0x1c0 [rt2x00lib]
      [  855.437097]  rt2x00lib_probe_dev+0x246/0x7a0 [rt2x00lib]
      [  855.437149]  ? ieee80211_roc_setup+0x9e/0xd0 [mac80211]
      [  855.437183]  ? __kmalloc+0x1af/0x1f0
      [  855.437207]  ? rt2x00usb_probe+0x13d/0xc50 [rt2x00usb]
      [  855.437240]  rt2x00usb_probe+0x155/0xc50 [rt2x00usb]
      [  855.437273]  rt2800usb_probe+0x15/0x20 [rt2800usb]
      [  855.437304]  usb_probe_interface+0x159/0x2d0
      [  855.437333]  driver_probe_device+0x2bb/0x460
      
      Patch changes initialization sequence to fix the problem.
      
      Cc: Vishal Thanki <vishalthanki@gmail.com>
      Fixes: 8b4c0009 ("rt2x00usb: Use usb anchor to manage URB")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Cc: Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb794d57
    • Noralf Trønnes's avatar
      i2c: bcm2835: Fix hang for writing messages larger than 16 bytes · 938f8e85
      Noralf Trønnes authored
      commit e2474541 upstream.
      
      Writing messages larger than the FIFO size results in a hang, rendering
      the machine unusable. This is because the RXD status flag is set on the
      first interrupt which results in bcm2835_drain_rxfifo() stealing bytes
      from the buffer. The controller continues to trigger interrupts waiting
      for the missing bytes, but bcm2835_fill_txfifo() has none to give.
      In this situation wait_for_completion_timeout() apparently is unable to
      stop the madness.
      
      The BCM2835 ARM Peripherals datasheet has this to say about the flags:
        TXD: is set when the FIFO has space for at least one byte of data.
        RXD: is set when the FIFO contains at least one byte of data.
        TXW: is set during a write transfer and the FIFO is less than full.
        RXR: is set during a read transfer and the FIFO is or more full.
      
      Implementing the logic from the downstream i2c-bcm2708 driver solved
      the hang problem.
      Signed-off-by: default avatarNoralf Trønnes <noralf@tronnes.org>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarMartin Sperl <kernel@martin.sperl.org>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      938f8e85
    • Mike Marshall's avatar
      orangefs: fix buffer size mis-match between kernel space and user space. · f7513c91
      Mike Marshall authored
      commit eb68d032 upstream.
      
      The deamon through which the kernel module communicates with the userspace
      part of Orangefs, the "client-core", sends initialization data to the
      kernel module with ioctl. The initialization data was built by the
      client-core in a 2k buffer and copy_from_user'd into a 1k buffer
      in the kernel module. When more than 1k of initialization data needed
      to be sent, some was lost, reducing the usability of the control by which
      debug levels are set. This patch sets the kernel side buffer to 2K to
      match the userspace side...
      Signed-off-by: default avatarMike Marshall <hubcap@omnibond.com>
      Signed-off-by: default avatarMartin Brandenburg <martin@omnibond.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7513c91
    • Mike Marshall's avatar
      orangefs: Dan Carpenter influenced cleanups... · 1b992186
      Mike Marshall authored
      commit 05973c2e upstream.
      
      This patch is simlar to one Dan Carpenter sent me, cleans
      up some return codes and whitespace errors. There was one
      place where he thought inserting an error message into
      the ring buffer might be too chatty, I hope I convinced him
      othewise. As a consolation <g> I changed a truly chatty
      error message in another location into a debug message,
      system-admins had already yelled at me about that one...
      Signed-off-by: default avatarMike Marshall <hubcap@omnibond.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b992186
    • Colin Ian King's avatar
      orangefs: fix memory leak of string 'new' on exit path · dcac0d18
      Colin Ian King authored
      commit 4defb5f9 upstream.
      
      allocates string 'new' is not free'd on the exit path when
      cdm_element_count <= 0. Fix this by kfree'ing it.
      
      Fixes CoverityScan CID#1375923 "Resource Leak"
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarMike Marshall <hubcap@omnibond.com>
      Signed-off-by: default avatarMartin Brandenburg <martin@omnibond.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dcac0d18
    • Chris Wilson's avatar
      drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker) · 17fda94d
      Chris Wilson authored
      commit 3d3d18f0 upstream.
      
      The rcu_barrier() takes the cpu_hotplug mutex which itself is not
      reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker.
      
      [  309.661373] =========================================================
      [  309.661376] [ INFO: possible irq lock inversion dependency detected ]
      [  309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ #1 Tainted: G        W
      [  309.661383] ---------------------------------------------------------
      [  309.661386] gem_exec_gttfil/6435 just changed the state of lock:
      [  309.661389]  (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [<ffffffff81100731>] _rcu_barrier+0x31/0x160
      [  309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past:
      [  309.661402]  (cpu_hotplug.lock){+.+.+.}
      [  309.661404]
      
                     and interrupts could create inverse lock ordering between them.
      
      [  309.661410]
                     other info that might help us debug this:
      [  309.661414]  Possible interrupt unsafe locking scenario:
      
      [  309.661417]        CPU0                    CPU1
      [  309.661419]        ----                    ----
      [  309.661421]   lock(cpu_hotplug.lock);
      [  309.661425]                                local_irq_disable();
      [  309.661432]                                lock(rcu_preempt_state.barrier_mutex);
      [  309.661441]                                lock(cpu_hotplug.lock);
      [  309.661446]   <Interrupt>
      [  309.661448]     lock(rcu_preempt_state.barrier_mutex);
      [  309.661453]
                      *** DEADLOCK ***
      
      [  309.661460] 4 locks held by gem_exec_gttfil/6435:
      [  309.661464]  #0:  (sb_writers#10){.+.+.+}, at: [<ffffffff8120d83d>] vfs_write+0x17d/0x1f0
      [  309.661475]  #1:  (debugfs_srcu){......}, at: [<ffffffff81320491>] debugfs_use_file_start+0x41/0xa0
      [  309.661486]  #2:  (&attr->mutex){+.+.+.}, at: [<ffffffff8123a3e7>] simple_attr_write+0x37/0xe0
      [  309.661495]  #3:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0091b4a>] i915_drop_caches_set+0x3a/0x150 [i915]
      [  309.661540]
                     the shortest dependencies between 2nd lock and 1st lock:
      [  309.661547]  -> (cpu_hotplug.lock){+.+.+.} ops: 829 {
      [  309.661553]     HARDIRQ-ON-W at:
      [  309.661560]                       __lock_acquire+0x5e5/0x1b50
      [  309.661565]                       lock_acquire+0xc9/0x220
      [  309.661572]                       __mutex_lock+0x6e/0x990
      [  309.661576]                       mutex_lock_nested+0x16/0x20
      [  309.661583]                       get_online_cpus+0x61/0x80
      [  309.661590]                       kmem_cache_create+0x25/0x1d0
      [  309.661596]                       debug_objects_mem_init+0x30/0x249
      [  309.661602]                       start_kernel+0x341/0x3fe
      [  309.661607]                       x86_64_start_reservations+0x2a/0x2c
      [  309.661612]                       x86_64_start_kernel+0x173/0x186
      [  309.661619]                       verify_cpu+0x0/0xfc
      [  309.661622]     SOFTIRQ-ON-W at:
      [  309.661627]                       __lock_acquire+0x611/0x1b50
      [  309.661632]                       lock_acquire+0xc9/0x220
      [  309.661636]                       __mutex_lock+0x6e/0x990
      [  309.661641]                       mutex_lock_nested+0x16/0x20
      [  309.661646]                       get_online_cpus+0x61/0x80
      [  309.661650]                       kmem_cache_create+0x25/0x1d0
      [  309.661655]                       debug_objects_mem_init+0x30/0x249
      [  309.661660]                       start_kernel+0x341/0x3fe
      [  309.661664]                       x86_64_start_reservations+0x2a/0x2c
      [  309.661669]                       x86_64_start_kernel+0x173/0x186
      [  309.661674]                       verify_cpu+0x0/0xfc
      [  309.661677]     RECLAIM_FS-ON-W at:
      [  309.661682]                          mark_held_locks+0x6f/0xa0
      [  309.661687]                          lockdep_trace_alloc+0xb3/0x100
      [  309.661693]                          kmem_cache_alloc_trace+0x31/0x2e0
      [  309.661699]                          __smpboot_create_thread.part.1+0x27/0xe0
      [  309.661704]                          smpboot_create_threads+0x61/0x90
      [  309.661709]                          cpuhp_invoke_callback+0x9c/0x8a0
      [  309.661713]                          cpuhp_up_callbacks+0x31/0xb0
      [  309.661718]                          _cpu_up+0x7a/0xc0
      [  309.661723]                          do_cpu_up+0x5f/0x80
      [  309.661727]                          cpu_up+0xe/0x10
      [  309.661734]                          smp_init+0x71/0xb3
      [  309.661738]                          kernel_init_freeable+0x94/0x19e
      [  309.661743]                          kernel_init+0x9/0xf0
      [  309.661748]                          ret_from_fork+0x2e/0x40
      [  309.661752]     INITIAL USE at:
      [  309.661757]                      __lock_acquire+0x234/0x1b50
      [  309.661761]                      lock_acquire+0xc9/0x220
      [  309.661766]                      __mutex_lock+0x6e/0x990
      [  309.661771]                      mutex_lock_nested+0x16/0x20
      [  309.661775]                      get_online_cpus+0x61/0x80
      [  309.661780]                      __cpuhp_setup_state+0x44/0x170
      [  309.661785]                      page_alloc_init+0x23/0x3a
      [  309.661790]                      start_kernel+0x124/0x3fe
      [  309.661794]                      x86_64_start_reservations+0x2a/0x2c
      [  309.661799]                      x86_64_start_kernel+0x173/0x186
      [  309.661804]                      verify_cpu+0x0/0xfc
      [  309.661807]   }
      [  309.661813]   ... key      at: [<ffffffff81e37690>] cpu_hotplug+0xb0/0x100
      [  309.661817]   ... acquired at:
      [  309.661821]    lock_acquire+0xc9/0x220
      [  309.661825]    __mutex_lock+0x6e/0x990
      [  309.661829]    mutex_lock_nested+0x16/0x20
      [  309.661833]    get_online_cpus+0x61/0x80
      [  309.661837]    _rcu_barrier+0x9f/0x160
      [  309.661841]    rcu_barrier+0x10/0x20
      [  309.661847]    netdev_run_todo+0x5f/0x310
      [  309.661852]    rtnl_unlock+0x9/0x10
      [  309.661856]    default_device_exit_batch+0x133/0x150
      [  309.661862]    ops_exit_list.isra.0+0x4d/0x60
      [  309.661866]    cleanup_net+0x1d8/0x2c0
      [  309.661872]    process_one_work+0x1f4/0x6d0
      [  309.661876]    worker_thread+0x49/0x4a0
      [  309.661881]    kthread+0x107/0x140
      [  309.661884]    ret_from_fork+0x2e/0x40
      
      [  309.661890] -> (rcu_preempt_state.barrier_mutex){+.+.-.} ops: 179 {
      [  309.661896]    HARDIRQ-ON-W at:
      [  309.661901]                     __lock_acquire+0x5e5/0x1b50
      [  309.661905]                     lock_acquire+0xc9/0x220
      [  309.661910]                     __mutex_lock+0x6e/0x990
      [  309.661914]                     mutex_lock_nested+0x16/0x20
      [  309.661919]                     _rcu_barrier+0x31/0x160
      [  309.661923]                     rcu_barrier+0x10/0x20
      [  309.661928]                     netdev_run_todo+0x5f/0x310
      [  309.661932]                     rtnl_unlock+0x9/0x10
      [  309.661936]                     default_device_exit_batch+0x133/0x150
      [  309.661941]                     ops_exit_list.isra.0+0x4d/0x60
      [  309.661946]                     cleanup_net+0x1d8/0x2c0
      [  309.661951]                     process_one_work+0x1f4/0x6d0
      [  309.661955]                     worker_thread+0x49/0x4a0
      [  309.661960]                     kthread+0x107/0x140
      [  309.661964]                     ret_from_fork+0x2e/0x40
      [  309.661968]    SOFTIRQ-ON-W at:
      [  309.661972]                     __lock_acquire+0x611/0x1b50
      [  309.661977]                     lock_acquire+0xc9/0x220
      [  309.661981]                     __mutex_lock+0x6e/0x990
      [  309.661986]                     mutex_lock_nested+0x16/0x20
      [  309.661990]                     _rcu_barrier+0x31/0x160
      [  309.661995]                     rcu_barrier+0x10/0x20
      [  309.661999]                     netdev_run_todo+0x5f/0x310
      [  309.662003]                     rtnl_unlock+0x9/0x10
      [  309.662008]                     default_device_exit_batch+0x133/0x150
      [  309.662013]                     ops_exit_list.isra.0+0x4d/0x60
      [  309.662017]                     cleanup_net+0x1d8/0x2c0
      [  309.662022]                     process_one_work+0x1f4/0x6d0
      [  309.662027]                     worker_thread+0x49/0x4a0
      [  309.662031]                     kthread+0x107/0x140
      [  309.662035]                     ret_from_fork+0x2e/0x40
      [  309.662039]    IN-RECLAIM_FS-W at:
      [  309.662043]                        __lock_acquire+0x638/0x1b50
      [  309.662048]                        lock_acquire+0xc9/0x220
      [  309.662053]                        __mutex_lock+0x6e/0x990
      [  309.662058]                        mutex_lock_nested+0x16/0x20
      [  309.662062]                        _rcu_barrier+0x31/0x160
      [  309.662067]                        rcu_barrier+0x10/0x20
      [  309.662089]                        i915_gem_shrink_all+0x33/0x40 [i915]
      [  309.662109]                        i915_drop_caches_set+0x141/0x150 [i915]
      [  309.662114]                        simple_attr_write+0xc7/0xe0
      [  309.662119]                        full_proxy_write+0x4f/0x70
      [  309.662124]                        __vfs_write+0x23/0x120
      [  309.662128]                        vfs_write+0xc6/0x1f0
      [  309.662133]                        SyS_write+0x44/0xb0
      [  309.662138]                        entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  309.662142]    INITIAL USE at:
      [  309.662147]                    __lock_acquire+0x234/0x1b50
      [  309.662151]                    lock_acquire+0xc9/0x220
      [  309.662156]                    __mutex_lock+0x6e/0x990
      [  309.662160]                    mutex_lock_nested+0x16/0x20
      [  309.662165]                    _rcu_barrier+0x31/0x160
      [  309.662169]                    rcu_barrier+0x10/0x20
      [  309.662174]                    netdev_run_todo+0x5f/0x310
      [  309.662178]                    rtnl_unlock+0x9/0x10
      [  309.662183]                    default_device_exit_batch+0x133/0x150
      [  309.662188]                    ops_exit_list.isra.0+0x4d/0x60
      [  309.662192]                    cleanup_net+0x1d8/0x2c0
      [  309.662197]                    process_one_work+0x1f4/0x6d0
      [  309.662202]                    worker_thread+0x49/0x4a0
      [  309.662206]                    kthread+0x107/0x140
      [  309.662210]                    ret_from_fork+0x2e/0x40
      [  309.662214]  }
      [  309.662220]  ... key      at: [<ffffffff81e4e1c8>] rcu_preempt_state+0x508/0x780
      [  309.662225]  ... acquired at:
      [  309.662229]    check_usage_forwards+0x12b/0x130
      [  309.662233]    mark_lock+0x360/0x6f0
      [  309.662237]    __lock_acquire+0x638/0x1b50
      [  309.662241]    lock_acquire+0xc9/0x220
      [  309.662245]    __mutex_lock+0x6e/0x990
      [  309.662249]    mutex_lock_nested+0x16/0x20
      [  309.662253]    _rcu_barrier+0x31/0x160
      [  309.662257]    rcu_barrier+0x10/0x20
      [  309.662279]    i915_gem_shrink_all+0x33/0x40 [i915]
      [  309.662298]    i915_drop_caches_set+0x141/0x150 [i915]
      [  309.662303]    simple_attr_write+0xc7/0xe0
      [  309.662307]    full_proxy_write+0x4f/0x70
      [  309.662311]    __vfs_write+0x23/0x120
      [  309.662315]    vfs_write+0xc6/0x1f0
      [  309.662319]    SyS_write+0x44/0xb0
      [  309.662323]    entry_SYSCALL_64_fastpath+0x1c/0xb1
      
      [  309.662329]
                     stack backtrace:
      [  309.662335] CPU: 1 PID: 6435 Comm: gem_exec_gttfil Tainted: G        W       4.11.0-rc1-CI-CI_DRM_2333+ #1
      [  309.662342] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
      [  309.662348] Call Trace:
      [  309.662354]  dump_stack+0x67/0x92
      [  309.662359]  print_irq_inversion_bug.part.19+0x1a4/0x1b0
      [  309.662365]  check_usage_forwards+0x12b/0x130
      [  309.662369]  mark_lock+0x360/0x6f0
      [  309.662374]  ? print_shortest_lock_dependencies+0x1a0/0x1a0
      [  309.662379]  __lock_acquire+0x638/0x1b50
      [  309.662383]  ? __mutex_unlock_slowpath+0x3e/0x2e0
      [  309.662388]  ? trace_hardirqs_on+0xd/0x10
      [  309.662392]  ? _rcu_barrier+0x31/0x160
      [  309.662396]  lock_acquire+0xc9/0x220
      [  309.662400]  ? _rcu_barrier+0x31/0x160
      [  309.662404]  ? _rcu_barrier+0x31/0x160
      [  309.662409]  __mutex_lock+0x6e/0x990
      [  309.662412]  ? _rcu_barrier+0x31/0x160
      [  309.662416]  ? _rcu_barrier+0x31/0x160
      [  309.662421]  ? synchronize_rcu_expedited+0x35/0xb0
      [  309.662426]  ? _raw_spin_unlock_irqrestore+0x52/0x60
      [  309.662434]  mutex_lock_nested+0x16/0x20
      [  309.662438]  _rcu_barrier+0x31/0x160
      [  309.662442]  rcu_barrier+0x10/0x20
      [  309.662464]  i915_gem_shrink_all+0x33/0x40 [i915]
      [  309.662484]  i915_drop_caches_set+0x141/0x150 [i915]
      [  309.662489]  simple_attr_write+0xc7/0xe0
      [  309.662494]  full_proxy_write+0x4f/0x70
      [  309.662498]  __vfs_write+0x23/0x120
      [  309.662503]  ? rcu_read_lock_sched_held+0x75/0x80
      [  309.662507]  ? rcu_sync_lockdep_assert+0x2a/0x50
      [  309.662512]  ? __sb_start_write+0x102/0x210
      [  309.662516]  ? vfs_write+0x17d/0x1f0
      [  309.662520]  vfs_write+0xc6/0x1f0
      [  309.662524]  ? trace_hardirqs_on_caller+0xe7/0x200
      [  309.662529]  SyS_write+0x44/0xb0
      [  309.662533]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  309.662537] RIP: 0033:0x7f507eac24a0
      [  309.662541] RSP: 002b:00007fffda8720e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [  309.662548] RAX: ffffffffffffffda RBX: ffffffff81482bd3 RCX: 00007f507eac24a0
      [  309.662552] RDX: 0000000000000005 RSI: 00007fffda8720f0 RDI: 0000000000000005
      [  309.662557] RBP: ffffc9000048bf88 R08: 0000000000000000 R09: 000000000000002c
      [  309.662561] R10: 0000000000000014 R11: 0000000000000246 R12: 00007fffda872230
      [  309.662566] R13: 00007fffda872228 R14: 0000000000000201 R15: 00007fffda8720f0
      [  309.662572]  ? __this_cpu_preempt_check+0x13/0x20
      
      Fixes: 0eafec6d ("drm/i915: Enable lockless lookup of request tracking via RCU")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100192Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170314115019.18127-1-chris@chris-wilson.co.ukReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      (cherry picked from commit bd784b7c)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170321144531.12344-1-chris@chris-wilson.co.ukSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17fda94d
    • Chris Wilson's avatar
      drm/i915: Stop using RP_DOWN_EI on Baytrail · 82dafcb9
      Chris Wilson authored
      commit 8f68d591 upstream.
      
      On Baytrail, we manually calculate busyness over the evaluation interval
      to avoid issues with miscaluations with RC6 enabled. However, it turns
      out that the DOWN_EI interrupt generator is completely bust - it
      operates in two modes, continuous or never. Neither of which are
      conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
      compute everything from the UP_EI which does seem to correspond to the
      desired interval.
      
      v2: Fixup gen6_rps_pm_mask() as well
      v3: Inline vlv_c0_above() to combine the now identical elapsed
      calculation for up/down and simplify the threshold testing
      
      Fixes: 43cf3bf0 ("drm/i915: Improved w/a for rps on Baytrail")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.ukReviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170313170617.31564-1-chris@chris-wilson.co.uk
      (cherry picked from commit e0e8c7cb)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82dafcb9
    • Kenneth Graunke's avatar
      drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. · 954ce087
      Kenneth Graunke authored
      commit 0f5418e5 upstream.
      
      This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
      (indicating the optional feature is not supported), and makes execbuf
      always return -EINVAL if the flags are used.
      
      Apparently, no userspace ever shipped which used this optional feature:
      I checked the git history of Mesa, xf86-video-intel, libva, and Beignet,
      and there were zero commits showing a use of these flags.  Kernel commit
      72bfa19c apparently introduced the feature prematurely.  According
      to Chris, the intention was to use this in cairo-drm, but "the use was
      broken for gen6", so I don't think it ever happened.
      
      'relative_constants_mode' has always been tracked per-device, but this
      has actually been wrong ever since hardware contexts were introduced, as
      the INSTPM register is saved (and automatically restored) as part of the
      render ring context. The software per-device value could therefore get
      out of sync with the hardware per-context value.  This meant that using
      them is actually unsafe: a client which tried to use them could damage
      the state of other clients, causing the GPU to interpret their BO
      offsets as absolute pointers, leading to bogus memory reads.
      
      These flags were also never ported to execlist mode, making them no-ops
      on Gen9+ (which requires execlists), and Gen8 in the default mode.
      
      On Gen8+, userspace can write these registers directly, achieving the
      same effect.  On Gen6-7.5, it likely makes sense to extend the command
      parser to support them.  I don't think anyone wants this on Gen4-5.
      
      Based on a patch by Dave Gordon.
      
      v3: Return -ENODEV for the getparam, as this is what we do for other
          obsolete features.  Suggested by Chris Wilson.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448Signed-off-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.orgAcked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170313170433.26843-1-chris@chris-wilson.co.uk
      (cherry picked from commit ef0f411f)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      954ce087
    • Chris Wilson's avatar
      drm/i915: Only enable hotplug interrupts if the display interrupts are enabled · 1cbf6296
      Chris Wilson authored
      commit 35a3abfd upstream.
      
      In order to prevent accessing the hpd registers outside of the display
      power wells, we should refrain from writing to the registers before the
      display interrupts are enabled.
      
      [    4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915]
      [    4.740155] Unclaimed read from register 0x1e1110
      [    4.740168] Modules linked in: i915(+) intel_gtt drm_kms_helper prime_numbers
      [    4.740190] CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 4.10.0-rc6+ #384
      [    4.740203] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
      [    4.740220] Call Trace:
      [    4.740236]  dump_stack+0x4d/0x6f
      [    4.740251]  __warn+0xc1/0xe0
      [    4.740265]  warn_slowpath_fmt+0x4a/0x50
      [    4.740281]  ? insert_work+0x77/0xc0
      [    4.740355]  ? fwtable_write32+0x90/0x130 [i915]
      [    4.740431]  __unclaimed_reg_debug+0x44/0x50 [i915]
      [    4.740507]  fwtable_read32+0xd8/0x130 [i915]
      [    4.740575]  i915_hpd_irq_setup+0xa5/0x100 [i915]
      [    4.740649]  intel_hpd_init+0x68/0x80 [i915]
      [    4.740716]  i915_driver_load+0xe19/0x1380 [i915]
      [    4.740784]  i915_pci_probe+0x32/0x90 [i915]
      [    4.740799]  pci_device_probe+0x8b/0xf0
      [    4.740815]  driver_probe_device+0x2b6/0x450
      [    4.740828]  __driver_attach+0xda/0xe0
      [    4.740841]  ? driver_probe_device+0x450/0x450
      [    4.740853]  bus_for_each_dev+0x5b/0x90
      [    4.740865]  driver_attach+0x19/0x20
      [    4.740878]  bus_add_driver+0x166/0x260
      [    4.740892]  driver_register+0x5b/0xd0
      [    4.740906]  ? 0xffffffffa0166000
      [    4.740920]  __pci_register_driver+0x47/0x50
      [    4.740985]  i915_init+0x5c/0x5e [i915]
      [    4.740999]  do_one_initcall+0x3e/0x160
      [    4.741015]  ? __vunmap+0x7c/0xc0
      [    4.741029]  ? kmem_cache_alloc+0xcf/0x120
      [    4.741045]  do_init_module+0x55/0x1c4
      [    4.741060]  load_module+0x1f3f/0x25b0
      [    4.741073]  ? __symbol_put+0x40/0x40
      [    4.741086]  ? kernel_read_file+0x100/0x190
      [    4.741100]  SYSC_finit_module+0xbc/0xf0
      [    4.741112]  SyS_finit_module+0x9/0x10
      [    4.741125]  entry_SYSCALL_64_fastpath+0x17/0x98
      [    4.741135] RIP: 0033:0x7f8559a140f9
      [    4.741145] RSP: 002b:00007fff7509a3e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [    4.741161] RAX: ffffffffffffffda RBX: 00007f855aba02d1 RCX: 00007f8559a140f9
      [    4.741172] RDX: 0000000000000000 RSI: 000055b6db0914f0 RDI: 0000000000000011
      [    4.741183] RBP: 0000000000020000 R08: 0000000000000000 R09: 000000000000000e
      [    4.741193] R10: 0000000000000011 R11: 0000000000000246 R12: 000055b6db0854d0
      [    4.741204] R13: 000055b6db091150 R14: 0000000000000000 R15: 000055b6db035924
      
      v2: Set dev_priv->display_irqs_enabled to true for all platforms other
      than vlv/chv that manually control the display power domain.
      
      Fixes: 19625e85 ("drm/i915: Enable polling when we don't have hpd")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97798Suggested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lyude <cpaul@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Hans de Goede <jwrdegoede@fedoraproject.org>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170215131547.5064-1-chris@chris-wilson.co.uk
      Link: http://patchwork.freedesktop.org/patch/msgid/20170313170231.18633-1-chris@chris-wilson.co.uk
      (cherry picked from commit 262fd485)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cbf6296
    • Mika Kuoppala's avatar
      drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3 · 1435e12e
      Mika Kuoppala authored
      commit 34dc8993 upstream.
      
      Certain Baytrails, namely the 4 cpu core variants, have been
      plaqued by spurious system hangs, mostly occurring with light loads.
      
      Multiple bisects by various people point to a commit which changes the
      reclocking strategy for Baytrail to follow its bigger brethen:
      commit 8fb55197 ("drm/i915: Agressive downclocking on Baytrail")
      
      There is also a review comment attached to this commit from Deepak S
      on avoiding punit access on Cherryview and thus it was excluded on
      common reclocking path. By taking the same approach and omitting
      the punit access by not tweaking the thresholds when the hardware
      has been asked to move into different frequency, considerable gains
      in stability have been observed.
      
      With J1900 box, light render/video load would end up in system hang
      in usually less than 12 hours. With this patch applied, the cumulative
      uptime has now been 34 days without issues. To provoke system hang,
      light loads on both render and bsd engines in parallel have been used:
      glxgears >/dev/null 2>/dev/null &
      mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4
      
      So far, author has not witnessed system hang with above load
      and this patch applied. Reports from the tenacious people at
      kernel bugzilla are also promising.
      
      Considering that the punit access frequency with this patch is
      considerably less, there is a possibility that this will push
      the, still unknown, root cause past the triggering point on most loads.
      
      But as we now can reliably reproduce the hang independently,
      we can reduce the pain that users are having and use a
      static thresholds until a root cause is found.
      
      v3: don't break debugfs and simplification (Chris Wilson)
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: fritsch@xbmc.org
      Cc: miku@iki.fi
      Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
      CC: Michal Feix <michal@feix.cz>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Deepak S <deepak.s@linux.intel.com>
      Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1487166779-26945-1-git-send-email-mika.kuoppala@intel.com
      (cherry picked from commit 6067a27d)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1435e12e
    • Ville Syrjälä's avatar
      drm/i915: Nuke debug messages from the pipe update critical section · 988028e5
      Ville Syrjälä authored
      commit edd06b83 upstream.
      
      printks are slow so we should not be doing them from the vblank evade
      critical section. These could explain why we sometimes seem to
      blow past our 100 usec deadline.
      
      The problem has been there ever since commit bfd16b2a ("drm/i915:
      Make updating pipe without modeset atomic.") but it may not have
      been readily visible until commit e1edbd44 ("drm/i915: Complain
      if we take too long under vblank evasion.") increased our chances
      of noticing it.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Fixes: bfd16b2a ("drm/i915: Make updating pipe without modeset atomic.")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170307205419.19447-1-ville.syrjala@linux.intel.comReviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      (cherry picked from commit c3f8ad57)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      988028e5
    • Imre Deak's avatar
      drm/i915/gen9: Increase PCODE request timeout to 50ms · 8ac9915c
      Imre Deak authored
      commit d253371c upstream.
      
      After
      commit 2c7d0602
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Mon Dec 5 18:27:37 2016 +0200
      
          drm/i915/gen9: Fix PCODE polling during CDCLK change notification
      
      there is still one report of the CDCLK-change request timing out on a
      KBL machine, see the Reference link. On that machine the maximum time
      the request took to succeed was 34ms, so increase the timeout to 50ms.
      
      v2:
      - Change timeout from 100 to 50 ms to maintain the current 50 ms limit
        for atomic waits in the driver. (Chris, Tvrtko)
      
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit 0129936d)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ac9915c
  2. 12 Apr, 2017 26 commits