Skip to content
Snippets Groups Projects
  1. Jul 04, 2009
  2. Jul 01, 2009
  3. Jun 30, 2009
  4. Jun 29, 2009
  5. Jun 27, 2009
  6. Jun 26, 2009
    • Wei Yongjun's avatar
      tcp: missing check ACK flag of received segment in FIN-WAIT-2 state · 1ac530b3
      Wei Yongjun authored
      
      RFC0793 defined that in FIN-WAIT-2 state if the ACK bit is off drop
      the segment and return[Page 72]. But this check is missing in function
      tcp_timewait_state_process(). This cause the segment with FIN flag but
      no ACK has two diffent action:
      
      Case 1:
          Node A                      Node B
                    <-------------    FIN,ACK
                                      (enter FIN-WAIT-1)
          ACK       ------------->
                                      (enter FIN-WAIT-2)
          FIN       ------------->    discard
                                      (move sk to tw list)
      
      Case 2:
          Node A                      Node B
                    <-------------    FIN,ACK
                                      (enter FIN-WAIT-1)
          ACK       ------------->
                                      (enter FIN-WAIT-2)
                                      (move sk to tw list)
          FIN       ------------->
      
                    <-------------    ACK
      
      This patch fixed the problem.
      
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ac530b3
  7. Jun 24, 2009
    • Neil Horman's avatar
      ipv4 routing: Ensure that route cache entries are usable and reclaimable with caching is off · b6280b47
      Neil Horman authored
      
      When route caching is disabled (rt_caching returns false), We still use route
      cache entries that are created and passed into rt_intern_hash once.  These
      routes need to be made usable for the one call path that holds a reference to
      them, and they need to be reclaimed when they're finished with their use.  To be
      made usable, they need to be associated with a neighbor table entry (which they
      currently are not), otherwise iproute_finish2 just discards the packet, since we
      don't know which L2 peer to send the packet to.  To do this binding, we need to
      follow the path a bit higher up in rt_intern_hash, which calls
      arp_bind_neighbour, but not assign the route entry to the hash table.
      Currently, if caching is off, we simply assign the route to the rp pointer and
      are reutrn success.  This patch associates us with a neighbor entry first.
      
      Secondly, we need to make sure that any single use routes like this are known to
      the garbage collector when caching is off.  If caching is off, and we try to
      hash in a route, it will leak when its refcount reaches zero.  To avoid this,
      this patch calls rt_free on the route cache entry passed into rt_intern_hash.
      This places us on the gc list for the route cache garbage collector, so that
      when its refcount reaches zero, it will be reclaimed (Thanks to Alexey for this
      suggestion).
      
      I've tested this on a local system here, and with these patches in place, I'm
      able to maintain routed connectivity to remote systems, even if I set
      /proc/sys/net/ipv4/rt_cache_rebuild_count to -1, which forces rt_caching to
      return false.
      
      Signed-off-by: default avatarNeil Horman <nhorman@redhat.com>
      Reported-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Reported-by: default avatarMaxime Bizon <mbizon@freebox.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6280b47
  8. Jun 20, 2009
    • Neil Horman's avatar
      ipv4: fix NULL pointer + success return in route lookup path · 73e42897
      Neil Horman authored
      
      Don't drop route if we're not caching	
      
      	I recently got a report of an oops on a route lookup.  Maxime was
      testing what would happen if route caching was turned off (doing so by setting
      making rt_caching always return 0), and found that it triggered an oops.  I
      looked at it and found that the problem stemmed from the fact that the route
      lookup routines were returning success from their lookup paths (which is good),
      but never set the **rp pointer to anything (which is bad).  This happens because
      in rt_intern_hash, if rt_caching returns false, we call rt_drop and return 0.
      This almost emulates slient success.  What we should be doing is assigning *rp =
      rt and _not_ dropping the route.  This way, during slow path lookups, when we
      create a new route cache entry, we don't immediately discard it, rather we just
      don't add it into the cache hash table, but we let this one lookup use it for
      the purpose of this route request.  Maxime has tested and reports it prevents
      the oops.  There is still a subsequent routing issue that I'm looking into
      further, but I'm confident that, even if its related to this same path, this
      patch makes sense to take.
      
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73e42897
  9. Jun 18, 2009
  10. Jun 15, 2009
  11. Jun 14, 2009
  12. Jun 12, 2009
    • Patrick McHardy's avatar
      netfilter: ip_tables: fix build error · 24992eac
      Patrick McHardy authored
      
      Fix build error introduced by commit bb70dfa5 (netfilter: xtables:
      consolidate comefrom debug cast access):
      
      net/ipv4/netfilter/ip_tables.c: In function 'ipt_do_table':
      net/ipv4/netfilter/ip_tables.c:421: error: 'comefrom' undeclared (first use in this function)
      net/ipv4/netfilter/ip_tables.c:421: error: (Each undeclared identifier is reported only once
      net/ipv4/netfilter/ip_tables.c:421: error: for each function it appears in.)
      
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      24992eac
  13. Jun 11, 2009
    • Eric Dumazet's avatar
      net: No more expensive sock_hold()/sock_put() on each tx · 2b85a34e
      Eric Dumazet authored
      
      One of the problem with sock memory accounting is it uses
      a pair of sock_hold()/sock_put() for each transmitted packet.
      
      This slows down bidirectional flows because the receive path
      also needs to take a refcount on socket and might use a different
      cpu than transmit path or transmit completion path. So these
      two atomic operations also trigger cache line bounces.
      
      We can see this in tx or tx/rx workloads (media gateways for example),
      where sock_wfree() can be in top five functions in profiles.
      
      We use this sock_hold()/sock_put() so that sock freeing
      is delayed until all tx packets are completed.
      
      As we also update sk_wmem_alloc, we could offset sk_wmem_alloc
      by one unit at init time, until sk_free() is called.
      Once sk_free() is called, we atomic_dec_and_test(sk_wmem_alloc)
      to decrement initial offset and atomicaly check if any packets
      are in flight.
      
      skb_set_owner_w() doesnt call sock_hold() anymore
      
      sock_wfree() doesnt call sock_put() anymore, but check if sk_wmem_alloc
      reached 0 to perform the final freeing.
      
      Drawback is that a skb->truesize error could lead to unfreeable sockets, or
      even worse, prematurely calling __sk_free() on a live socket.
      
      Nice speedups on SMP. tbench for example, going from 2691 MB/s to 2711 MB/s
      on my 8 cpu dev machine, even if tbench was not really hitting sk_refcnt
      contention point. 5 % speedup on a UDP transmit workload (depends
      on number of flows), lowering TX completion cpu usage.
      
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b85a34e
  14. Jun 10, 2009
  15. Jun 09, 2009
  16. Jun 08, 2009
    • Jan Kasprzak's avatar
      netfilter: nf_ct_icmp: keep the ICMP ct entries longer · f87fb666
      Jan Kasprzak authored
      
      Current conntrack code kills the ICMP conntrack entry as soon as
      the first reply is received. This is incorrect, as we then see only
      the first ICMP echo reply out of several possible duplicates as
      ESTABLISHED, while the rest will be INVALID. Also this unnecessarily
      increases the conntrackd traffic on H-A firewalls.
      
      Make all the ICMP conntrack entries (including the replied ones)
      last for the default of nf_conntrack_icmp{,v6}_timeout seconds.
      
      Signed-off-by: default avatarJan "Yenya" Kasprzak <kas@fi.muni.cz>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      f87fb666
  17. Jun 05, 2009
  18. Jun 04, 2009
  19. Jun 03, 2009
  20. Jun 02, 2009
    • Pablo Neira Ayuso's avatar
      netfilter: conntrack: simplify event caching system · 17e6e4ea
      Pablo Neira Ayuso authored
      
      This patch simplifies the conntrack event caching system by removing
      several events:
      
       * IPCT_[*]_VOLATILE, IPCT_HELPINFO and IPCT_NATINFO has been deleted
         since the have no clients.
       * IPCT_COUNTER_FILLING which is a leftover of the 32-bits counter
         days.
       * IPCT_REFRESH which is not of any use since we always include the
         timeout in the messages.
      
      After this patch, the existing events are:
      
       * IPCT_NEW, IPCT_RELATED and IPCT_DESTROY, that are used to identify
       addition and deletion of entries.
       * IPCT_STATUS, that notes that the status bits have changes,
       eg. IPS_SEEN_REPLY and IPS_ASSURED.
       * IPCT_PROTOINFO, that reports that internal protocol information has
       changed, eg. the TCP, DCCP and SCTP protocol state.
       * IPCT_HELPER, that a helper has been assigned or unassigned to this
       entry.
       * IPCT_MARK and IPCT_SECMARK, that reports that the mark has changed, this
       covers the case when a mark is set to zero.
       * IPCT_NATSEQADJ, to report that there's updates in the NAT sequence
       adjustment.
      
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      17e6e4ea
    • Nivedita Singhvi's avatar
      ipv4: New multicast-all socket option · f771bef9
      Nivedita Singhvi authored
      
      After some discussion offline with Christoph Lameter and David Stevens
      regarding multicast behaviour in Linux, I'm submitting a slightly
      modified patch from the one Christoph submitted earlier.
      
      This patch provides a new socket option IP_MULTICAST_ALL.
      
      In this case, default behaviour is _unchanged_ from the current
      Linux standard. The socket option is set by default to provide
      original behaviour. Sockets wishing to receive data only from
      multicast groups they join explicitly will need to clear this
      socket option.
      
      Signed-off-by: default avatarNivedita Singhvi <niv@us.ibm.com>
      Signed-off-by: default avatarChristoph <Lameter&lt;cl@linux.com>
      Acked-by: default avatarDavid Stevens <dlstevens@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f771bef9
    • Eric Dumazet's avatar
      net: ipv4/ip_sockglue.c cleanups · 4d52cfbe
      Eric Dumazet authored
      
      Pure cleanups
      
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4d52cfbe
  21. May 30, 2009
    • Ilpo Järvinen's avatar
      tcp: fix loop in ofo handling code and reduce its complexity · 2df9001e
      Ilpo Järvinen authored
      
      Somewhat luckily, I was looking into these parts with very fine
      comb because I've made somewhat similar changes on the same
      area (conflicts that arose weren't that lucky though). The loop
      was very much overengineered recently in commit 91521944
      (tcp: Use SKB queue and list helpers instead of doing it
      by-hand), while it basically just wants to know if there are
      skbs after 'skb'.
      
      Also it got broken because skb1 = skb->next got translated into
      skb1 = skb1->next (though abstracted) improperly. Note that
      'skb1' is pointing to previous sk_buff than skb or NULL if at
      head. Two things went wrong:
      - We'll kfree 'skb' on the first iteration instead of the
        skbuff following 'skb' (it would require required SACK reneging
        to recover I think).
      - The list head case where 'skb1' is NULL is checked too early
        and the loop won't execute whereas it previously did.
      
      Conclusion, mostly revert the recent changes which makes the
      cset very messy looking but using proper accessor in the
      previous-like version.
      
      The effective changes against the original can be viewed with:
        git-diff 91521944^ \
      		net/ipv4/tcp_input.c | sed -n -e '57,70 p'
      
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2df9001e
  22. May 29, 2009
  23. May 27, 2009
Loading