1. 09 2月, 2010 4 次提交
    • A
      netfilter: xtables: compat out of scope fix · 14c7dbe0
      Alexey Dobriyan 提交于
      As per C99 6.2.4(2) when temporary table data goes out of scope,
      the behaviour is undefined:
      
      	if (compat) {
      		struct foo tmp;
      		...
      		private = &tmp;
      	}
      	[dereference private]
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      14c7dbe0
    • A
      netfilter: nf_conntrack: restrict runtime expect hashsize modifications · 13ccdfc2
      Alexey Dobriyan 提交于
      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: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      13ccdfc2
    • E
      netfilter: nf_conntrack: per netns nf_conntrack_cachep · 5b3501fa
      Eric Dumazet 提交于
      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: NEric Dumazet <eric.dumazet@gmail.com>
      [Patrick: added unique slab name allocation]
      Cc: stable@kernel.org
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      5b3501fa
    • P
      netfilter: nf_conntrack: fix memory corruption with multiple namespaces · 9edd7ca0
      Patrick McHardy 提交于
      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: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9edd7ca0
  2. 05 2月, 2010 2 次提交
  3. 04 2月, 2010 11 次提交
  4. 03 2月, 2010 2 次提交
    • E
      connector: Delete buggy notification code. · f98bfbd7
      Evgeniy Polyakov 提交于
      On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote:
      > > There are at least two ways to fix it: using a big cannon and a small
      > > one. The former way is to disable notification registration, since it is
      > > not used by anyone at all. Second way is to check whether calling
      > > process is root and its destination group is -1 (kind of priveledged
      > > one) before command is dispatched to workqueue.
      > 
      > Well if no one is using it, removing it makes the most sense, right?
      > 
      > No objection from me, care to make up a patch either way for this?
      
      Getting it is not used, let's drop support for notifications about
      (un)registered events from connector.
      Another option was to check credentials on receiving, but we can always
      restore it without bugs if needed, but genetlink has a wider code base
      and none complained, that userspace can not get notification when some
      other clients were (un)registered.
      
      Kudos for Sebastian Krahmer <krahmer@suse.de>, who found a bug in the
      code.
      Signed-off-by: NEvgeniy Polyakov <zbr@ioremap.net>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f98bfbd7
    • D
  5. 02 2月, 2010 1 次提交
  6. 01 2月, 2010 1 次提交
  7. 30 1月, 2010 5 次提交
  8. 29 1月, 2010 2 次提交
  9. 28 1月, 2010 7 次提交
  10. 27 1月, 2010 3 次提交
  11. 26 1月, 2010 2 次提交
    • S
      ipv6: conntrack: Add member of user to nf_ct_frag6_queue structure · c92b544b
      Shan Wei 提交于
      The commit 0b5ccb2e(title:ipv6: reassembly: use seperate reassembly queues for
      conntrack and local delivery) has broken the saddr&&daddr member of
      nf_ct_frag6_queue when creating new queue.  And then hash value
      generated by nf_hashfn() was not equal with that generated by fq_find().
      So, a new received fragment can't be inserted to right queue.
      
      The patch fixes the bug with adding member of user to nf_ct_frag6_queue structure.
      Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
      Acked-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c92b544b
    • H
      virtio_net: Make delayed refill more reliable · 39d32157
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39d32157