1. 08 Feb, 2010 3 commits
    • Alexey Dobriyan's avatar
      netfilter: nf_conntrack: restrict runtime expect hashsize modifications · 13ccdfc2
      Alexey Dobriyan authored
      Expectation hashtable size was simply glued to a variable with no code
      to rehash expectations, so it was a bug to allow writing to it.
      Make "expect_hashsize" readonly.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Eric Dumazet's avatar
      netfilter: nf_conntrack: per netns nf_conntrack_cachep · 5b3501fa
      Eric Dumazet authored
      nf_conntrack_cachep is currently shared by all netns instances, but
      because of SLAB_DESTROY_BY_RCU special semantics, this is wrong.
      If we use a shared slab cache, one object can instantly flight between
      one hash table (netns ONE) to another one (netns TWO), and concurrent
      reader (doing a lookup in netns ONE, 'finding' an object of netns TWO)
      can be fooled without notice, because no RCU grace period has to be
      observed between object freeing and its reuse.
      We dont have this problem with UDP/TCP slab caches because TCP/UDP
      hashtables are global to the machine (and each object has a pointer to
      its netns).
      If we use per netns conntrack hash tables, we also *must* use per netns
      conntrack slab caches, to guarantee an object can not escape from one
      namespace to another one.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      [Patrick: added unique slab name allocation]
      Cc: stable@kernel.org
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Patrick McHardy's avatar
      netfilter: nf_conntrack: fix memory corruption with multiple namespaces · 9edd7ca0
      Patrick McHardy authored
      As discovered by Jon Masters <jonathan@jonmasters.org>, the "untracked"
      conntrack, which is located in the data section, might be accidentally
      freed when a new namespace is instantiated while the untracked conntrack
      is attached to a skb because the reference count it re-initialized.
      The best fix would be to use a seperate untracked conntrack per
      namespace since it includes a namespace pointer. Unfortunately this is
      not possible without larger changes since the namespace is not easily
      available everywhere we need it. For now move the untracked conntrack
      initialization to the init_net setup function to make sure the reference
      count is not re-initialized and handle cleanup in the init_net cleanup
      function to make sure namespaces can exit properly while the untracked
      conntrack is in use in other namespaces.
      Cc: stable@kernel.org
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 04 Feb, 2010 2 commits
  3. 03 Feb, 2010 11 commits
  4. 02 Feb, 2010 3 commits
  5. 01 Feb, 2010 1 commit
  6. 30 Jan, 2010 5 commits
  7. 28 Jan, 2010 9 commits
  8. 26 Jan, 2010 4 commits
  9. 25 Jan, 2010 2 commits
    • Herbert Xu's avatar
      virtio_net: Make delayed refill more reliable · 39d32157
      Herbert Xu authored
      I have seen RX stalls on a machine that experienced a suspected
      OOM.  After the stall, the RX buffer is empty on the guest side
      and there are exactly 16 entries available on the host side.  As
      the number of entries is less than that required by a maximal
      skb, the host cannot proceed.
      The guest did not have a refill job scheduled.
      My diagnosis is that an OOM had occured, with the delayed refill
      job scheduled.  The job was able to allocate at least one skb, but
      not enough to overcome the minimum required by the host to proceed.
      As the refill job would only reschedule itself if it failed completely
      to allocate any skbs, this would lead to an RX stall.
      The following patch removes this stall possibility by always
      rescheduling the refill job until the ring is totally refilled.
      Testing has shown that the RX stall no longer occurs whereas
      previously it would occur within a day.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Ben Hutchings's avatar
      sfc: Use fixed-size buffers for MCDI NVRAM requests · 5a27e86b
      Ben Hutchings authored
      The low-level MCDI code always uses 32-bit MMIO operations, and
      callers must pad input and output buffers to multiples of 4 bytes.
      The MCDI NVRAM functions are not doing this.  Also, their buffers are
      declared as variable-length arrays with no explicit maximum length.
      Switch to a fixed buffer size based on the chunk size used by the
      MTD driver (which is a multiple of 4).
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>