1. 30 Jun, 2009 2 commits
  2. 29 Jun, 2009 8 commits
  3. 26 Jun, 2009 7 commits
  4. 25 Jun, 2009 5 commits
  5. 24 Jun, 2009 1 commit
  6. 23 Jun, 2009 3 commits
    • 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
      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>
    • Herbert Xu's avatar
      net: Move rx skb_orphan call to where needed · d55d87fd
      Herbert Xu authored
      In order to get the tun driver to account packets, we need to be
      able to receive packets with destructors set.  To be on the safe
      side, I added an skb_orphan call for all protocols by default since
      some of them (IP in particular) cannot handle receiving packets
      destructors properly.
      Now it seems that at least one protocol (CAN) expects to be able
      to pass skb->sk through the rx path without getting clobbered.
      So this patch attempts to fix this properly by moving the skb_orphan
      call to where it's actually needed.  In particular, I've added it
      to skb_set_owner_[rw] which is what most users of skb->destructor
      This is actually an improvement for tun too since it means that
      we only give back the amount charged to the socket when the skb
      is passed to another socket that will also be charged accordingly.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarOliver Hartkopp <olver@hartkopp.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Brian Haley's avatar
      ipv6: Use correct data types for ICMPv6 type and code · d5fdd6ba
      Brian Haley authored
      Change all the code that deals directly with ICMPv6 type and code
      values to use u8 instead of a signed int as that's the actual data
      Signed-off-by: default avatarBrian Haley <brian.haley@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  7. 22 Jun, 2009 7 commits
    • Patrick McHardy's avatar
      netfilter: xt_rateest: fix comparison with self · 4d900f9d
      Patrick McHardy authored
      As noticed by Trk Edwin <edwintorok@gmail.com>:
      Compiling the kernel with clang has shown this warning:
      net/netfilter/xt_rateest.c:69:16: warning: self-comparison always results in a
      constant value
                              ret &= pps2 == pps2;
      Looking at the code:
      if (info->flags & XT_RATEEST_MATCH_BPS)
                  ret &= bps1 == bps2;
              if (info->flags & XT_RATEEST_MATCH_PPS)
                  ret &= pps2 == pps2;
      Judging from the MATCH_BPS case it seems to be a typo, with the intention of
      comparing pps1 with pps2.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Jan Engelhardt's avatar
      netfilter: xt_quota: fix incomplete initialization · 6d62182f
      Jan Engelhardt authored
      Commit v2.6.29-rc5-872-gacc738fe
       ("xtables: avoid pointer to self")
      forgot to copy the initial quota value supplied by iptables into the
      private structure, thus counting from whatever was in the memory
      kmalloc returned.
      Signed-off-by: default avatarJan Engelhardt <jengelh@medozas.de>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Patrick McHardy's avatar
    • Patrick McHardy's avatar
      netfilter: fix some sparse endianess warnings · f9ffc312
      Patrick McHardy authored
      net/netfilter/xt_NFQUEUE.c:46:9: warning: incorrect type in assignment (different base types)
      net/netfilter/xt_NFQUEUE.c:46:9:    expected unsigned int [unsigned] [usertype] ipaddr
      net/netfilter/xt_NFQUEUE.c:46:9:    got restricted unsigned int
      net/netfilter/xt_NFQUEUE.c:68:10: warning: incorrect type in assignment (different base types)
      net/netfilter/xt_NFQUEUE.c:68:10:    expected unsigned int [unsigned] <noident>
      net/netfilter/xt_NFQUEUE.c:68:10:    got restricted unsigned int
      net/netfilter/xt_NFQUEUE.c:69:10: warning: incorrect type in assignment (different base types)
      net/netfilter/xt_NFQUEUE.c:69:10:    expected unsigned int [unsigned] <noident>
      net/netfilter/xt_NFQUEUE.c:69:10:    got restricted unsigned int
      net/netfilter/xt_NFQUEUE.c:70:10: warning: incorrect type in assignment (different base types)
      net/netfilter/xt_NFQUEUE.c:70:10:    expected unsigned int [unsigned] <noident>
      net/netfilter/xt_NFQUEUE.c:70:10:    got restricted unsigned int
      net/netfilter/xt_NFQUEUE.c:71:10: warning: incorrect type in assignment (different base types)
      net/netfilter/xt_NFQUEUE.c:71:10:    expected unsigned int [unsigned] <noident>
      net/netfilter/xt_NFQUEUE.c:71:10:    got restricted unsigned int
      net/netfilter/xt_cluster.c:20:55: warning: incorrect type in return expression (different base types)
      net/netfilter/xt_cluster.c:20:55:    expected unsigned int
      net/netfilter/xt_cluster.c:20:55:    got restricted unsigned int const [usertype] ip
      net/netfilter/xt_cluster.c:20:55: warning: incorrect type in return expression (different base types)
      net/netfilter/xt_cluster.c:20:55:    expected unsigned int
      net/netfilter/xt_cluster.c:20:55:    got restricted unsigned int const [usertype] ip
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Patrick McHardy's avatar
      netfilter: nf_conntrack: fix conntrack lookup race · 8d8890b7
      Patrick McHardy authored
      The RCU protected conntrack hash lookup only checks whether the entry
      has a refcount of zero to decide whether it is stale. This is not
      sufficient, entries are explicitly removed while there is at least
      one reference left, possibly more. Explicitly check whether the entry
      has been marked as dying to fix this.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Patrick McHardy's avatar
      netfilter: nf_conntrack: fix confirmation race condition · 5c8ec910
      Patrick McHardy authored
      New connection tracking entries are inserted into the hash before they
      are fully set up, namely the CONFIRMED bit is not set and the timer not
      started yet. This can theoretically lead to a race with timer, which
      would set the timeout value to a relative value, most likely already in
      the past.
      Perform hash insertion as the final step to fix this.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Eric Dumazet's avatar
      netfilter: nf_conntrack: death_by_timeout() fix · 8cc20198
      Eric Dumazet authored
      death_by_timeout() might delete a conntrack from hash list
      and insert it in dying list.
      I believe a (lockless) reader could *catch* ct while doing a lookup
      and miss the end of its chain.
      (nulls lookup algo must check the null value at the end of lookup and
      should restart if the null value is not the expected one.
      cf Documentation/RCU/rculist_nulls.txt for details)
      We need to change nf_conntrack_init_net() and use a different "null" value,
      guaranteed not being used in regular lists. Choose very large values, since
      hash table uses [0..size-1] null values.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
  8. 20 Jun, 2009 2 commits
    • Ricardo Labiaga's avatar
      nfs41: sunrpc: xprt_alloc_bc_request() should not use spin_lock_bh() · e9f02985
      Ricardo Labiaga authored
      xprt_alloc_bc_request() is always called in soft interrupt context.
      Grab the spin_lock instead of the bottom half spin_lock.  Softirqs
      do not preempt other softirqs running on the same processor, so there
      is no need to disable bottom halves.
      Signed-off-by: default avatarRicardo Labiaga <Ricardo.Labiaga@netapp.com>
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    • 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>
  9. 19 Jun, 2009 5 commits