1. 02 1月, 2017 7 次提交
  2. 31 12月, 2016 2 次提交
  3. 30 12月, 2016 19 次提交
  4. 29 12月, 2016 2 次提交
  5. 28 12月, 2016 2 次提交
  6. 27 12月, 2016 1 次提交
  7. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  8. 25 12月, 2016 3 次提交
  9. 24 12月, 2016 3 次提交
    • T
      net/mlx4_en: Fix user prio field in XDP forward · eb9def61
      Tariq Toukan 提交于
      The user prio field is wrong (and overflows) in the XDP forward
      flow.
      This is a result of a bad value for num_tx_rings_p_up, which should
      account all XDP TX rings, as they operate for the same user prio.
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Reported-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb9def61
    • M
      ipvlan: fix multicast processing · e2525360
      Mahesh Bandewar 提交于
      In an IPvlan setup when master is set in loopback mode e.g.
      
        ethtool -K eth0 set loopback on
      
        where eth0 is master device for IPvlan setup.
      
      The failure is caused by the faulty logic that determines if the
      packet is from TX-path vs. RX-path by just looking at the mac-
      addresses on the packet while processing multicast packets.
      
      In the loopback-mode where this crash was happening, the packets
      that are sent out are reflected by the NIC and are processed on
      the RX path, but mac-address check tricks into thinking this
      packet is from TX path and falsely uses dev_forward_skb() to pass
      packets to the slave (virtual) devices.
      
      This patch records the path while queueing packets and eliminates
      logic of looking at mac-addresses for the same decision.
      
      ------------[ cut here ]------------
      kernel BUG at include/linux/skbuff.h:1737!
      Call Trace:
       [<ffffffff921fbbc2>] dev_forward_skb+0x92/0xd0
       [<ffffffffc031ac65>] ipvlan_process_multicast+0x395/0x4c0 [ipvlan]
       [<ffffffffc031a9a7>] ? ipvlan_process_multicast+0xd7/0x4c0 [ipvlan]
       [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
       [<ffffffff91cdff09>] process_one_work+0x1a9/0x660
       [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
       [<ffffffff91ce086d>] worker_thread+0x11d/0x360
       [<ffffffff91ce0750>] ? rescuer_thread+0x350/0x350
       [<ffffffff91ce960b>] kthread+0xdb/0xe0
       [<ffffffff91c05c70>] ? _raw_spin_unlock_irq+0x30/0x50
       [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
       [<ffffffff92348b7a>] ret_from_fork+0x9a/0xd0
       [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
      
      Fixes: ba35f858 ("ipvlan: Defer multicast / broadcast processing to a work-queue")
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      CC: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e2525360
    • E
      ipvlan: fix various issues in ipvlan_process_multicast() · b1227d01
      Eric Dumazet 提交于
      1) netif_rx() / dev_forward_skb() should not be called from process
      context.
      
      2) ipvlan_count_rx() should be called with preemption disabled.
      
      3) We should check if ipvlan->dev is up before feeding packets
      to netif_rx()
      
      4) We need to prevent device from disappearing if some packets
      are in the multicast backlog.
      
      5) One kfree_skb() should be a consume_skb() eventually
      
      Fixes: ba35f858 ("ipvlan: Defer multicast / broadcast processing to
      a work-queue")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1227d01