1. 11 Jun, 2019 20 commits
    • Hante Meuleman's avatar
      brcmfmac: Add length checks on firmware events · 6da841e9
      Hante Meuleman authored
      commit 0aedbcaf
      
       upstream.
      
      Add additional length checks on firmware events to create more
      robust code.
      Reviewed-by: default avatarArend Van Spriel <arend@broadcom.com>
      Reviewed-by: default avatarFranky (Zhenhui) Lin <frankyl@broadcom.com>
      Reviewed-by: default avatarPieter-Paul Giesberts <pieterpg@broadcom.com>
      Reviewed-by: default avatarLei Zhang <leizh@broadcom.com>
      Signed-off-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      [bwh: Backported to 4.4:
       - Drop changes to brcmf_wowl_nd_results()
       - Adjust filenames]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6da841e9
    • Daniel Axtens's avatar
      bnx2x: disable GSO where gso_size is too big for hardware · c55a2cff
      Daniel Axtens authored
      commit 8914a595
      
       upstream.
      
      If a bnx2x card is passed a GSO packet with a gso_size larger than
      ~9700 bytes, it will cause a firmware error that will bring the card
      down:
      
      bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert!
      bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2
      bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052
      bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1
      ... (dump of values continues) ...
      
      Detect when the mac length of a GSO packet is greater than the maximum
      packet size (9700 bytes) and disable GSO.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c55a2cff
    • Antoine Tenart's avatar
      net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value · 61ba8e9f
      Antoine Tenart authored
      [ Upstream commit 21808437214637952b61beaba6034d97880fbeb3 ]
      
      MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but
      the current code is passing the global tx queue offset, so it ends
      up writing to unknown registers (between 0x8280 and 0x82fc, which
      seemed to be unused by the hardware). This fixes the issue by using
      the logical queue id instead.
      
      Fixes: 3f518509
      
       ("ethernet: Add new driver for Marvell Armada 375 network unit")
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61ba8e9f
    • Michael Chan's avatar
      bnxt_en: Fix aggregation buffer leak under OOM condition. · 1d33a3eb
      Michael Chan authored
      [ Upstream commit 296d5b54163964b7ae536b8b57dfbd21d4e868e1 ]
      
      For every RX packet, the driver replenishes all buffers used for that
      packet and puts them back into the RX ring and RX aggregation ring.
      In one code path where the RX packet has one RX buffer and one or more
      aggregation buffers, we missed recycling the aggregation buffer(s) if
      we are unable to allocate a new SKB buffer.  This leads to the
      aggregation ring slowly running out of buffers over time.  Fix it
      by properly recycling the aggregation buffers.
      
      Fixes: c0c050c5
      
       ("bnxt_en: New Broadcom ethernet driver.")
      Reported-by: default avatarRakesh Hemnani <rhemnani@fb.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d33a3eb
    • Kloetzke Jan's avatar
      usbnet: fix kernel crash after disconnect · 332bff9d
      Kloetzke Jan authored
      
      
      [ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
      
      When disconnecting cdc_ncm the kernel sporadically crashes shortly
      after the disconnect:
      
        [   57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000
        ...
        [   58.006653] PC is at 0x0
        [   58.009202] LR is at call_timer_fn+0xec/0x1b4
        [   58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145
        [   58.020976] sp : ffffff8008003da0
        [   58.024295] x29: ffffff8008003da0 x28: 0000000000000001
        [   58.029618] x27: 000000000000000a x26: 0000000000000100
        [   58.034941] x25: 0000000000000000 x24: ffffff8008003e68
        [   58.040263] x23: 0000000000000000 x22: 0000000000000000
        [   58.045587] x21: 0000000000000000 x20: ffffffc68fac1808
        [   58.050910] x19: 0000000000000100 x18: 0000000000000000
        [   58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10
        [   58.061556] x15: 0000000000000001 x14: 000000000000006e
        [   58.066878] x13: 0000000000000000 x12: 00000000000000ba
        [   58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020
        [   58.077524] x9 : 8000100008001000 x8 : 0000000000000001
        [   58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70
        [   58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b
        [   58.093492] x3 : 0000000000000000 x2 : 0000000000000000
        [   58.098814] x1 : 0000000000000000 x0 : 0000000000000000
        ...
        [   58.205800] [<          (null)>]           (null)
        [   58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c
        [   58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128
        [   58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348
        [   58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc
        [   58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac
        [   58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac
        ...
      
      The crash happens roughly 125..130ms after the disconnect. This
      correlates with the 'delay' timer that is started on certain USB tx/rx
      errors in the URB completion handler.
      
      The problem is a race of usbnet_stop() with usbnet_start_xmit(). In
      usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in
      flight. This only makes sense if no new URBs are submitted
      concurrently, though. But the usbnet_start_xmit() can run at the same
      time on another CPU which almost unconditionally submits an URB. The
      error callback of the new URB will then schedule the timer after it was
      already stopped.
      
      The fix adds a check if the tx queue is stopped after the tx list lock
      has been taken. This should reliably prevent the submission of new URBs
      while usbnet_terminate_urbs() does its job. The same thing is done on
      the rx side even though it might be safe due to other flags that are
      checked there.
      Signed-off-by: default avatarJan Klötzke <Jan.Kloetzke@preh.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      332bff9d
    • Jisheng Zhang's avatar
      net: stmmac: fix reset gpio free missing · 16ffb5f7
      Jisheng Zhang authored
      [ Upstream commit 49ce881c0d4c4a7a35358d9dccd5f26d0e56fc61 ]
      
      Commit 984203ce ("net: stmmac: mdio: remove reset gpio free")
      removed the reset gpio free, when the driver is unbinded or rmmod,
      we miss the gpio free.
      
      This patch uses managed API to request the reset gpio, so that the
      gpio could be freed properly.
      
      Fixes: 984203ce
      
       ("net: stmmac: mdio: remove reset gpio free")
      Signed-off-by: default avatarJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16ffb5f7
    • Gustavo A. R. Silva's avatar
      cxgb3/l2t: Fix undefined behaviour · 5e75d5e2
      Gustavo A. R. Silva authored
      [ Upstream commit 76497732932f15e7323dc805e8ea8dc11bb587cf ]
      
      The use of zero-sized array causes undefined behaviour when it is not
      the last member in a structure. As it happens to be in this case.
      
      Also, the current code makes use of a language extension to the C90
      standard, but the preferred mechanism to declare variable-length
      types such as this one is a flexible array member, introduced in
      C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last. Which is beneficial
      to cultivate a high-quality code.
      
      Fixes: e48f129c
      
       ("[SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5e75d5e2
    • Piotr Figiel's avatar
      brcmfmac: fix race during disconnect when USB completion is in progress · 0a597d2b
      Piotr Figiel authored
      
      
      [ Upstream commit db3b9e2e1d58080d0754bdf9293dabf8c6491b67 ]
      
      It was observed that rarely during USB disconnect happening shortly after
      connect (before full initialization completes) usb_hub_wq would wait
      forever for the dev_init_lock to be unlocked. dev_init_lock would remain
      locked though because of infinite wait during usb_kill_urb:
      
      [ 2730.656472] kworker/0:2     D    0   260      2 0x00000000
      [ 2730.660700] Workqueue: events request_firmware_work_func
      [ 2730.664807] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
      [ 2730.670587] [<809dd164>] (schedule) from [<8069af44>] (usb_kill_urb+0xdc/0x114)
      [ 2730.676815] [<8069af44>] (usb_kill_urb) from [<7f258b50>] (brcmf_usb_free_q+0x34/0xa8 [brcmfmac])
      [ 2730.684833] [<7f258b50>] (brcmf_usb_free_q [brcmfmac]) from [<7f2517d4>] (brcmf_detach+0xa0/0xb8 [brcmfmac])
      [ 2730.693557] [<7f2517d4>] (brcmf_detach [brcmfmac]) from [<7f251a34>] (brcmf_attach+0xac/0x3d8 [brcmfmac])
      [ 2730.702094] [<7f251a34>] (brcmf_attach [brcmfmac]) from [<7f2587ac>] (brcmf_usb_probe_phase2+0x468/0x4a0 [brcmfmac])
      [ 2730.711601] [<7f2587ac>] (brcmf_usb_probe_phase2 [brcmfmac]) from [<7f252888>] (brcmf_fw_request_done+0x194/0x220 [brcmfmac])
      [ 2730.721795] [<7f252888>] (brcmf_fw_request_done [brcmfmac]) from [<805748e4>] (request_firmware_work_func+0x4c/0x88)
      [ 2730.731125] [<805748e4>] (request_firmware_work_func) from [<80141474>] (process_one_work+0x228/0x808)
      [ 2730.739223] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [ 2730.746105] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [ 2730.752227] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      
      [ 2733.099695] kworker/0:3     D    0  1065      2 0x00000000
      [ 2733.103926] Workqueue: usb_hub_wq hub_event
      [ 2733.106914] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
      [ 2733.112693] [<809dd164>] (schedule) from [<809e2a8c>] (schedule_timeout+0x214/0x3e4)
      [ 2733.119621] [<809e2a8c>] (schedule_timeout) from [<809dde2c>] (wait_for_common+0xc4/0x1c0)
      [ 2733.126810] [<809dde2c>] (wait_for_common) from [<7f258d00>] (brcmf_usb_disconnect+0x1c/0x4c [brcmfmac])
      [ 2733.135206] [<7f258d00>] (brcmf_usb_disconnect [brcmfmac]) from [<8069e0c8>] (usb_unbind_interface+0x5c/0x1e4)
      [ 2733.143943] [<8069e0c8>] (usb_unbind_interface) from [<8056d3e8>] (device_release_driver_internal+0x164/0x1fc)
      [ 2733.152769] [<8056d3e8>] (device_release_driver_internal) from [<8056c078>] (bus_remove_device+0xd0/0xfc)
      [ 2733.161138] [<8056c078>] (bus_remove_device) from [<8056977c>] (device_del+0x11c/0x310)
      [ 2733.167939] [<8056977c>] (device_del) from [<8069cba8>] (usb_disable_device+0xa0/0x1cc)
      [ 2733.174743] [<8069cba8>] (usb_disable_device) from [<8069507c>] (usb_disconnect+0x74/0x1dc)
      [ 2733.181823] [<8069507c>] (usb_disconnect) from [<80695e88>] (hub_event+0x478/0xf88)
      [ 2733.188278] [<80695e88>] (hub_event) from [<80141474>] (process_one_work+0x228/0x808)
      [ 2733.194905] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [ 2733.201724] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [ 2733.207913] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      
      It was traced down to a case where usb_kill_urb would be called on an URB
      structure containing more or less random data, including large number in
      its use_count. During the debugging it appeared that in brcmf_usb_free_q()
      the traversal over URBs' lists is not synchronized with operations on those
      lists in brcmf_usb_rx_complete() leading to handling
      brcmf_usbdev_info structure (holding lists' head) as lists' element and in
      result causing above problem.
      
      Fix it by walking through all URBs during brcmf_cancel_all_urbs using the
      arrays of requests instead of linked lists.
      Signed-off-by: default avatarPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0a597d2b
    • Piotr Figiel's avatar
      brcmfmac: convert dev_init_lock mutex to completion · f95ab00a
      Piotr Figiel authored
      
      
      [ Upstream commit a9fd0953fa4a62887306be28641b4b0809f3b2fd ]
      
      Leaving dev_init_lock mutex locked in probe causes BUG and a WARNING when
      kernel is compiled with CONFIG_PROVE_LOCKING. Convert mutex to completion
      which silences those warnings and improves code readability.
      
      Fix below errors when connecting the USB WiFi dongle:
      
      brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43143 for chip BCM43143/2
      BUG: workqueue leaked lock or atomic: kworker/0:2/0x00000000/434
           last function: hub_event
      1 lock held by kworker/0:2/434:
       #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: usb_hub_wq hub_event
      [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
      [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
      [<809c4324>] (dump_stack) from [<8014195c>] (process_one_work+0x710/0x808)
      [<8014195c>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xed1d9fb0 to 0xed1d9ff8)
      9fa0:                                     00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.19.23-00084-g454a789-dirty #123 Not tainted
      ------------------------------------------------------
      kworker/0:2/434 is trying to acquire lock:
      e29cf799 ((wq_completion)"events"){+.+.}, at: process_one_work+0x174/0x808
      
      but task is already holding lock:
      18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (&devinfo->dev_init_lock){+.+.}:
             mutex_lock_nested+0x1c/0x24
             brcmf_usb_probe+0x78/0x550 [brcmfmac]
             usb_probe_interface+0xc0/0x1bc
             really_probe+0x228/0x2c0
             __driver_attach+0xe4/0xe8
             bus_for_each_dev+0x68/0xb4
             bus_add_driver+0x19c/0x214
             driver_register+0x78/0x110
             usb_register_driver+0x84/0x148
             process_one_work+0x228/0x808
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      -> #1 (brcmf_driver_work){+.+.}:
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      -> #0 ((wq_completion)"events"){+.+.}:
             process_one_work+0x1b8/0x808
             worker_thread+0x2c/0x564
             kthread+0x13c/0x16c
             ret_from_fork+0x14/0x20
               (null)
      
      other info that might help us debug this:
      
      Chain exists of:
        (wq_completion)"events" --> brcmf_driver_work --> &devinfo->dev_init_lock
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&devinfo->dev_init_lock);
                                     lock(brcmf_driver_work);
                                     lock(&devinfo->dev_init_lock);
        lock((wq_completion)"events");
      
       *** DEADLOCK ***
      
      1 lock held by kworker/0:2/434:
       #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
      
      stack backtrace:
      CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Workqueue: events request_firmware_work_func
      [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
      [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
      [<809c4324>] (dump_stack) from [<80172838>] (print_circular_bug+0x210/0x330)
      [<80172838>] (print_circular_bug) from [<80175940>] (__lock_acquire+0x160c/0x1a30)
      [<80175940>] (__lock_acquire) from [<8017671c>] (lock_acquire+0xe0/0x268)
      [<8017671c>] (lock_acquire) from [<80141404>] (process_one_work+0x1b8/0x808)
      [<80141404>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
      [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
      [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xed1d9fb0 to 0xed1d9ff8)
      9fa0:                                     00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      Signed-off-by: default avatarPiotr Figiel <p.figiel@camlintechnologies.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f95ab00a
    • Arnd Bergmann's avatar
      b43: shut up clang -Wuninitialized variable warning · db74ef82
      Arnd Bergmann authored
      [ Upstream commit d825db346270dbceef83b7b750dbc29f1d7dcc0e ]
      
      Clang warns about what is clearly a case of passing an uninitalized
      variable into a static function:
      
      drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
            [-Werror,-Wuninitialized]
                      lpphy_papd_cal(dev, gains, 0, 1, 30);
                                          ^~~~~
      drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
              struct lpphy_tx_gains gains, oldgains;
              ^
      1 error generated.
      
      However, this function is empty, and its arguments are never evaluated,
      so gcc in contrast does not warn here. Both compilers behave in a
      reasonable way as far as I can tell, so we should change the code
      to avoid the warning everywhere.
      
      We could just eliminate the lpphy_papd_cal() function entirely,
      given that it has had the TODO comment in it for 10 years now
      and is rather unlikely to ever get done. I'm doing a simpler
      change here, and just pass the 'oldgains' variable in that has
      been initialized, based on the guess that this is what was
      originally meant.
      
      Fixes: 2c0d6100
      
       ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      db74ef82
    • Kangjie Lu's avatar
      brcmfmac: fix missing checks for kmemdup · 951fbf92
      Kangjie Lu authored
      
      
      [ Upstream commit 46953f97224d56a12ccbe9c6acaa84ca0dab2780 ]
      
      In case kmemdup fails, the fix sets conn_info->req_ie_len and
      conn_info->resp_ie_len to zero to avoid buffer overflows.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Acked-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      951fbf92
    • Kangjie Lu's avatar
      rtlwifi: fix a potential NULL pointer dereference · 1d3ee4d7
      Kangjie Lu authored
      
      
      [ Upstream commit 765976285a8c8db3f0eb7f033829a899d0c2786e ]
      
      In case alloc_workqueue fails, the fix reports the error and
      returns to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d3ee4d7
    • Nicholas Nunley's avatar
      i40e: don't allow changes to HW VLAN stripping on active port VLANs · 2ff310e6
      Nicholas Nunley authored
      
      
      [ Upstream commit bfb0ebed53857cfc57f11c63fa3689940d71c1c8 ]
      
      Modifying the VLAN stripping options when a port VLAN is configured
      will break traffic for the VSI, and conceptually doesn't make sense,
      so don't allow this.
      Signed-off-by: default avatarNicholas Nunley <nicholas.d.nunley@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2ff310e6
    • Kangjie Lu's avatar
      net: cw1200: fix a NULL pointer dereference · 50d25ca8
      Kangjie Lu authored
      
      
      [ Upstream commit 0ed2a005347400500a39ea7c7318f1fea57fb3ca ]
      
      In case create_singlethread_workqueue fails, the fix free the
      hardware and returns NULL to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      50d25ca8
    • Dan Carpenter's avatar
      mwifiex: prevent an array overflow · af2fb022
      Dan Carpenter authored
      [ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ]
      
      The "rate_index" is only used as an index into the phist_data->rx_rate[]
      array in the mwifiex_hist_data_set() function.  That array has
      MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
      debugfs information.  The "rate_index" variable comes from the network
      skb->data[] and it is a u8 so it's in the 0-255 range.  We need to cap
      it to prevent an array overflow.
      
      Fixes: cbf6e055
      
       ("mwifiex: add rx histogram statistics support")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      af2fb022
    • Dan Carpenter's avatar
      brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler() · a898d150
      Dan Carpenter authored
      [ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
      
      If "ret_len" is negative then it could lead to a NULL dereference.
      
      The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
      then we don't allocate the "dcmd_buf" buffer.  Then we pass "ret_len" to
      brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
      Most of the functions in that call tree check whether the buffer we pass
      is NULL but there are at least a couple places which don't such as
      brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd().  We memcpy() to and
      from the buffer so it would result in a NULL dereference.
      
      The fix is to change the types so that "ret_len" can't be negative.  (If
      we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
      issue).
      
      Fixes: 1bacb048
      
       ("brcmfmac: replace cfg80211 testmode with vendor command")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a898d150
    • YueHaibing's avatar
      cxgb4: Fix error path in cxgb4_init_module · 333e8303
      YueHaibing authored
      [ Upstream commit a3147770bea76c8dbad73eca3a24c2118da5e719 ]
      
      BUG: unable to handle kernel paging request at ffffffffa016a270
      PGD 3270067 P4D 3270067 PUD 3271063 PMD 230bbd067 PTE 0
      Oops: 0000 [#1
      CPU: 0 PID: 6134 Comm: modprobe Not tainted 5.1.0+ #33
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:atomic_notifier_chain_register+0x24/0x60
      Code: 1f 80 00 00 00 00 55 48 89 e5 41 54 49 89 f4 53 48 89 fb e8 ae b4 38 01 48 8b 53 38 48 8d 4b 38 48 85 d2 74 20 45 8b 44 24 10 <44> 3b 42 10 7e 08 eb 13 44 39 42 10 7c 0d 48 8d 4a 08 48 8b 52 08
      RSP: 0018:ffffc90000e2bc60 EFLAGS: 00010086
      RAX: 0000000000000292 RBX: ffffffff83467240 RCX: ffffffff83467278
      RDX: ffffffffa016a260 RSI: ffffffff83752140 RDI: ffffffff83467240
      RBP: ffffc90000e2bc70 R08: 0000000000000000 R09: 0000000000000001
      R10: 0000000000000000 R11: 00000000014fa61f R12: ffffffffa01c8260
      R13: ffff888231091e00 R14: 0000000000000000 R15: ffffc90000e2be78
      FS:  00007fbd8d7cd540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa016a270 CR3: 000000022c7e3000 CR4: 00000000000006f0
      Call Trace:
       register_inet6addr_notifier+0x13/0x20
       cxgb4_init_module+0x6c/0x1000 [cxgb4
       ? 0xffffffffa01d7000
       do_one_initcall+0x6c/0x3cc
       ? do_init_module+0x22/0x1f1
       ? rcu_read_lock_sched_held+0x97/0xb0
       ? kmem_cache_alloc_trace+0x325/0x3b0
       do_init_module+0x5b/0x1f1
       load_module+0x1db1/0x2690
       ? m_show+0x1d0/0x1d0
       __do_sys_finit_module+0xc5/0xd0
       __x64_sys_finit_module+0x15/0x20
       do_syscall_64+0x6b/0x1d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      If pci_register_driver fails, register inet6addr_notifier is
      pointless. This patch fix the error path in cxgb4_init_module.
      
      Fixes: b5a02f50
      
       ("cxgb4 : Update ipv6 address handling api")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      333e8303
    • YueHaibing's avatar
      at76c50x-usb: Don't register led_trigger if usb_register_driver failed · a1f254dc
      YueHaibing authored
      
      
      commit 09ac2694b0475f96be895848687ebcbba97eeecf upstream.
      
      Syzkaller report this:
      
      [ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
      [ 1213.469530] #PF error: [normal kernel read fault]
      [ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
      [ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
      [ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G         C        5.1.0-rc3+ #8
      [ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
      [ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
      [ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
      [ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
      [ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
      [ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
      [ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
      [ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
      [ 1213.473514] FS:  00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
      [ 1213.473514] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
      [ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 1213.473514] PKRU: 55555554
      [ 1213.473514] Call Trace:
      [ 1213.473514]  led_trigger_register+0x112/0x3f0
      [ 1213.473514]  led_trigger_register_simple+0x7a/0x110
      [ 1213.473514]  ? 0xffffffffc1c10000
      [ 1213.473514]  at76_mod_init+0x77/0x1000 [at76c50x_usb]
      [ 1213.473514]  do_one_initcall+0xbc/0x47d
      [ 1213.473514]  ? perf_trace_initcall_level+0x3a0/0x3a0
      [ 1213.473514]  ? kasan_unpoison_shadow+0x30/0x40
      [ 1213.473514]  ? kasan_unpoison_shadow+0x30/0x40
      [ 1213.473514]  do_init_module+0x1b5/0x547
      [ 1213.473514]  load_module+0x6405/0x8c10
      [ 1213.473514]  ? module_frob_arch_sections+0x20/0x20
      [ 1213.473514]  ? kernel_read_file+0x1e6/0x5d0
      [ 1213.473514]  ? find_held_lock+0x32/0x1c0
      [ 1213.473514]  ? cap_capable+0x1ae/0x210
      [ 1213.473514]  ? __do_sys_finit_module+0x162/0x190
      [ 1213.473514]  __do_sys_finit_module+0x162/0x190
      [ 1213.473514]  ? __ia32_sys_init_module+0xa0/0xa0
      [ 1213.473514]  ? __mutex_unlock_slowpath+0xdc/0x690
      [ 1213.473514]  ? wait_for_completion+0x370/0x370
      [ 1213.473514]  ? vfs_write+0x204/0x4a0
      [ 1213.473514]  ? do_syscall_64+0x18/0x450
      [ 1213.473514]  do_syscall_64+0x9f/0x450
      [ 1213.473514]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [ 1213.473514] RIP: 0033:0x462e99
      [ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      [ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      [ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
      [ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
      [ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
      [ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      
      If usb_register failed, no need to call led_trigger_register_simple.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 1264b951
      
       ("at76c50x-usb: add driver")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1f254dc
    • YueHaibing's avatar
      ppp: deflate: Fix possible crash in deflate_init · 2ff783f3
      YueHaibing authored
      
      
      [ Upstream commit 3ebe1bca58c85325c97a22d4fc3f5b5420752e6f ]
      
      BUG: unable to handle kernel paging request at ffffffffa018f000
      PGD 3270067 P4D 3270067 PUD 3271063 PMD 2307eb067 PTE 0
      Oops: 0000 [#1] PREEMPT SMP
      CPU: 0 PID: 4138 Comm: modprobe Not tainted 5.1.0-rc7+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:ppp_register_compressor+0x3e/0xd0 [ppp_generic]
      Code: 98 4a 3f e2 48 8b 15 c1 67 00 00 41 8b 0c 24 48 81 fa 40 f0 19 a0
      75 0e eb 35 48 8b 12 48 81 fa 40 f0 19 a0 74
      RSP: 0018:ffffc90000d93c68 EFLAGS: 00010287
      RAX: ffffffffa018f000 RBX: ffffffffa01a3000 RCX: 000000000000001a
      RDX: ffff888230c750a0 RSI: 0000000000000000 RDI: ffffffffa019f000
      RBP: ffffc90000d93c80 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0194080
      R13: ffff88822ee1a700 R14: 0000000000000000 R15: ffffc90000d93e78
      FS:  00007f2339557540(0000) GS:ffff888237a00000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa018f000 CR3: 000000022bde4000 CR4: 00000000000006f0
      Call Trace:
       ? 0xffffffffa01a3000
       deflate_init+0x11/0x1000 [ppp_deflate]
       ? 0xffffffffa01a3000
       do_one_initcall+0x6c/0x3cc
       ? kmem_cache_alloc_trace+0x248/0x3b0
       do_init_module+0x5b/0x1f1
       load_module+0x1db1/0x2690
       ? m_show+0x1d0/0x1d0
       __do_sys_finit_module+0xc5/0xd0
       __x64_sys_finit_module+0x15/0x20
       do_syscall_64+0x6b/0x1d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      If ppp_deflate fails to register in deflate_init,
      module initialization failed out, however
      ppp_deflate_draft may has been regiestred and not
      unregistered before return.
      Then the seconed modprobe will trigger crash like this.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ff783f3
    • Yunjian Wang's avatar
      net/mlx4_core: Change the error print to info print · dd20e0c0
      Yunjian Wang authored
      [ Upstream commit 00f9fec48157f3734e52130a119846e67a12314b ]
      
      The error print within mlx4_flow_steer_promisc_add() should
      be a info print.
      
      Fixes: 592e49dd
      
       ('net/mlx4: Implement promiscuous mode with device managed flow-steering')
      Signed-off-by: default avatarYunjian Wang <wangyunjian@huawei.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd20e0c0
  2. 16 May, 2019 20 commits
    • Jarod Wilson's avatar
      bonding: fix arp_validate toggling in active-backup mode · 7a22a4ea
      Jarod Wilson authored
      [ Upstream commit a9b8a2b39ce65df45687cf9ef648885c2a99fe75 ]
      
      There's currently a problem with toggling arp_validate on and off with an
      active-backup bond. At the moment, you can start up a bond, like so:
      
      modprobe bonding mode=1 arp_interval=100 arp_validate=0 arp_ip_targets=192.168.1.1
      ip link set bond0 down
      echo "ens4f0" > /sys/class/net/bond0/bonding/slaves
      echo "ens4f1" > /sys/class/net/bond0/bonding/slaves
      ip link set bond0 up
      ip addr add 192.168.1.2/24 dev bond0
      
      Pings to 192.168.1.1 work just fine. Now turn on arp_validate:
      
      echo 1 > /sys/class/net/bond0/bonding/arp_validate
      
      Pings to 192.168.1.1 continue to work just fine. Now when you go to turn
      arp_validate off again, the link falls flat on it's face:
      
      echo 0 > /sys/class/net/bond0/bonding/arp_validate
      dmesg
      ...
      [133191.911987] bond0: Setting arp_validate to none (0)
      [133194.257793] bond0: bond_should_notify_peers: slave ens4f0
      [133194.258031] bond0: link status definitely down for interface ens4f0, disabling it
      [133194.259000] bond0: making interface ens4f1 the new active one
      [133197.330130] bond0: link status definitely down for interface ens4f1, disabling it
      [133197.331191] bond0: now running without any active interface!
      
      The problem lies in bond_options.c, where passing in arp_validate=0
      results in bond->recv_probe getting set to NULL. This flies directly in
      the face of commit 3fe68df9, which says we need to set recv_probe =
      bond_arp_recv, even if we're not using arp_validate. Said commit fixed
      this in bond_option_arp_interval_set, but missed that we can get to that
      same state in bond_option_arp_validate_set as well.
      
      One solution would be to universally set recv_probe = bond_arp_recv here
      as well, but I don't think bond_option_arp_validate_set has any business
      touching recv_probe at all, and that should be left to the arp_interval
      code, so we can just make things much tidier here.
      
      Fixes: 3fe68df9
      
       ("bonding: always set recv_probe to bond_arp_rcv in arp monitor")
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a22a4ea
    • Christophe Leroy's avatar
      net: ucc_geth - fix Oops when changing number of buffers in the ring · 1261f44d
      Christophe Leroy authored
      [ Upstream commit ee0df19305d9fabd9479b785918966f6e25b733b ]
      
      When changing the number of buffers in the RX ring while the interface
      is running, the following Oops is encountered due to the new number
      of buffers being taken into account immediately while their allocation
      is done when opening the device only.
      
      [   69.882706] Unable to handle kernel paging request for data at address 0xf0000100
      [   69.890172] Faulting instruction address: 0xc033e164
      [   69.895122] Oops: Kernel access of bad area, sig: 11 [#1]
      [   69.900494] BE PREEMPT CMPCPRO
      [   69.907120] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.115-00006-g179ade8ce3-dirty #269
      [   69.915956] task: c0684310 task.stack: c06da000
      [   69.920470] NIP:  c033e164 LR: c02e44d0 CTR: c02e41fc
      [   69.925504] REGS: dfff1e20 TRAP: 0300   Not tainted  (4.14.115-00006-g179ade8ce3-dirty)
      [   69.934161] MSR:  00009032 <EE,ME,IR,DR,RI>  CR: 22004428  XER: 20000000
      [   69.940869] DAR: f0000100 DSISR: 20000000
      [   69.940869] GPR00: c0352d70 dfff1ed0 c0684310 f00000a4 00000040 dfff1f68 00000000 0000001f
      [   69.940869] GPR08: df53f410 1cc00040 00000021 c0781640 42004424 100c82b6 f00000a4 df53f5b0
      [   69.940869] GPR16: df53f6c0 c05daf84 00000040 00000000 00000040 c0782be4 00000000 00000001
      [   69.940869] GPR24: 00000000 df53f400 000001b0 df53f410 df53f000 0000003f df708220 1cc00044
      [   69.978348] NIP [c033e164] skb_put+0x0/0x5c
      [   69.982528] LR [c02e44d0] ucc_geth_poll+0x2d4/0x3f8
      [   69.987384] Call Trace:
      [   69.989830] [dfff1ed0] [c02e4554] ucc_geth_poll+0x358/0x3f8 (unreliable)
      [   69.996522] [dfff1f20] [c0352d70] net_rx_action+0x248/0x30c
      [   70.002099] [dfff1f80] [c04e93e4] __do_softirq+0xfc/0x310
      [   70.007492] [dfff1fe0] [c0021124] irq_exit+0xd0/0xd4
      [   70.012458] [dfff1ff0] [c000e7e0] call_do_irq+0x24/0x3c
      [   70.017683] [c06dbe80] [c0006bac] do_IRQ+0x64/0xc4
      [   70.022474] [c06dbea0] [c001097c] ret_from_except+0x0/0x14
      [   70.027964] --- interrupt: 501 at rcu_idle_exit+0x84/0x90
      [   70.027964]     LR = rcu_idle_exit+0x74/0x90
      [   70.037585] [c06dbf60] [20000000] 0x20000000 (unreliable)
      [   70.042984] [c06dbf80] [c004bb0c] do_idle+0xb4/0x11c
      [   70.047945] [c06dbfa0] [c004bd14] cpu_startup_entry+0x18/0x1c
      [   70.053682] [c06dbfb0] [c05fb034] start_kernel+0x370/0x384
      [   70.059153] [c06dbff0] [00003438] 0x3438
      [   70.063062] Instruction dump:
      [   70.066023] 38a00000 38800000 90010014 4bfff015 80010014 7c0803a6 3123ffff 7c691910
      [   70.073767] 38210010 4e800020 38600000 4e800020 <80e3005c> 80c30098 3107ffff 7d083910
      [   70.081690] ---[ end trace be7ccd9c1e1a9f12 ]---
      
      This patch forbids the modification of the number of buffers in the
      ring while the interface is running.
      
      Fixes: ac421852
      
       ("ucc_geth: add ethtool support")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1261f44d
    • Wei Yongjun's avatar
      cw1200: fix missing unlock on error in cw1200_hw_scan() · 9767260b
      Wei Yongjun authored
      
      
      commit 51c8d24101c79ffce3e79137e2cee5dfeb956dd7 upstream.
      
      Add the missing unlock before return from function cw1200_hw_scan()
      in the error handling case.
      
      Fixes: 4f68ef64cd7f ("cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan()")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Acked-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      [iwamatsu: Change the patching file from drivers/net/wireless/st/cw1200/scan.c to
      drivers/net/wireless/cw1200/scan.c]
      Signed-off-by: default avatarNobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9767260b
    • Yonglong Liu's avatar
      net: hns: Fix WARNING when remove HNS driver with SMMU enabled · 550ce5b3
      Yonglong Liu authored
      
      
      [ Upstream commit 8601a99d7c0256b7a7fdd1ab14cf6c1f1dfcadc6 ]
      
      When enable SMMU, remove HNS driver will cause a WARNING:
      
      [  141.924177] WARNING: CPU: 36 PID: 2708 at drivers/iommu/dma-iommu.c:443 __iommu_dma_unmap+0xc0/0xc8
      [  141.954673] Modules linked in: hns_enet_drv(-)
      [  141.963615] CPU: 36 PID: 2708 Comm: rmmod Tainted: G        W         5.0.0-rc1-28723-gb729c57de95c-dirty #32
      [  141.983593] Hardware name: Huawei D05/D05, BIOS Hisilicon D05 UEFI Nemo 1.8 RC0 08/31/2017
      [  142.000244] pstate: 60000005 (nZCv daif -PAN -UAO)
      [  142.009886] pc : __iommu_dma_unmap+0xc0/0xc8
      [  142.018476] lr : __iommu_dma_unmap+0xc0/0xc8
      [  142.027066] sp : ffff000013533b90
      [  142.033728] x29: ffff000013533b90 x28: ffff8013e6983600
      [  142.044420] x27: 0000000000000000 x26: 0000000000000000
      [  142.055113] x25: 0000000056000000 x24: 0000000000000015
      [  142.065806] x23: 0000000000000028 x22: ffff8013e66eee68
      [  142.076499] x21: ffff8013db919800 x20: 0000ffffefbff000
      [  142.087192] x19: 0000000000001000 x18: 0000000000000007
      [  142.097885] x17: 000000000000000e x16: 0000000000000001
      [  142.108578] x15: 0000000000000019 x14: 363139343a70616d
      [  142.119270] x13: 6e75656761705f67 x12: 0000000000000000
      [  142.129963] x11: 00000000ffffffff x10: 0000000000000006
      [  142.140656] x9 : 1346c1aa88093500 x8 : ffff0000114de4e0
      [  142.151349] x7 : 6662666578303d72 x6 : ffff0000105ffec8
      [  142.162042] x5 : 0000000000000000 x4 : 0000000000000000
      [  142.172734] x3 : 00000000ffffffff x2 : ffff0000114de500
      [  142.183427] x1 : 0000000000000000 x0 : 0000000000000035
      [  142.194120] Call trace:
      [  142.199030]  __iommu_dma_unmap+0xc0/0xc8
      [  142.206920]  iommu_dma_unmap_page+0x20/0x28
      [  142.215335]  __iommu_unmap_page+0x40/0x60
      [  142.223399]  hnae_unmap_buffer+0x110/0x134
      [  142.231639]  hnae_free_desc+0x6c/0x10c
      [  142.239177]  hnae_fini_ring+0x14/0x34
      [  142.246540]  hnae_fini_queue+0x2c/0x40
      [  142.254080]  hnae_put_handle+0x38/0xcc
      [  142.261619]  hns_nic_dev_remove+0x54/0xfc [hns_enet_drv]
      [  142.272312]  platform_drv_remove+0x24/0x64
      [  142.280552]  device_release_driver_internal+0x17c/0x20c
      [  142.291070]  driver_detach+0x4c/0x90
      [  142.298259]  bus_remove_driver+0x5c/0xd8
      [  142.306148]  driver_unregister+0x2c/0x54
      [  142.314037]  platform_driver_unregister+0x10/0x18
      [  142.323505]  hns_nic_dev_driver_exit+0x14/0xf0c [hns_enet_drv]
      [  142.335248]  __arm64_sys_delete_module+0x214/0x25c
      [  142.344891]  el0_svc_common+0xb0/0x10c
      [  142.352430]  el0_svc_handler+0x24/0x80
      [  142.359968]  el0_svc+0x8/0x7c0
      [  142.366104] ---[ end trace 60ad1cd58e63c407 ]---
      
      The tx ring buffer map when xmit and unmap when xmit done. So in
      hnae_init_ring() did not map tx ring buffer, but in hnae_fini_ring()
      have a unmap operation for tx ring buffer, which is already unmapped
      when xmit done, than cause this WARNING.
      
      The hnae_alloc_buffers() is called in hnae_init_ring(),
      so the hnae_free_buffers() should be in hnae_fini_ring(), not in
      hnae_free_desc().
      
      In hnae_fini_ring(), adds a check is_rx_ring() as in hnae_init_ring().
      When the ring buffer is tx ring, adds a piece of code to ensure that
      the tx ring is unmap.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      550ce5b3
    • Yonglong Liu's avatar
      net: hns: Use NAPI_POLL_WEIGHT for hns driver · c8d4b98e
      Yonglong Liu authored
      
      
      [ Upstream commit acb1ce15a61154aa501891d67ebf79bc9ea26818 ]
      
      When the HNS driver loaded, always have an error print:
      "netif_napi_add() called with weight 256"
      
      This is because the kernel checks the NAPI polling weights
      requested by drivers and it prints an error message if a driver
      requests a weight bigger than 64.
      
      So use NAPI_POLL_WEIGHT to fix it.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c8d4b98e
    • Konstantin Khorenko's avatar
      bonding: show full hw address in sysfs for slave entries · cd43ccbf
      Konstantin Khorenko authored
      
      
      [ Upstream commit 18bebc6dd3281955240062655a4df35eef2c46b3 ]
      
      Bond expects ethernet hwaddr for its slave, but it can be longer than 6
      bytes - infiniband interface for example.
      
       # cat /sys/devices/<skipped>/net/ib0/address
       80:00:02:08:fe:80:00:00:00:00:00:00:7c:fe:90:03:00:be:5d:e1
      
       # cat /sys/devices/<skipped>/net/ib0/bonding_slave/perm_hwaddr
       80:00:02:08:fe:80
      
      So print full hwaddr in sysfs "bonding_slave/perm_hwaddr" as well.
      Signed-off-by: default avatarKonstantin Khorenko <khorenko@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cd43ccbf
    • Arvind Sankar's avatar
      igb: Fix WARN_ONCE on runtime suspend · 88020a14
      Arvind Sankar authored
      
      
      [ Upstream commit dabb8338be533c18f50255cf39ff4f66d4dabdbe ]
      
      The runtime_suspend device callbacks are not supposed to save
      configuration state or change the power state. Commit fb29f76cc566
      ("igb: Fix an issue that PME is not enabled during runtime suspend")
      changed the driver to not save configuration state during runtime
      suspend, however the driver callback still put the device into a
      low-power state. This causes a warning in the pci pm core and results in
      pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend.
      
      Fix this by not changing the power state either, leaving that to pci pm
      core, and make the same change for suspend callback as well.
      
      Also move a couple of defines into the appropriate header file instead
      of inline in the .c file.
      
      Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend")
      Signed-off-by: default avatarArvind Sankar <niveditas98@gmail.com>
      Reviewed-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      88020a14
    • Michael Chan's avatar
      bnxt_en: Improve multicast address setup logic. · aed15cc2
      Michael Chan authored
      [ Upstream commit b4e30e8e7ea1d1e35ffd64ca46f7d9a7f227b4bf ]
      
      The driver builds a list of multicast addresses and sends it to the
      firmware when the driver's ndo_set_rx_mode() is called.  In rare
      cases, the firmware can fail this call if internal resources to
      add multicast addresses are exhausted.  In that case, we should
      try the call again by setting the ALL_MCAST flag which is more
      guaranteed to succeed.
      
      Fixes: c0c050c5
      
       ("bnxt_en: New Broadcom ethernet driver.")
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aed15cc2
    • Wen Yang's avatar
      net: ethernet: ti: fix possible object reference leak · f18c946e
      Wen Yang authored
      
      
      [ Upstream commit 75eac7b5f68b0a0671e795ac636457ee27cc11d8 ]
      
      The call to of_get_child_by_name returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/net/ethernet/ti/netcp_ethss.c:3661:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function.
      ./drivers/net/ethernet/ti/netcp_ethss.c:3665:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3654, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Wingman Kwok <w-kwok2@ti.com>
      Cc: Murali Karicheri <m-karicheri2@ti.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      f18c946e
    • Wen Yang's avatar
      net: ibm: fix possible object reference leak · 64206dd0
      Wen Yang authored
      
      
      [ Upstream commit be693df3cf9dd113ff1d2c0d8150199efdba37f6 ]
      
      The call to ehea_get_eth_dn returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/net/ethernet/ibm/ehea/ehea_main.c:3163:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3154, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Douglas Miller <dougmill@linux.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      64206dd0
    • Wen Yang's avatar
      net: xilinx: fix possible object reference leak · ae35f101
      Wen Yang authored
      
      
      [ Upstream commit fa3a419d2f674b431d38748cb58fb7da17ee8949 ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1624:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1569, but without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Anirudha Sarangi <anirudh@xilinx.com>
      Cc: John Linn <John.Linn@xilinx.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      ae35f101
    • Lukas Wunner's avatar
      net: ks8851: Set initial carrier state to down · c0d641aa
      Lukas Wunner authored
      
      
      [ Upstream commit 9624bafa5f6418b9ca5b3f66d1f6a6a2e8bf6d4c ]
      
      The ks8851 chip's initial carrier state is down. A Link Change Interrupt
      is signaled once interrupts are enabled if the carrier is up.
      
      The ks8851 driver has it backwards by assuming that the initial carrier
      state is up. The state is therefore misrepresented if the interface is
      opened with no cable attached. Fix it.
      
      The Link Change interrupt is sometimes not signaled unless the P1MBSR
      register (which contains the Link Status bit) is read on ->ndo_open().
      This might be a hardware erratum. Read the register by calling
      mii_check_link(), which has the desirable side effect of setting the
      carrier state to down if the cable was detached while the interface was
      closed.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      c0d641aa
    • Lukas Wunner's avatar
      net: ks8851: Delay requesting IRQ until opened · f41b4fd8
      Lukas Wunner authored
      
      
      [ Upstream commit d268f31552794abf5b6aa5af31021643411f25f5 ]
      
      The ks8851 driver currently requests the IRQ before registering the
      net_device.  Because the net_device name is used as IRQ name and is
      still "eth%d" when the IRQ is requested, it's impossibe to tell IRQs
      apart if multiple ks8851 chips are present.  Most other drivers delay
      requesting the IRQ until the net_device is opened.  Do the same.
      
      The driver doesn't enable interrupts on the chip before opening the
      net_device and disables them when closing it, so there doesn't seem to
      be a need to request the IRQ already on probe.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      f41b4fd8
    • Lukas Wunner's avatar
      net: ks8851: Reassert reset pin if chip ID check fails · 195aac29
      Lukas Wunner authored
      [ Upstream commit 761cfa979a0c177d6c2d93ef5585cd79ae49a7d5 ]
      
      Commit 73fdeb82
      
       ("net: ks8851: Add optional vdd_io regulator and
      reset gpio") amended the ks8851 driver to briefly assert the chip's
      reset pin on probe. It also amended the probe routine's error path to
      reassert the reset pin if a subsequent initialization step fails.
      
      However the commit misplaced reassertion of the reset pin in the error
      path such that it is not performed if the check of the Chip ID and
      Enable Register (CIDER) fails. The error path is therefore slightly
      asymmetrical to the probe routine's body. Fix it.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      195aac29
    • Lukas Wunner's avatar
      net: ks8851: Dequeue RX packets explicitly · 36b1240d
      Lukas Wunner authored
      
      
      [ Upstream commit 536d3680fd2dab5c39857d62a3e084198fc74ff9 ]
      
      The ks8851 driver lets the chip auto-dequeue received packets once they
      have been read in full. It achieves that by setting the ADRFE flag in
      the RXQCR register ("Auto-Dequeue RXQ Frame Enable").
      
      However if allocation of a packet's socket buffer or retrieval of the
      packet over the SPI bus fails, the packet will not have been read in
      full and is not auto-dequeued. Such partial retrieval of a packet
      confuses the chip's RX queue management:  On the next RX interrupt,
      the first packet read from the queue will be the one left there
      previously and this one can be retrieved without issues. But for any
      newly received packets, the frame header status and byte count registers
      (RXFHSR and RXFHBCR) contain bogus values, preventing their retrieval.
      
      The chip allows explicitly dequeueing a packet from the RX queue by
      setting the RRXEF flag in the RXQCR register ("Release RX Error Frame").
      This could be used to dequeue the packet in case of an error, but if
      that error is a failed SPI transfer, it is unknown if the packet was
      transferred in full and was auto-dequeued or if it was only transferred
      in part and requires an explicit dequeue. The safest approach is thus
      to always dequeue packets explicitly and forgo auto-dequeueing.
      
      Without this change, I've witnessed packet retrieval break completely
      when an SPI DMA transfer fails, requiring a chip reset. Explicit
      dequeueing magically fixes this and makes packet retrieval absolutely
      robust for me.
      
      The chip's documentation suggests auto-dequeuing and uses the RRXEF
      flag only to dequeue error frames which the driver doesn't want to
      retrieve. But that seems to be a fair-weather approach.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      36b1240d
    • Aditya Pakki's avatar
      qlcnic: Avoid potential NULL pointer dereference · d3114799
      Aditya Pakki authored
      
      
      [ Upstream commit 5bf7295fe34a5251b1d241b9736af4697b590670 ]
      
      netdev_alloc_skb can fail and return a NULL pointer which is
      dereferenced without a check. The patch avoids such a scenario.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin (Microsoft) <sashal@kernel.org>
      d3114799
    • Gustavo A. R. Silva's avatar
      usbnet: ipheth: fix potential null pointer dereference in ipheth_carrier_set · 1652d119
      Gustavo A. R. Silva authored
      commit 61c59355 upstream.
      
      _dev_ is being dereferenced before it is null checked, hence there
      is a potential null pointer dereference.
      
      Fix this by moving the pointer dereference after _dev_ has been null
      checked.
      
      Addresses-Coverity-ID: 1462020
      Fixes: bb1b40c7
      
       ("usbnet: ipheth: prevent TX queue timeouts when device not ready")
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1652d119
    • Alexander Kappner's avatar
      usbnet: ipheth: prevent TX queue timeouts when device not ready · 4f2df9fd
      Alexander Kappner authored
      commit bb1b40c7
      
       upstream.
      
      iOS devices require the host to be "trusted" before servicing network
      packets. Establishing trust requires the user to confirm a dialog on the
      iOS device.Until trust is established, the iOS device will silently discard
      network packets from the host. Currently, the ipheth driver does not detect
      whether an iOS device has established trust with the host, and immediately
      sets up the transmit queues.
      
      This causes the following problems:
      
      - Kernel taint due to WARN() in netdev watchdog.
      - Dmesg spam ("TX timeout").
      - Disruption of user space networking activity (dhcpd, etc...) when new
      interface comes up but cannot be used.
      - Unnecessary host and device wakeups and USB traffic
      
      Example dmesg output:
      
      [ 1101.319778] NETDEV WATCHDOG: eth1 (ipheth): transmit queue 0 timed out
      [ 1101.319817] ------------[ cut here ]------------
      [ 1101.319828] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x20f/0x220
      [ 1101.319831] Modules linked in: ipheth usbmon nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) iwlmvm mac80211 iwlwifi btusb btrtl btbcm btintel qmi_wwan bluetooth cfg80211 ecdh_generic thinkpad_acpi rfkill [last unloaded: ipheth]
      [ 1101.319861] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P           O    4.13.12.1 #1
      [ 1101.319864] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W (1.35 ) 11/10/2016
      [ 1101.319867] task: ffffffff81e11500 task.stack: ffffffff81e00000
      [ 1101.319873] RIP: 0010:dev_watchdog+0x20f/0x220
      [ 1101.319876] RSP: 0018:ffff8810a3c03e98 EFLAGS: 00010292
      [ 1101.319880] RAX: 000000000000003a RBX: 0000000000000000 RCX: 0000000000000000
      [ 1101.319883] RDX: ffff8810a3c15c48 RSI: ffffffff81ccbfc2 RDI: 00000000ffffffff
      [ 1101.319886] RBP: ffff880c04ebc41c R08: 0000000000000000 R09: 0000000000000379
      [ 1101.319889] R10: 00000100696589d0 R11: 0000000000000378 R12: ffff880c04ebc000
      [ 1101.319892] R13: 0000000000000000 R14: 0000000000000001 R15: ffff880c2865fc80
      [ 1101.319896] FS:  0000000000000000(0000) GS:ffff8810a3c00000(0000) knlGS:0000000000000000
      [ 1101.319899] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1101.319902] CR2: 00007f3ff24ac000 CR3: 0000000001e0a000 CR4: 00000000003406f0
      [ 1101.319905] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1101.319908] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 1101.319910] Call Trace:
      [ 1101.319914]  <IRQ>
      [ 1101.319921]  ? dev_graft_qdisc+0x70/0x70
      [ 1101.319928]  ? dev_graft_qdisc+0x70/0x70
      [ 1101.319934]  ? call_timer_fn+0x2e/0x170
      [ 1101.319939]  ? dev_graft_qdisc+0x70/0x70
      [ 1101.319944]  ? run_timer_softirq+0x1ea/0x440
      [ 1101.319951]  ? timerqueue_add+0x54/0x80
      [ 1101.319956]  ? enqueue_hrtimer+0x38/0xa0
      [ 1101.319963]  ? __do_softirq+0xed/0x2e7
      [ 1101.319970]  ? irq_exit+0xb4/0xc0
      [ 1101.319976]  ? smp_apic_timer_interrupt+0x39/0x50
      [ 1101.319981]  ? apic_timer_interrupt+0x8c/0xa0
      [ 1101.319983]  </IRQ>
      [ 1101.319992]  ? cpuidle_enter_state+0xfa/0x2a0
      [ 1101.319999]  ? do_idle+0x1a3/0x1f0
      [ 1101.320004]  ? cpu_startup_entry+0x5f/0x70
      [ 1101.320011]  ? start_kernel+0x444/0x44c
      [ 1101.320017]  ? early_idt_handler_array+0x120/0x120
      [ 1101.320023]  ? x86_64_start_kernel+0x145/0x154
      [ 1101.320028]  ? secondary_startup_64+0x9f/0x9f
      [ 1101.320033] Code: 20 04 00 00 eb 9f 4c 89 e7 c6 05 59 44 71 00 01 e8 a7 df fd ff 89 d9 4c 89 e6 48 c7 c7 70 b7 cd 81 48 89 c2 31 c0 e8 97 64 90 ff <0f> ff eb bf 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
      [ 1101.320103] ---[ end trace 0cc4d251e2b57080 ]---
      [ 1101.320110] ipheth 1-5:4.2: ipheth_tx_timeout: TX timeout
      
      The last message "TX timeout" is repeated every 5 seconds until trust is
      established or the device is disconnected, filling up dmesg.
      
      The proposed patch eliminates the problem by, upon connection, keeping the
      TX queue and carrier disabled until a packet is first received from the iOS
      device. This is reflected by the confirmed_pairing variable in the device
      structure. Only after at least one packet has been received from the iOS
      device, the transmit queue and carrier are brought up during the periodic
      device poll in ipheth_carrier_set. Because the iOS device will always send
      a packet immediately upon trust being established, this should not delay
      the interface becoming useable. To prevent failed UBRs in
      ipheth_rcvbulk_callback from perpetually re-enabling the queue if it was
      disabled, a new check is added so only successful transfers re-enable the
      queue, whereas failed transfers only trigger an immediate poll.
      
      This has the added benefit of removing the periodic control requests to the
      iOS device until trust has been established and thus should reduce wakeup
      events on both the host and the iOS device.
      Signed-off-by: default avatarAlexander Kappner <agk@godking.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [groeck: Fixed context conflict seen because 45611c61dd50 was applied first]
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f2df9fd
    • Vinod Koul's avatar
      net: stmmac: move stmmac_check_ether_addr() to driver probe · 8cab9c87
      Vinod Koul authored
      
      
      [ Upstream commit b561af36b1841088552464cdc3f6371d92f17710 ]
      
      stmmac_check_ether_addr() checks the MAC address and assigns one in
      driver open(). In many cases when we create slave netdevice, the dev
      addr is inherited from master but the master dev addr maybe NULL at
      that time, so move this call to driver probe so that address is
      always valid.
      Signed-off-by: default avatarXiaofei Shen <xiaofeis@codeaurora.org>
      Tested-by: default avatarXiaofei Shen <xiaofeis@codeaurora.org>
      Signed-off-by: default avatarSneh Shah <snehshah@codeaurora.org>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8cab9c87
    • Hangbin Liu's avatar
      team: fix possible recursive locking when add slaves · 1990e41b
      Hangbin Liu authored
      [ Upstream commit 925b0c841e066b488cc3a60272472b2c56300704 ]
      
      If we add a bond device which is already the master of the team interface,
      we will hold the team->lock in team_add_slave() first and then request the
      lock in team_set_mac_address() again. The functions are called like:
      
      - team_add_slave()
       - team_port_add()
         - team_port_enter()
           - team_modeop_port_enter()
             - __set_port_dev_addr()
               - dev_set_mac_address()
                 - bond_set_mac_address()
                   - dev_set_mac_address()
        	       - team_set_mac_address
      
      Although team_upper_dev_link() would check the upper devices but it is
      called too late. Fix it by adding a checking before processing the slave.
      
      v2: Do not split the string in netdev_err()
      
      Fixes: 3d249d4c
      
       ("net: introduce ethernet teaming device")
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1990e41b