1. 26 10月, 2011 3 次提交
  2. 20 10月, 2011 1 次提交
  3. 19 10月, 2011 4 次提交
  4. 18 10月, 2011 3 次提交
  5. 13 10月, 2011 1 次提交
  6. 11 10月, 2011 1 次提交
  7. 07 10月, 2011 1 次提交
  8. 06 10月, 2011 1 次提交
  9. 05 10月, 2011 2 次提交
    • Y
      tcp: properly update lost_cnt_hint during shifting · 1e5289e1
      Yan, Zheng 提交于
      lost_skb_hint is used by tcp_mark_head_lost() to mark the first unhandled skb.
      lost_cnt_hint is the number of packets or sacked packets before the lost_skb_hint;
      When shifting a skb that is before the lost_skb_hint, if tcp_is_fack() is ture,
      the skb has already been counted in the lost_cnt_hint; if tcp_is_fack() is false,
      tcp_sacktag_one() will increase the lost_cnt_hint. So tcp_shifted_skb() does not
      need to adjust the lost_cnt_hint by itself. When shifting a skb that is equal to
      lost_skb_hint, the shifted packets will not be counted by tcp_mark_head_lost().
      So tcp_shifted_skb() should adjust the lost_cnt_hint even tcp_is_fack(tp) is true.
      Signed-off-by: NZheng Yan <zheng.z.yan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e5289e1
    • Y
      tcp: properly handle md5sig_pool references · 260fcbeb
      Yan, Zheng 提交于
      tcp_v4_clear_md5_list() assumes that multiple tcp md5sig peers
      only hold one reference to md5sig_pool. but tcp_v4_md5_do_add()
      increases use count of md5sig_pool for each peer. This patch
      makes tcp_v4_md5_do_add() only increases use count for the first
      tcp md5sig peer.
      Signed-off-by: NZheng Yan <zheng.z.yan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      260fcbeb
  10. 04 10月, 2011 1 次提交
    • W
      make PACKET_STATISTICS getsockopt report consistently between ring and non-ring · 7091fbd8
      Willem de Bruijn 提交于
      This is a minor change.
      
      Up until kernel 2.6.32, getsockopt(fd, SOL_PACKET, PACKET_STATISTICS,
      ...) would return total and dropped packets since its last invocation. The
      introduction of socket queue overflow reporting [1] changed drop
      rate calculation in the normal packet socket path, but not when using a
      packet ring. As a result, the getsockopt now returns different statistics
      depending on the reception method used. With a ring, it still returns the
      count since the last call, as counts are incremented in tpacket_rcv and
      reset in getsockopt. Without a ring, it returns 0 if no drops occurred
      since the last getsockopt and the total drops over the lifespan of
      the socket otherwise. The culprit is this line in packet_rcv, executed
      on a drop:
      
      drop_n_acct:
              po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);
      
      As it shows, the new drop number it taken from the socket drop counter,
      which is not reset at getsockopt. I put together a small example
      that demonstrates the issue [2]. It runs for 10 seconds and overflows
      the queue/ring on every odd second. The reported drop rates are:
      ring: 16, 0, 16, 0, 16, ...
      non-ring: 0, 15, 0, 30, 0, 46, 0, 60, 0 , 74.
      
      Note how the even ring counts monotonically increase. Because the
      getsockopt adds tp_drops to tp_packets, total counts are similarly
      reported cumulatively. Long story short, reinstating the original code, as
      the below patch does, fixes the issue at the cost of additional per-packet
      cycles. Another solution that does not introduce per-packet overhead
      is be to keep the current data path, record the value of sk_drops at
      getsockopt() at call N in a new field in struct packetsock and subtract
      that when reporting at call N+1. I'll be happy to code that, instead,
      it's just more messy.
      
      [1] http://patchwork.ozlabs.org/patch/35665/
      [2] http://kernel.googlecode.com/files/test-packetsock-getstatistics.cSigned-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7091fbd8
  11. 03 10月, 2011 1 次提交
  12. 30 9月, 2011 2 次提交
  13. 29 9月, 2011 4 次提交
    • Y
      ipv6: nullify ipv6_ac_list and ipv6_fl_list when creating new socket · 676a1184
      Yan, Zheng 提交于
      ipv6_ac_list and ipv6_fl_list from listening socket are inadvertently
      shared with new socket created for connection.
      Signed-off-by: NZheng Yan <zheng.z.yan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676a1184
    • O
      can bcm: fix tx_setup off-by-one errors · aabdcb0b
      Oliver Hartkopp 提交于
      This patch fixes two off-by-one errors that canceled each other out.
      Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
      the count of frames to be sent by one. This did not show up the first time
      tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
      Invoking a second tx_setup on the same item led to a reduced (by 1) number of
      sent frames.
      Reported-by: NAndre Naujoks <nautsch@gmail.com>
      Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aabdcb0b
    • S
      libceph: fix pg_temp mapping update · 8adc8b3d
      Sage Weil 提交于
      The incremental map updates have a record for each pg_temp mapping that is
      to be add/updated (len > 0) or removed (len == 0).  The old code was
      written as if the updates were a complete enumeration; that was just wrong.
      Update the code to remove 0-length entries and drop the rbtree traversal.
      
      This avoids misdirected (and hung) requests that manifest as server
      errors like
      
      [WRN] client4104 10.0.1.219:0/275025290 misdirected client4104.1:129 0.1 to osd0 not [1,0] in e11/11
      Signed-off-by: NSage Weil <sage@newdream.net>
      8adc8b3d
    • S
      libceph: fix pg_temp mapping calculation · 782e182e
      Sage Weil 提交于
      We need to apply the modulo pg_num calculation before looking up a pgid in
      the pg_temp mapping rbtree.  This fixes pg_temp mappings, and fixes
      (some) misdirected requests that result in messages like
      
      [WRN] client4104 10.0.1.219:0/275025290 misdirected client4104.1:129 0.1 to osd0 not [1,0] in e11/11
      
      on the server and stall make the client block without getting a reply (at
      least until the pg_temp mapping goes way, but that can take a long long
      time).
      
      Reorder calc_pg_raw() a bit to make more sense.
      Signed-off-by: NSage Weil <sage@newdream.net>
      782e182e
  14. 28 9月, 2011 4 次提交
  15. 23 9月, 2011 1 次提交
  16. 22 9月, 2011 3 次提交
  17. 21 9月, 2011 1 次提交
  18. 19 9月, 2011 1 次提交
  19. 17 9月, 2011 5 次提交