1. 12 Oct, 2018 1 commit
  2. 05 Oct, 2018 12 commits
  3. 04 Oct, 2018 9 commits
    • Ido Schimmel's avatar
      team: Forbid enslaving team device to itself · 471b83bd
      Ido Schimmel authored
      team's ndo_add_slave() acquires 'team->lock' and later tries to open the
      newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event
      that causes the VLAN driver to add VLAN 0 on the team device. team's
      ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and
      deadlock.
      
      Fix this by checking early at the enslavement function that a team
      device is not being enslaved to itself.
      
      A similar check was added to the bond driver in commit 09a89c21
      ("bonding: disallow enslaving a bond to itself").
      
      WARNING: possible recursive locking detected
      4.18.0-rc7+ #176 Not tainted
      --------------------------------------------
      syz-executor4/6391 is trying to acquire lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
      
      but task is already holding lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&team->lock);
        lock(&team->lock);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      2 locks held by syz-executor4/6391:
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4662
       #1: (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      stack backtrace:
      CPU: 1 PID: 6391 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #176
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
       print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
       check_deadlock kernel/locking/lockdep.c:1809 [inline]
       validate_chain kernel/locking/lockdep.c:2405 [inline]
       __lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435
       lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
       __mutex_lock_common kernel/locking/mutex.c:757 [inline]
       __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894
       mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909
       team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
       vlan_add_rx_filter_info+0x14a/0x1d0 net/8021q/vlan_core.c:210
       __vlan_vid_add net/8021q/vlan_core.c:278 [inline]
       vlan_vid_add+0x63e/0x9d0 net/8021q/vlan_core.c:308
       vlan_device_event.cold.12+0x2a/0x2f net/8021q/vlan.c:381
       notifier_call_chain+0x180/0x390 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
       call_netdevice_notifiers net/core/dev.c:1753 [inline]
       dev_open+0x173/0x1b0 net/core/dev.c:1433
       team_port_add drivers/net/team/team.c:1219 [inline]
       team_add_slave+0xa8b/0x1c30 drivers/net/team/team.c:1948
       do_set_master+0x1c9/0x220 net/core/rtnetlink.c:2248
       do_setlink+0xba4/0x3e10 net/core/rtnetlink.c:2382
       rtnl_setlink+0x2a9/0x400 net/core/rtnetlink.c:2636
       rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
       netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2455
       rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1908
       sock_sendmsg_nosec net/socket.c:642 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:652
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
       __sys_sendmsg+0x11d/0x290 net/socket.c:2164
       __do_sys_sendmsg net/socket.c:2173 [inline]
       __se_sys_sendmsg net/socket.c:2171 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x456b29
      Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29
      RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
      RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000
      
      Fixes: 87002b03 ("net: introduce vlan_vid_[add/del] and use them instead of direct [add/kill]_vid ndo calls")
      Signed-off-by: default avatarIdo Schimmel <[email protected]>
      Reported-and-tested-by: [email protected]
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      471b83bd
    • Yu Zhao's avatar
      net/usb: cancel pending work when unbinding smsc75xx · f7b2a56e
      Yu Zhao authored
      Cancel pending work before freeing smsc75xx private data structure
      during binding. This fixes the following crash in the driver:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      IP: mutex_lock+0x2b/0x3f
      <snipped>
      Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx]
      task: ffff8caa83e85700 task.stack: ffff948b80518000
      RIP: 0010:mutex_lock+0x2b/0x3f
      <snipped>
      Call Trace:
       smsc75xx_deferred_multicast_write+0x40/0x1af [smsc75xx]
       process_one_work+0x18d/0x2fc
       worker_thread+0x1a2/0x269
       ? pr_cont_work+0x58/0x58
       kthread+0xfa/0x10a
       ? pr_cont_work+0x58/0x58
       ? rcu_read_unlock_sched_notrace+0x48/0x48
       ret_from_fork+0x22/0x40
      Signed-off-by: default avatarYu Zhao <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      f7b2a56e
    • Mike Snitzer's avatar
      dm cache: fix resize crash if user doesn't reload cache table · 5d07384a
      Mike Snitzer authored
      A reload of the cache's DM table is needed during resize because
      otherwise a crash will occur when attempting to access smq policy
      entries associated with the portion of the cache that was recently
      extended.
      
      The reason is cache-size based data structures in the policy will not be
      resized, the only way to safely extend the cache is to allow for a
      proper cache policy initialization that occurs when the cache table is
      loaded.  For example the smq policy's space_init(), init_allocator(),
      calc_hotspot_params() must be sized based on the extended cache size.
      
      The fix for this is to disallow cache resizes of this pattern:
      1) suspend "cache" target's device
      2) resize the fast device used for the cache
      3) resume "cache" target's device
      
      Instead, the last step must be a full reload of the cache's DM table.
      
      Fixes: 66a63635 ("dm cache: add stochastic-multi-queue (smq) policy")
      Cc: [email protected]
      Signed-off-by: default avatarMike Snitzer <[email protected]>
      5d07384a
    • Joe Thornber's avatar
      dm cache metadata: ignore hints array being too small during resize · 4561ffca
      Joe Thornber authored
      Commit fd2fa954 ("dm cache metadata: save in-core policy_hint_size to
      on-disk superblock") enabled previously written policy hints to be
      used after a cache is reactivated.  But in doing so the cache
      metadata's hint array was left exposed to out of bounds access because
      on resize the metadata's on-disk hint array wasn't ever extended.
      
      Fix this by ignoring that there are no on-disk hints associated with the
      newly added cache blocks.  An expanded on-disk hint array is later
      rewritten upon the next clean shutdown of the cache.
      
      Fixes: fd2fa954 ("dm cache metadata: save in-core policy_hint_size to on-disk superblock")
      Cc: [email protected]
      Signed-off-by: default avatarJoe Thornber <[email protected]>
      Signed-off-by: default avatarMike Snitzer <[email protected]>
      4561ffca
    • Rafael J. Wysocki's avatar
      PM / core: Clear the direct_complete flag on errors · 69e445ab
      Rafael J. Wysocki authored
      If __device_suspend() runs asynchronously (in which case the device
      passed to it is in dpm_suspended_list at that point) and it returns
      early on an error or pending wakeup, and the power.direct_complete
      flag has been set for the device already, the subsequent
      device_resume() will be confused by that and it will call
      pm_runtime_enable() incorrectly, as runtime PM has not been
      disabled for the device by __device_suspend().
      
      To avoid that, clear power.direct_complete if __device_suspend()
      is not going to disable runtime PM for the device before returning.
      
      Fixes: aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily)
      Reported-by: default avatarAl Cooper <[email protected]>
      Tested-by: default avatarAl Cooper <[email protected]>
      Reviewed-by: default avatarUlf Hansson <[email protected]>
      Cc: 3.16+ <[email protected]> # 3.16+
      Signed-off-by: default avatarRafael J. Wysocki <[email protected]>
      69e445ab
    • Ido Schimmel's avatar
      mlxsw: spectrum: Delete RIF when VLAN device is removed · c360867e
      Ido Schimmel authored
      In commit 602b74ed ("mlxsw: spectrum_switchdev: Do not leak RIFs
      when removing bridge") I handled the case where RIFs created for VLAN
      devices were not properly cleaned up when their real device (a bridge)
      was removed.
      
      However, I forgot to handle the case of the VLAN device itself being
      removed. Do so now when the VLAN device is being unlinked from its real
      device.
      
      Fixes: 99f44bb3 ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices")
      Signed-off-by: default avatarIdo Schimmel <[email protected]>
      Reviewed-by: default avatarJiri Pirko <[email protected]>
      Reported-by: default avatarArtem Shvorin <[email protected]>
      Tested-by: default avatarArtem Shvorin <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      c360867e
    • Nir Dotan's avatar
      mlxsw: pci: Derive event type from event queue number · f3c84a8e
      Nir Dotan authored
      Due to a hardware issue in Spectrum-2, the field event_type of the event
      queue element (EQE) has become reserved. It was used to distinguish between
      command interface completion events and completion events.
      
      Use queue number to determine event type, as command interface completion
      events are always received on EQ0 and mlxsw driver maps completion events
      to EQ1.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: default avatarNir Dotan <[email protected]>
      Reviewed-by: default avatarJiri Pirko <[email protected]>
      Signed-off-by: default avatarIdo Schimmel <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      f3c84a8e
    • Felix Kuehling's avatar
      drm/amdkfd: Fix incorrect use of process->mm · 11b29c9e
      Felix Kuehling authored
      This mm_struct pointer should never be dereferenced. If running in
      a user thread, just use current->mm. If running in a kernel worker
      use get_task_mm to get a safe reference to the mm_struct.
      Reviewed-by: default avatarOded Gabbay <[email protected]>
      Acked-by: default avatarChristian König <[email protected]>
      Signed-off-by: default avatarFelix Kuehling <[email protected]>
      Signed-off-by: default avatarAlex Deucher <[email protected]>
      11b29c9e
    • Shirish S's avatar
      drm/amd/display: Signal hw_done() after waiting for flip_done() · 987bf116
      Shirish S authored
      In amdgpu_dm_commit_tail(), wait until flip_done() is signaled before
      we signal hw_done().
      
      [Why]
      
      This is to temporarily address a paging error that occurs when a
      nonblocking commit contends with another commit, particularly in a
      mirrored display configuration where at least 2 CRTCs are updated.
      The error occurs in drm_atomic_helper_wait_for_flip_done(), when we
      attempt to access the contents of new_crtc_state->commit.
      
      Here's the sequence for a mirrored 2 display setup (irrelevant steps
      left out for clarity):
      
      **THREAD 1**                        | **THREAD 2**
                                          |
      Initialize atomic state for flip    |
                                          |
      Queue worker                        |
                                         ...
      
                                          | Do work for flip
                                          |
                                          | Signal hw_done() on CRTC 1
                                          | Signal hw_done() on CRTC 2
                                          |
                                          | Wait for flip_done() on CRTC 1
      
                                      <---- **PREEMPTED BY THREAD 1**
      
      Initialize atomic state for cursor  |
      update (1)                          |
                                          |
      Do cursor update work on both CRTCs |
                                          |
      Clear atomic state (2)              |
      **DONE**                            |
                                         ...
                                          |
                                          | Wait for flip_done() on CRTC 2
                                          | *ERROR*
                                          |
      
      The issue starts with (1). When the atomic state is initialized, the
      current CRTC states are duplicated to be the new_crtc_states, and
      referenced to be the old_crtc_states. (The new_crtc_states are to be
      filled with update data.)
      
      Some things to note:
      
      * Due to the mirrored configuration, the cursor updates on both CRTCs.
      
      * At this point, the pflip IRQ has already been handled, and flip_done
        signaled on all CRTCs. The cursor commit can therefore continue.
      
      * The old_crtc_states used by the cursor update are the **same states**
        as the new_crtc_states used by the flip worker.
      
      At (2), the old_crtc_state is freed (*), and the cursor commit
      completes. We then context switch back to the flip worker, where we
      attempt to access the new_crtc_state->commit object. This is
      problematic, as this state has already been freed.
      
      (*) Technically, 'state->crtcs[i].state' is freed, which was made to
          reference old_crtc_state in drm_atomic_helper_swap_state()
      
      [How]
      
      By moving hw_done() after wait_for_flip_done(), we're guaranteed that
      the new_crtc_state (from the flip worker's perspective) still exists.
      This is because any other commit will be blocked, waiting for the
      hw_done() signal.
      
      Note that both the i915 and imx drivers have this sequence flipped
      already, masking this problem.
      Signed-off-by: Shirish S's avatarShirish S <[email protected]>
      Signed-off-by: default avatarLeo Li <[email protected]>
      Reviewed-by: default avatarHarry Wentland <[email protected]>
      Signed-off-by: default avatarAlex Deucher <[email protected]>
      987bf116
  4. 03 Oct, 2018 8 commits
  5. 02 Oct, 2018 10 commits
    • Mahesh Bandewar's avatar
      bonding: fix warning message · 0f3b914c
      Mahesh Bandewar authored
      RX queue config for bonding master could be different from its slave
      device(s). With the commit 6a9e461f ("bonding: pass link-local
      packets to bonding master also."), the packet is reinjected into stack
      with skb->dev as bonding master. This potentially triggers the
      message:
      
         "bondX received packet on queue Y, but number of RX queues is Z"
      
      whenever the queue that packet is received on is higher than the
      numrxqueues on bonding master (Y > Z).
      
      Fixes: 6a9e461f ("bonding: pass link-local packets to bonding master also.")
      Reported-by: default avatarJohn Sperbeck <[email protected]>
      Signed-off-by: default avatarEric Dumazet <[email protected]>
      Signed-off-by: default avatarMahesh Bandewar <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      0f3b914c
    • Geert Uytterhoeven's avatar
      Revert "serial: sh-sci: Allow for compressed SCIF address" · 5b162cc4
      Geert Uytterhoeven authored
      This reverts commit 2d4dd0da.
      
      This broke earlycon on all Renesas ARM platforms using a SCIF port for the
      serial console (R-Car, RZ/A1, RZ/G1, RZ/G2 SoCs), due to an incorrect value
      of port->regshift.
      Signed-off-by: default avatarGeert Uytterhoeven <[email protected]>
      Acked-by: default avatarChris Brandt <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      5b162cc4
    • Geert Uytterhoeven's avatar
    • Guenter Roeck's avatar
      Revert "serial: 8250_dw: Fix runtime PM handling" · beeeac43
      Guenter Roeck authored
      This reverts commit d76c7438.
      
      While commit d76c7438 ("serial: 8250_dw: Fix runtime PM handling")
      fixes runtime PM handling when using kgdb, it introduces a traceback for
      everyone else.
      
      BUG: sleeping function called from invalid context at
      	/mnt/host/source/src/third_party/kernel/next/drivers/base/power/runtime.c:1034
      in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: swapper/0
      7 locks held by swapper/0/1:
       #0: 000000005ec5bc72 (&dev->mutex){....}, at: __driver_attach+0xb5/0x12b
       #1: 000000005d5fa9e5 (&dev->mutex){....}, at: __device_attach+0x3e/0x15b
       #2: 0000000047e93286 (serial_mutex){+.+.}, at: serial8250_register_8250_port+0x51/0x8bb
       #3: 000000003b328f07 (port_mutex){+.+.}, at: uart_add_one_port+0xab/0x8b0
       #4: 00000000fa313d4d (&port->mutex){+.+.}, at: uart_add_one_port+0xcc/0x8b0
       #5: 00000000090983ca (console_lock){+.+.}, at: vprintk_emit+0xdb/0x217
       #6: 00000000c743e583 (console_owner){-...}, at: console_unlock+0x211/0x60f
      irq event stamp: 735222
      __down_trylock_console_sem+0x4a/0x84
      console_unlock+0x338/0x60f
      __do_softirq+0x4a4/0x50d
      irq_exit+0x64/0xe2
      CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc5 #6
      Hardware name: Google Caroline/Caroline, BIOS Google_Caroline.7820.286.0 03/15/2017
      Call Trace:
       dump_stack+0x7d/0xbd
       ___might_sleep+0x238/0x259
       __pm_runtime_resume+0x4e/0xa4
       ? serial8250_rpm_get+0x2e/0x44
       serial8250_console_write+0x44/0x301
       ? lock_acquire+0x1b8/0x1fa
       console_unlock+0x577/0x60f
       vprintk_emit+0x1f0/0x217
       printk+0x52/0x6e
       register_console+0x43b/0x524
       uart_add_one_port+0x672/0x8b0
       ? set_io_from_upio+0x150/0x162
       serial8250_register_8250_port+0x825/0x8bb
       dw8250_probe+0x80c/0x8b0
       ? dw8250_serial_inq+0x8e/0x8e
       ? dw8250_check_lcr+0x108/0x108
       ? dw8250_runtime_resume+0x5b/0x5b
       ? dw8250_serial_outq+0xa1/0xa1
       ? dw8250_remove+0x115/0x115
       platform_drv_probe+0x76/0xc5
       really_probe+0x1f1/0x3ee
       ? driver_allows_async_probing+0x5d/0x5d
       driver_probe_device+0xd6/0x112
       ? driver_allows_async_probing+0x5d/0x5d
       bus_for_each_drv+0xbe/0xe5
       __device_attach+0xdd/0x15b
       bus_probe_device+0x5a/0x10b
       device_add+0x501/0x894
       ? _raw_write_unlock+0x27/0x3a
       platform_device_add+0x224/0x2b7
       mfd_add_device+0x718/0x75b
       ? __kmalloc+0x144/0x16a
       ? mfd_add_devices+0x38/0xdb
       mfd_add_devices+0x9b/0xdb
       intel_lpss_probe+0x7d4/0x8ee
       intel_lpss_pci_probe+0xac/0xd4
       pci_device_probe+0x101/0x18e
      ...
      
      Revert the offending patch until a more comprehensive solution
      is available.
      
      Cc: Tony Lindgren <[email protected]>
      Cc: Andy Shevchenko <[email protected]>
      Cc: Phil Edworthy <[email protected]>
      Fixes: d76c7438 ("serial: 8250_dw: Fix runtime PM handling")
      Signed-off-by: default avatarGuenter Roeck <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      beeeac43
    • Jakub Kicinski's avatar
      nfp: avoid soft lockups under control message storm · ff58e2df
      Jakub Kicinski authored
      When FW floods the driver with control messages try to exit the cmsg
      processing loop every now and then to avoid soft lockups.  Cmsg
      processing is generally very lightweight so 512 seems like a reasonable
      budget, which should not be exceeded under normal conditions.
      
      Fixes: 77ece8d5 ("nfp: add control vNIC datapath")
      Signed-off-by: default avatarJakub Kicinski <[email protected]>
      Reviewed-by: default avatarSimon Horman <[email protected]>
      Tested-by: default avatarPieter Jansen van Vuuren <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      ff58e2df
    • Maciej W. Rozycki's avatar
      declance: Fix continuation with the adapter identification message · fe3a83af
      Maciej W. Rozycki authored
      Fix a commit 4bcc595c ("printk: reinstate KERN_CONT for printing
      continuation lines") regression with the `declance' driver, which caused
      the adapter identification message to be split between two lines, e.g.:
      
      declance.c: v0.011 by Linux MIPS DECstation task force
      tc6: PMAD-AA
      , addr = 08:00:2b:1b:2a:6a, irq = 14
      tc6: registered as eth0.
      
      Address that properly, by printing identification with a single call,
      making the messages now look like:
      
      declance.c: v0.011 by Linux MIPS DECstation task force
      tc6: PMAD-AA, addr = 08:00:2b:1b:2a:6a, irq = 14
      tc6: registered as eth0.
      Signed-off-by: default avatarMaciej W. Rozycki <[email protected]>
      Fixes: 4bcc595c ("printk: reinstate KERN_CONT for printing continuation lines")
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      fe3a83af
    • Rickard x Andersson's avatar
      net: fec: fix rare tx timeout · 657ade07
      Rickard x Andersson authored
      During certain heavy network loads TX could time out
      with TX ring dump.
      TX is sometimes never restarted after reaching
      "tx_stop_threshold" because function "fec_enet_tx_queue"
      only tests the first queue.
      
      In addition the TX timeout callback function failed to
      recover because it also operated only on the first queue.
      Signed-off-by: default avatarRickard x Andersson <[email protected]>
      Signed-off-by: default avatarDavid S. Miller <[email protected]>
      657ade07
    • Mika Westerberg's avatar
      thunderbolt: Initialize after IOMMUs · eafa717b
      Mika Westerberg authored
      If IOMMU is enabled and Thunderbolt driver is built into the kernel
      image, it will be probed before IOMMUs are attached to the PCI bus.
      Because of this DMA mappings the driver does will not go through IOMMU
      and start failing right after IOMMUs are enabled.
      
      For this reason move the Thunderbolt driver initialization happen at
      rootfs level.
      Signed-off-by: default avatarMika Westerberg <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      eafa717b
    • Mika Westerberg's avatar
      thunderbolt: Do not handle ICM events after domain is stopped · 86da809d
      Mika Westerberg authored
      If there is a long chain of devices connected when the driver is loaded
      ICM sends device connected event for each and those are put to tb->wq
      for later processing. Now if the driver gets unloaded in the middle, so
      that the work queue is not yet empty it gets flushed by tb_domain_stop().
      However, by that time the root switch is already removed so the driver
      crashes when it tries to dereference it in ICM event handling callbacks.
      
      Fix this by checking whether the root switch is already removed. If it
      is we know that the domain is stopped and we should merely skip handling
      the event.
      Signed-off-by: default avatarMika Westerberg <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      86da809d
    • Noralf Trønnes's avatar
      drm/cma-helper: Fix crash in fbdev error path · 4d4c2d89
      Noralf Trønnes authored
      Sergey Suloev reported a crash happening in drm_client_dev_hotplug()
      when fbdev had failed to register.
      
      [    9.124598] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs directory
      [    9.147667] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
      [    9.155184] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name!
      [    9.166544] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
      [    9.173840] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
      [    9.181029] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
      [    9.188519] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
      [    9.195690] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
      [    9.203523] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
      [    9.215032] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
      [    9.274785] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
      [    9.290246] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
      [    9.297464] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
      [    9.304600] [drm] Driver supports precise vblank timestamp query.
      [    9.382856] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup [drm_kms_helper]] *ERROR* Failed to set fbdev configuration
      [   10.404937] Unable to handle kernel paging request at virtual address 00330a656369768a
      [   10.441620] [00330a656369768a] address between user and kernel address ranges
      [   10.449087] Internal error: Oops: 96000004 [#1] PREEMPT SMP
      [   10.454762] Modules linked in: brcmfmac vc4 drm_kms_helper cfg80211 drm rfkill smsc95xx brcmutil usbnet drm_panel_orientation_quirks raspberrypi_hwmon bcm2835_dma crc32_ce pwm_bcm2835 bcm2835_rng virt_dma rng_core i2c_bcm2835 ip_tables x_tables ipv6
      [   10.477296] CPU: 2 PID: 45 Comm: kworker/2:1 Not tainted 4.19.0-rc5 #3
      [   10.483934] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
      [   10.489966] Workqueue: events output_poll_execute [drm_kms_helper]
      [   10.596515] Process kworker/2:1 (pid: 45, stack limit = 0x000000007e8924dc)
      [   10.603590] Call trace:
      [   10.606259]  drm_client_dev_hotplug+0x5c/0xb0 [drm]
      [   10.611303]  drm_kms_helper_hotplug_event+0x30/0x40 [drm_kms_helper]
      [   10.617849]  output_poll_execute+0xc4/0x1e0 [drm_kms_helper]
      [   10.623616]  process_one_work+0x1c8/0x318
      [   10.627695]  worker_thread+0x48/0x428
      [   10.631420]  kthread+0xf8/0x128
      [   10.634615]  ret_from_fork+0x10/0x18
      [   10.638255] Code: 54000220 f9401261 aa1303e0 b4000141 (f9400c21)
      [   10.644456] ---[ end trace c75b4a4b0e141908 ]---
      
      The reason for this is that drm_fbdev_cma_init() removes the drm_client
      when fbdev registration fails, but it doesn't remove the client from the
      drm_device client list. So the client list now has a pointer that points
      into the unknown and we have a 'use after free' situation.
      
      Split drm_client_new() into drm_client_init() and drm_client_add() to fix
      removal in the error path.
      
      Fixes: 894a677f ("drm/cma-helper: Use the generic fbdev emulation")
      Reported-by: Sergey Suloev's avatarSergey Suloev <[email protected]>
      Cc: Stefan Wahren <[email protected]>
      Cc: Eric Anholt <[email protected]>
      Cc: Daniel Vetter <[email protected]>
      Signed-off-by: default avatarNoralf Trønnes <[email protected]>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <danie[email protected]>
      Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
      4d4c2d89