1. 17 Nov, 2015 9 commits
    • Andrew Lunn's avatar
      phy: marvell: Add support for 88E1540 PHY · 819ec8e1
      Andrew Lunn authored
      The 88E1540 can be found embedded in the Marvell 88E6352 switch.  It
      is compatible with the 88E1510, so add support for it, using the
      88E1510 specific functions.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      819ec8e1
    • Yang Shi's avatar
      arm64: bpf: make BPF prologue and epilogue align with ARM64 AAPCS · ec0738db
      Yang Shi authored
      Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
      in prologue in order to get the correct stack backtrace.
      
      However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
      change during function call so it may cause the BPF prog stack base address
      change too.
      
      Use x25 to replace FP as BPF stack base register (fp). Since x25 is callee
      saved register, so it will keep intact during function call.
      It is initialized in BPF prog prologue when BPF prog is started to run
      everytime. Save and restore x25/x26 in BPF prologue and epilogue to keep
      them intact for the outside of BPF. Actually, x26 is unnecessary, but SP
      requires 16 bytes alignment.
      
      So, the BPF stack layout looks like:
      
                                       high
               original A64_SP =>   0:+-----+ BPF prologue
                                      |FP/LR|
               current A64_FP =>  -16:+-----+
                                      | ... | callee saved registers
                                      +-----+
                                      |     | x25/x26
               BPF fp register => -80:+-----+
                                      |     |
                                      | ... | BPF prog stack
                                      |     |
                                      |     |
               current A64_SP =>      +-----+
                                      |     |
                                      | ... | Function call stack
                                      |     |
                                      +-----+
                                        low
      
      CC: Zi Shen Lim <zlim.lnx@gmail.com>
      CC: Xi Wang <xi.wang@gmail.com>
      Signed-off-by: default avatarYang Shi <yang.shi@linaro.org>
      Acked-by: default avatarZi Shen Lim <zlim.lnx@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec0738db
    • Sabrina Dubroca's avatar
      macvlan: fix leak in macvlan_handle_frame · e639b8d8
      Sabrina Dubroca authored
      Reset pskb in macvlan_handle_frame in case skb_share_check returned a
      clone.
      
      Fixes: 8a4eb573 ("net: introduce rx_handler results and logic around that")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e639b8d8
    • Sabrina Dubroca's avatar
      ipvlan: fix use after free of skb · a534dc52
      Sabrina Dubroca authored
      ipvlan_handle_frame is a rx_handler, and when it returns a value other
      than RX_HANDLER_CONSUMED (here, NET_RX_DROP aka RX_HANDLER_ANOTHER),
      __netif_receive_skb_core expects that the skb still exists and will
      process it further, but we just freed it.
      
      Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a534dc52
    • Sabrina Dubroca's avatar
      ipvlan: fix leak in ipvlan_rcv_frame · cf554ada
      Sabrina Dubroca authored
      Pass a **skb to ipvlan_rcv_frame so that if skb_share_check returns a
      new skb, we actually use it during further processing.
      
      It's safe to ignore the new skb in the ipvlan_xmit_* functions, because
      they call ipvlan_rcv_frame with local == true, so that dev_forward_skb
      is called and always takes ownership of the skb.
      
      Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf554ada
    • David S. Miller's avatar
      Merge branch 'vlan-reorder' · eb3f8b42
      David S. Miller authored
      Vladislav Yasevich says:
      
      ====================
      Fix issues with vlans without REORDER_HEADER
      
      A while ago Phil Sutter brought up an issue with vlans without
      REORDER_HEADER and bridges.  The problem was that if a vlan
      without REORDER_HEADER was a port in the bridge, the bridge ended
      up forwarding corrupted packets that still contained the vlan header.
      The same issue exists for bridge mode macvlan/macvtap devices.
      
      An additional issue with vlans without REORDER_HEADER is that stacking
      them also doesn't work.  The reason here is that skb_reorder_vlan_header()
      function assumes that it on ETH_HLEN bytes deep into the packet.  That
      is not the case, when you a vlan without REORRDER_HEADER flag set.
      
      This series attempts to correct these 2 issues.
      
      1) To solve the stacked vlans problem, the patch simply use
      skb->mac_len as an offset to start copying mac addresses that
      is part of header reordering.
      
      2) To fix the issue with bridge/macvlan/macvtap, the second patch
      simply doesn't write the vlan header back to the packet if the
      vlan device is either a bridge or a macvlan port.  This ends up
      being the simplest and least performance intrussive solution.
      
      I've considered extending patch 2 to all stacked devices (essentially
      checked for the presense of rx_handler), but that feels like a broader
      restriction and _may_ break existing uses.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb3f8b42
    • Vlad Yasevich's avatar
      vlan: Do not put vlan headers back on bridge and macvlan ports · 28f9ee22
      Vlad Yasevich authored
      When a vlan is configured with REORDER_HEADER set to 0, the vlan
      header is put back into the packet and makes it appear that
      the vlan header is still there even after it's been processed.
      This posses a problem for bridge and macvlan ports.  The packets
      passed to those device may be forwarded and at the time of the
      forward, vlan headers end up being unexpectedly present.
      
      With the patch, we make sure that we do not put the vlan header
      back (when REORDER_HEADER is 0) if a bridge or macvlan has
      been configured on top of the vlan device.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28f9ee22
    • Vlad Yasevich's avatar
      vlan: Fix untag operations of stacked vlans with REORDER_HEADER off · a6e18ff1
      Vlad Yasevich authored
      When we have multiple stacked vlan devices all of which have
      turned off REORDER_HEADER flag, the untag operation does not
      locate the ethernet addresses correctly for nested vlans.
      The reason is that in case of REORDER_HEADER flag being off,
      the outer vlan headers are put back and the mac_len is adjusted
      to account for the presense of the header.  Then, the subsequent
      untag operation, for the next level vlan, always use VLAN_ETH_HLEN
      to locate the begining of the ethernet header and that ends up
      being a multiple of 4 bytes short of the actuall beginning
      of the mac header (the multiple depending on the how many vlan
      encapsulations ethere are).
      
      As a reslult, if there are multiple levles of vlan devices
      with REODER_HEADER being off, the recevied packets end up
      being dropped.
      
      To solve this, we use skb->mac_len as the offset.  The value
      is always set on receive path and starts out as a ETH_HLEN.
      The value is also updated when the vlan header manupations occur
      so we know it will be correct.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6e18ff1
    • Timo Teräs's avatar
      via-velocity: unconditionally drop frames with bad l2 length · 6c606fa3
      Timo Teräs authored
      By default the driver allowed incorrect frames to be received. What is
      worse the code does not handle very short frames correctly. The FCS
      length is unconditionally subtracted, and the underflow can cause
      skb_put to be called with large number after implicit cast to unsigned.
      And indeed, an skb_over_panic() was observed with via-velocity.
      
      This removes the module parameter as it does not work in it's
      current state, and should be implemented via NETIF_F_RXALL if needed.
      Suggested-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c606fa3
  2. 16 Nov, 2015 31 commits