1. 25 Jan, 2017 11 commits
    • Geert Uytterhoeven's avatar
      net: phy: leds: Break dependency of phy.h on phy_led_triggers.h · d6f8cfa3
      Geert Uytterhoeven authored
      <linux/phy.h> includes <linux/phy_led_triggers.h>, which is not really
      needed.  Drop the include from <linux/phy.h>, and add it to all users
      that didn't include it explicitly.
      Suggested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6f8cfa3
    • 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
    • John Crispin's avatar
      Documentation: devicetree: change the mediatek ethernet compatible string · 61976fff
      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>
      Reviewed-by: default avatarMatthias Brugger <matthias.bgg@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61976fff
    • David S. Miller's avatar
      Merge branch 'bnxt_en-rtnl-fixes' · c0d9665f
      David S. Miller authored
      Michael Chan says:
      
      ====================
      bnxt_en: Fix RTNL lock usage in bnxt_sp_task().
      
      There are 2 function calls from bnxt_sp_task() that have buggy RTNL
      usage.  These 2 functions take RTNL lock under some conditions, but
      some callers (such as open, ethtool) have already taken RTNL.  These
      3 patches fix the issue by making it clear that callers must take
      RTNL.  If the caller is bnxt_sp_task() which does not automatically
      take RTNL, we add a common scheme for bnxt_sp_task() to call these
      functions properly under RTNL.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0d9665f
    • 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
    • Jason Baron's avatar
      tcp: correct memory barrier usage in tcp_check_space() · 56d80622
      Jason Baron authored
      sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit().
      Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient.
      
      Fixes: 3c715127 ("tcp: add memory barriers to write space paths")
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56d80622
    • Xin Long's avatar
      sctp: sctp gso should set feature with NETIF_F_SG when calling skb_segment · 5207f399
      Xin Long authored
      Now sctp gso puts segments into skb's frag_list, then processes these
      segments in skb_segment. But skb_segment handles them only when gs is
      enabled, as it's in the same branch with skb's frags.
      
      Although almost all the NICs support sg other than some old ones, but
      since commit 1e16aa3d ("net: gso: use feature flag argument in all
      protocol gso handlers"), features &= skb->dev->hw_enc_features, and
      xfrm_output_gso call skb_segment with features = 0, which means sctp
      gso would call skb_segment with sg = 0, and skb_segment would not work
      as expected.
      
      This patch is to fix it by setting features param with NETIF_F_SG when
      calling skb_segment so that it can go the right branch to process the
      skb's frag_list.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5207f399
    • Xin Long's avatar
      sctp: sctp_addr_id2transport should verify the addr before looking up assoc · 6f29a130
      Xin Long authored
      sctp_addr_id2transport is a function for sockopt to look up assoc by
      address. As the address is from userspace, it can be a v4-mapped v6
      address. But in sctp protocol stack, it always handles a v4-mapped
      v6 address as a v4 address. So it's necessary to convert it to a v4
      address before looking up assoc by address.
      
      This patch is to fix it by calling sctp_verify_addr in which it can do
      this conversion before calling sctp_endpoint_lookup_assoc, just like
      what sctp_sendmsg and __sctp_connect do for the address from users.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f29a130
  2. 24 Jan, 2017 29 commits