1. 28 Aug, 2016 12 commits
  2. 26 Aug, 2016 5 commits
  3. 25 Aug, 2016 8 commits
  4. 24 Aug, 2016 6 commits
    • Yotam Gigi's avatar
      mlxsw: router: Enable neighbors to be created on stacked devices · 51af96b5
      Yotam Gigi authored
      Make the function mlxsw_router_neigh_construct search the rif according
      to the neighbour dev other than the dev that was passed to the ndo, thus
      allowing creating neigbhours upon stacked devices.
      
      Fixes: 6cf3c971
      
       ("mlxsw: spectrum_router: Add private neigh table")
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51af96b5
    • Ido Schimmel's avatar
      mlxsw: spectrum: Add missing flood to router port · f888f587
      Ido Schimmel authored
      In case we have a layer 3 interface on top of a bridge (VLAN / FID RIF),
      then we should flood the following packet types to the router:
      
      * Broadcast: If DIP is the broadcast address of the interface, then we
      need to be able to get it to CPU by trapping it following route lookup.
      
      * Reserved IP multicast (224.0.0.X): Some control packets (e.g. OSPF)
      use this range and are trapped in the router block.
      
      Fixes: 99f44bb3
      
       ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f888f587
    • Daniel Borkmann's avatar
      Bluetooth: split sk_filter in l2cap_sock_recv_cb · dbb50887
      Daniel Borkmann authored
      During an audit for sk_filter(), we found that rx_busy_skb handling
      in l2cap_sock_recv_cb() and l2cap_sock_recvmsg() looks not quite as
      intended.
      
      The assumption from commit e328140f ("Bluetooth: Use event-driven
      approach for handling ERTM receive buffer") is that errors returned
      from sock_queue_rcv_skb() are due to receive buffer shortage. However,
      nothing should prevent doing a setsockopt() with SO_ATTACH_FILTER on
      the socket, that could drop some of the incoming skbs when handled in
      sock_queue_rcv_skb().
      
      In that case sock_queue_rcv_skb() will return with -EPERM, propagated
      from sk_filter() and if in L2CAP_MODE_ERTM mode, wrong assumption was
      that we failed due to receive buffer being full. From that point onwards,
      due to the to-be-dropped skb being held in rx_busy_skb, we cannot make
      any forward progress as rx_busy_skb is never cleared from l2cap_sock_recvmsg(),
      due to the filter drop verdict over and over coming from sk_filter().
      Meanwhile, in l2cap_sock_recv_cb() all new incoming skbs are being
      dropped due to rx_busy_skb being occupied.
      
      Instead, just use __sock_queue_rcv_skb() where an error really tells that
      there's a receive buffer issue. Split the sk_filter() and enable it for
      non-segmented modes at queuing time since at this point in time the skb has
      already been through the ERTM state machine and it has been acked, so dropping
      is not allowed. Instead, for ERTM and streaming mode, call sk_filter() in
      l2cap_data_rcv() so the packet can be dropped before the state machine sees it.
      
      Fixes: e328140f
      
       ("Bluetooth: Use event-driven approach for handling ERTM receive buffer")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      dbb50887
    • Frederic Dalleau's avatar
      Bluetooth: Fix memory leak at end of hci requests · 9afee949
      Frederic Dalleau authored
      
      
      In hci_req_sync_complete the event skb is referenced in hdev->req_skb.
      It is used (via hci_req_run_skb) from either __hci_cmd_sync_ev which will
      pass the skb to the caller, or __hci_req_sync which leaks.
      
      unreferenced object 0xffff880005339a00 (size 256):
        comm "kworker/u3:1", pid 1011, jiffies 4294671976 (age 107.389s)
        backtrace:
          [<ffffffff818d89d9>] kmemleak_alloc+0x49/0xa0
          [<ffffffff8116bba8>] kmem_cache_alloc+0x128/0x180
          [<ffffffff8167c1df>] skb_clone+0x4f/0xa0
          [<ffffffff817aa351>] hci_event_packet+0xc1/0x3290
          [<ffffffff8179a57b>] hci_rx_work+0x18b/0x360
          [<ffffffff810692ea>] process_one_work+0x14a/0x440
          [<ffffffff81069623>] worker_thread+0x43/0x4d0
          [<ffffffff8106ead4>] kthread+0xc4/0xe0
          [<ffffffff818dd38f>] ret_from_fork+0x1f/0x40
          [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: default avatarFrédéric Dalleau <frederic.dalleau@collabora.co.uk>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9afee949
    • David Ahern's avatar
      net: diag: Fix refcnt leak in error path destroying socket · d7226c7a
      David Ahern authored
      inet_diag_find_one_icsk takes a reference to a socket that is not
      released if sock_diag_destroy returns an error. Fix by changing
      tcp_diag_destroy to manage the refcnt for all cases and remove
      the sock_put calls from tcp_abort.
      
      Fixes: c1e64e29
      
       ("net: diag: Support destroying TCP sockets")
      Reported-by: default avatarLorenzo Colitti <lorenzo@google.com>
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7226c7a
    • Soheil Hassas Yeganeh's avatar
      tun: fix transmit timestamp support · 7b996243
      Soheil Hassas Yeganeh authored
      Instead of using sock_tx_timestamp, use skb_tx_timestamp to record
      software transmit timestamp of a packet.
      
      sock_tx_timestamp resets and overrides the tx_flags of the skb.
      The function is intended to be called from within the protocol
      layer when creating the skb, not from a device driver. This is
      inconsistent with other drivers and will cause issues for TCP.
      
      In TCP, we intend to sample the timestamps for the last byte
      for each sendmsg/sendpage. For that reason, tcp_sendmsg calls
      tcp_tx_timestamp only with the last skb that it generates.
      For example, if a 128KB message is split into two 64KB packets
      we want to sample the SND timestamp of the last packet. The current
      code in the tun driver, however, will result in sampling the SND
      timestamp for both packets.
      
      Also, when the last packet is split into smaller packets for
      retranmission (see tcp_fragment), the tun driver will record
      timestamps for all of the retransmitted packets and not only the
      last packet.
      
      Fixes: eda29772
      
       (tun: Support software transmit time stamping.)
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarFrancis Yan <francisyyan@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b996243
  5. 23 Aug, 2016 9 commits