1. 27 2月, 2013 2 次提交
  2. 26 2月, 2013 6 次提交
  3. 20 2月, 2013 4 次提交
  4. 19 2月, 2013 13 次提交
  5. 14 2月, 2013 7 次提交
  6. 13 2月, 2013 2 次提交
    • J
      htb: fix values in opt dump · 9c10f411
      Jiri Pirko 提交于
      in htb_change_class() cl->buffer and cl->buffer are stored in ns.
      So in dump, convert them back to psched ticks.
      
      Note this was introduced by:
      commit 56b765b7
          htb: improved accuracy at high rates
      
      Please consider this for -net/-stable.
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c10f411
    • E
      net: fix infinite loop in __skb_recv_datagram() · 77c1090f
      Eric Dumazet 提交于
      Tommi was fuzzing with trinity and reported the following problem :
      
      commit 3f518bf7 (datagram: Add offset argument to __skb_recv_datagram)
      missed that a raw socket receive queue can contain skbs with no payload.
      
      We can loop in __skb_recv_datagram() with MSG_PEEK mode, because
      wait_for_packet() is not prepared to skip these skbs.
      
      [   83.541011] INFO: rcu_sched detected stalls on CPUs/tasks: {}
      (detected by 0, t=26002 jiffies, g=27673, c=27672, q=75)
      [   83.541011] INFO: Stall ended before state dump start
      [  108.067010] BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child31:2847]
      ...
      [  108.067010] Call Trace:
      [  108.067010]  [<ffffffff818cc103>] __skb_recv_datagram+0x1a3/0x3b0
      [  108.067010]  [<ffffffff818cc33d>] skb_recv_datagram+0x2d/0x30
      [  108.067010]  [<ffffffff819ed43d>] rawv6_recvmsg+0xad/0x240
      [  108.067010]  [<ffffffff818c4b04>] sock_common_recvmsg+0x34/0x50
      [  108.067010]  [<ffffffff818bc8ec>] sock_recvmsg+0xbc/0xf0
      [  108.067010]  [<ffffffff818bf31e>] sys_recvfrom+0xde/0x150
      [  108.067010]  [<ffffffff81ca4329>] system_call_fastpath+0x16/0x1b
      Reported-by: NTommi Rantala <tt.rantala@gmail.com>
      Tested-by: NTommi Rantala <tt.rantala@gmail.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Acked-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77c1090f
  7. 12 2月, 2013 1 次提交
  8. 11 2月, 2013 2 次提交
  9. 09 2月, 2013 2 次提交
  10. 08 2月, 2013 1 次提交
    • E
      l2tp: dont play with skb->truesize · 87c084a9
      Eric Dumazet 提交于
      Andrew Savchenko reported a DNS failure and we diagnosed that
      some UDP sockets were unable to send more packets because their
      sk_wmem_alloc was corrupted after a while (tx_queue column in
      following trace)
      
      $ cat /proc/net/udp
        sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
      ...
        459: 00000000:0270 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4507 2 ffff88003d612380 0
        466: 00000000:0277 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4802 2 ffff88003d613180 0
        470: 076A070A:007B 00000000:0000 07 FFFF4600:00000000 00:00000000 00000000   123        0 5552 2 ffff880039974380 0
        470: 010213AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4986 2 ffff88003dbd3180 0
        470: 010013AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4985 2 ffff88003dbd2e00 0
        470: 00FCA8C0:007B 00000000:0000 07 FFFFFB00:00000000 00:00000000 00000000     0        0 4984 2 ffff88003dbd2a80 0
      ...
      
      Playing with skb->truesize is tricky, especially when
      skb is attached to a socket, as we can fool memory charging.
      
      Just remove this code, its not worth trying to be ultra
      precise in xmit path.
      Reported-by: NAndrew Savchenko <bircoph@gmail.com>
      Tested-by: NAndrew Savchenko <bircoph@gmail.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: James Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87c084a9