1. 08 1月, 2012 2 次提交
  2. 05 1月, 2012 2 次提交
  3. 31 12月, 2011 1 次提交
  4. 29 12月, 2011 1 次提交
  5. 25 12月, 2011 1 次提交
  6. 23 12月, 2011 2 次提交
  7. 22 12月, 2011 1 次提交
  8. 20 12月, 2011 1 次提交
  9. 17 12月, 2011 6 次提交
  10. 14 12月, 2011 2 次提交
  11. 13 12月, 2011 3 次提交
  12. 12 12月, 2011 1 次提交
  13. 10 12月, 2011 1 次提交
  14. 09 12月, 2011 2 次提交
  15. 07 12月, 2011 3 次提交
  16. 06 12月, 2011 2 次提交
  17. 05 12月, 2011 1 次提交
    • E
      tcp: take care of misalignments · 117632e6
      Eric Dumazet 提交于
      We discovered that TCP stack could retransmit misaligned skbs if a
      malicious peer acknowledged sub MSS frame. This currently can happen
      only if output interface is non SG enabled : If SG is enabled, tcp
      builds headless skbs (all payload is included in fragments), so the tcp
      trimming process only removes parts of skb fragments, header stay
      aligned.
      
      Some arches cant handle misalignments, so force a head reallocation and
      shrink headroom to MAX_TCP_HEADER.
      
      Dont care about misaligments on x86 and PPC (or other arches setting
      NET_IP_ALIGN to 0)
      
      This patch introduces __pskb_copy() which can specify the headroom of
      new head, and pskb_copy() becomes a wrapper on top of __pskb_copy()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      117632e6
  18. 02 12月, 2011 1 次提交
  19. 01 12月, 2011 4 次提交
  20. 30 11月, 2011 3 次提交
    • I
      net: Fix skb_update_prio RCU usage. · 6977a79d
      Igor Maravic 提交于
      Change function rcu_dereference to rcu_dereference_bh to avoid warning
      
      [ INFO: suspicious RCU usage. ]
      -------------------------------
      net/core/dev.c:2459 suspicious rcu_dereference_check() usage!
      
      because we are locking with
      
      rcu_read_lock_bh();
      
      in function dev_queue_xmit(struct sk_buff *skb)
      Signed-off-by: NIgor Maravic <igorm@etf.rs>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6977a79d
    • E
      flow_dissector: use a 64bit load/store · 4d77d2b5
      Eric Dumazet 提交于
      Le lundi 28 novembre 2011 à 19:06 -0500, David Miller a écrit :
      > From: Dimitris Michailidis <dm@chelsio.com>
      > Date: Mon, 28 Nov 2011 08:25:39 -0800
      >
      > >> +bool skb_flow_dissect(const struct sk_buff *skb, struct flow_keys
      > >> *flow)
      > >> +{
      > >> +	int poff, nhoff = skb_network_offset(skb);
      > >> +	u8 ip_proto;
      > >> +	u16 proto = skb->protocol;
      > >
      > > __be16 instead of u16 for proto?
      >
      > I'll take care of this when I apply these patches.
      
      ( CC trimmed )
      
      Thanks David !
      
      Here is a small patch to use one 64bit load/store on x86_64 instead of
      two 32bit load/stores.
      
      [PATCH net-next] flow_dissector: use a 64bit load/store
      
      gcc compiler is smart enough to use a single load/store if we
      memcpy(dptr, sptr, 8) on x86_64, regardless of
      CONFIG_CC_OPTIMIZE_FOR_SIZE
      
      In IP header, daddr immediately follows saddr, this wont change in the
      future. We only need to make sure our flow_keys (src,dst) fields wont
      break the rule.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d77d2b5
    • T
      bql: Byte queue limits · 114cf580
      Tom Herbert 提交于
      Networking stack support for byte queue limits, uses dynamic queue
      limits library.  Byte queue limits are maintained per transmit queue,
      and a dql structure has been added to netdev_queue structure for this
      purpose.
      
      Configuration of bql is in the tx-<n> sysfs directory for the queue
      under the byte_queue_limits directory.  Configuration includes:
      limit_min, bql minimum limit
      limit_max, bql maximum limit
      hold_time, bql slack hold time
      
      Also under the directory are:
      limit, current byte limit
      inflight, current number of bytes on the queue
      Signed-off-by: NTom Herbert <therbert@google.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      114cf580