Skip to content

cloud-kernel
cloud-kernel

bug2833 / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  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
  3. 05 2月, 2010 2 次提交
  5. 04 2月, 2010 11 次提交
  7. 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
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6 · a4c89051
      由 David S. Miller 提交于
      a4c89051
  9. 02 2月, 2010 1 次提交
  11. 01 2月, 2010 1 次提交
  13. 30 1月, 2010 5 次提交
  15. 29 1月, 2010 2 次提交
  17. 28 1月, 2010 7 次提交
  19. 27 1月, 2010 3 次提交
  21. 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