Skip to content
Snippets Groups Projects
  1. Jan 25, 2017
    • Geert Uytterhoeven's avatar
      net: phy: leds: Clear phy_num_led_triggers on failure to avoid crash · 8a87fca8
      Geert Uytterhoeven authored
      
      phy_attach_direct() ignores errors returned by
      phy_led_triggers_register(). I think that's OK, as LED triggers can be
      considered a non-critical feature.
      
      However, this causes problems later:
        - phy_led_trigger_change_speed() will access the array
          phy_device.phy_led_triggers, which has been freed in the error path
          of phy_led_triggers_register(), which may lead to a crash.
      
        - phy_led_triggers_unregister() will access the same array, leading to
          crashes during s2ram or poweroff, like:
      
      	Unable to handle kernel NULL pointer dereference at virtual address
      	00000000
      	...
      	[<c04116d4>] (__list_del_entry_valid) from [<c05e8948>] (led_trigger_unregister+0x34/0xcc)
      	[<c05e8948>] (led_trigger_unregister) from [<c05336c4>] (phy_led_triggers_unregister+0x28/0x34)
      	[<c05336c4>] (phy_led_triggers_unregister) from [<c0531d44>] (phy_detach+0x30/0x74)
      	[<c0531d44>] (phy_detach) from [<c0538bdc>] (sh_eth_close+0x64/0x9c)
      	[<c0538bdc>] (sh_eth_close) from [<c04d4ce0>] (dpm_run_callback+0x48/0xc8)
      
          or:
      
      	list_del corruption. prev->next should be dede6540, but was 2e323931
      	------------[ cut here ]------------
      	kernel BUG at lib/list_debug.c:52!
      	...
      	[<c02f6d70>] (__list_del_entry_valid) from [<c0425168>] (led_trigger_unregister+0x34/0xcc)
      	[<c0425168>] (led_trigger_unregister) from [<c03a05a0>] (phy_led_triggers_unregister+0x28/0x34)
      	[<c03a05a0>] (phy_led_triggers_unregister) from [<c039ec04>] (phy_detach+0x30/0x74)
      	[<c039ec04>] (phy_detach) from [<c03a4fc0>] (sh_eth_close+0x6c/0xa4)
      	[<c03a4fc0>] (sh_eth_close) from [<c0483234>] (__dev_close_many+0xac/0xd0)
      
      To fix this, clear phy_device.phy_num_led_triggers in the error path of
      phy_led_triggers_register() fails.
      
      Note that the "No phy led trigger registered for speed" message will
      still be printed on link speed changes, which is a good cue that
      something went wrong with the LED triggers.
      
      Fixes: 2e0bc452 ("net: phy: leds: add support for led triggers on phy link state change")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a87fca8
    • John Crispin's avatar
      net-next: ethernet: mediatek: change the compatible string · 8b901f6b
      John Crispin authored
      
      When the binding was defined, I was not aware that mt2701 was an earlier
      version of the SoC. For sake of consistency, the ethernet driver should
      use mt2701 inside the compat string as this is the earliest SoC with the
      ethernet core.
      
      The ethernet driver is currently of no real use until we finish and
      upstream the DSA driver. There are no users of this binding yet. It should
      be safe to fix this now before it is too late and we need to provide
      backward compatibility for the mt7623-eth compat string.
      
      Reported-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarJohn Crispin <john@phrozen.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b901f6b
    • Michael Chan's avatar
      bnxt_en: Fix RTNL lock usage on bnxt_get_port_module_status(). · 90c694bb
      Michael Chan authored
      
      bnxt_get_port_module_status() calls bnxt_update_link() which expects
      RTNL to be held.  In bnxt_sp_task() that does not hold RTNL, we need to
      call it with a prior call to bnxt_rtnl_lock_sp() and the call needs to
      be moved to the end of bnxt_sp_task().
      
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90c694bb
    • Michael Chan's avatar
      bnxt_en: Fix RTNL lock usage on bnxt_update_link(). · 0eaa24b9
      Michael Chan authored
      
      bnxt_update_link() is called from multiple code paths.  Most callers,
      such as open, ethtool, already hold RTNL.  Only the caller bnxt_sp_task()
      does not.  So it is a bug to take RTNL inside bnxt_update_link().
      
      Fix it by removing the RTNL inside bnxt_update_link().  The function
      now expects the caller to always hold RTNL.
      
      In bnxt_sp_task(), call bnxt_rtnl_lock_sp() before calling
      bnxt_update_link().  We also need to move the call to the end of
      bnxt_sp_task() since it will be clearing the BNXT_STATE_IN_SP_TASK bit.
      
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0eaa24b9
    • Michael Chan's avatar
      bnxt_en: Fix bnxt_reset() in the slow path task. · a551ee94
      Michael Chan authored
      
      In bnxt_sp_task(), we set a bit BNXT_STATE_IN_SP_TASK so that bnxt_close()
      will synchronize and wait for bnxt_sp_task() to finish.  Some functions
      in bnxt_sp_task() require us to clear BNXT_STATE_IN_SP_TASK and then
      acquire rtnl_lock() to prevent race conditions.
      
      There are some bugs related to this logic. This patch refactors the code
      to have common bnxt_rtnl_lock_sp() and bnxt_rtnl_unlock_sp() to handle
      the RTNL and the clearing/setting of the bit.  Multiple functions will
      need the same logic.  We also need to move bnxt_reset() to the end of
      bnxt_sp_task().  Functions that clear BNXT_STATE_IN_SP_TASK must be the
      last functions to be called in bnxt_sp_task().  The common scheme will
      handle the condition properly.
      
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a551ee94
  2. Jan 24, 2017
  3. Jan 23, 2017
  4. Jan 22, 2017
  5. Jan 20, 2017
  6. Jan 19, 2017
  7. Jan 18, 2017
  8. Jan 17, 2017
  9. Jan 16, 2017
Loading