07 Oct, 2010
1 commit
-
Merge reason: Update from -rc3 to -rc7.
Signed-off-by: Ingo Molnar
23 Sep, 2010
1 commit
-
As soon as rcu_read_unlock() is called, there is no guarantee current
thread can safely derefence t pointer, rcu protected.Fix is to copy t->alloc_size in a temporary variable.
Signed-off-by: Eric Dumazet
Reviewed-by: Paul E. McKenney
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
20 Aug, 2010
1 commit
-
Signed-off-by: Arnd Bergmann
Signed-off-by: Paul E. McKenney
Acked-by: Patrick McHardy
Cc: "David S. Miller"
Cc: Eric Dumazet
Reviewed-by: Josh Triplett
02 Aug, 2010
1 commit
-
some users of nf_ct_ext_exist() know ct->ext isn't NULL. For these users, the
check for ct->ext isn't necessary, the function __nf_ct_ext_exist() can be
used instead.the type of the return value of nf_ct_ext_exist() is changed to bool.
Signed-off-by: Changli Gao
Signed-off-by: Patrick McHardy
12 Feb, 2010
1 commit
-
call_rcu() will unconditionally reinitialize RCU head anyway.
Signed-off-by: Alexey Dobriyan
Reviewed-by: Paul E. McKenney
Signed-off-by: Patrick McHardy
25 Jun, 2009
1 commit
-
RCU barriers, rcu_barrier(), is inserted two places.
In nf_conntrack_expect.c nf_conntrack_expect_fini() before the
kmem_cache_destroy(). Firstly to make sure the callback to the
nf_ct_expect_free_rcu() code is still around. Secondly because I'm
unsure about the consequence of having in flight
nf_ct_expect_free_rcu/kmem_cache_free() calls while doing a
kmem_cache_destroy() slab destroy.And in nf_conntrack_extend.c nf_ct_extend_unregister(), inorder to
wait for completion of callbacks to __nf_ct_ext_free_rcu(), which is
invoked by __nf_ct_ext_add(). It might be more efficient to call
rcu_barrier() in nf_conntrack_core.c nf_conntrack_cleanup_net(), but
thats make it more difficult to read the code (as the callback code
in located in nf_conntrack_extend.c).Signed-off-by: Jesper Dangaard Brouer
Signed-off-by: Patrick McHardy
27 Jul, 2008
2 commits
-
As Linus points out, "ct->ext" and "new" are always equal, avoid unnecessary
dereferences and use "new" directly.Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller -
As suggested by Patrick McHardy, introduce a __krealloc() that doesn't
free the original buffer to fix a double-free and use-after-free bug
introduced by me in netfilter that uses RCU.Reported-by: Patrick McHardy
Signed-off-by: Pekka Enberg
Tested-by: Dieter Ries
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
20 Jun, 2008
1 commit
-
Conflicts:
net/mac80211/tx.c
18 Jun, 2008
1 commit
-
Fix three ct_extend/NAT extension related races:
- When cleaning up the extension area and removing it from the bysource hash,
the nat->ct pointer must not be set to NULL since it may still be used in
a RCU read side- When replacing a NAT extension area in the bysource hash, the nat->ct
pointer must be assigned before performing the replacement- When reallocating extension storage in ct_extend, the old memory must
not be freed immediately since it may still be used by a RCU read sidePossibly fixes https://bugzilla.redhat.com/show_bug.cgi?id=449315
and/or http://bugzilla.kernel.org/show_bug.cgi?id=10875Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
10 Jun, 2008
1 commit
-
The ksize() API is going away because it is being abused and it doesn't even
work consistenly across different allocators. Therefore, convert
net/netfilter/nf_conntrack_extend.c to use krealloc().Signed-off-by: Pekka Enberg
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
14 Apr, 2008
1 commit
-
New extensions may only be added to unconfirmed conntracks to avoid races
when reallocating the storage.Also change NF_CT_ASSERT to use WARN_ON to get backtraces.
Signed-off-by: Patrick McHardy
11 Mar, 2008
1 commit
-
There's a horrible slab abuse in net/netfilter/nf_conntrack_extend.c
that can be replaced with a call to ksize().Cc: Christoph Lameter
Signed-off-by: Pekka Enberg
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
08 Feb, 2008
1 commit
-
The ->move operation has two bugs:
- It is called with the same extension as source and destination,
so it doesn't update the new extension.- The address of the old extension is calculated incorrectly,
instead of (void *)ct->ext + ct->ext->offset[i] it uses
ct->ext + ct->ext->offset[i].Fixes a crash on x86_64 reported by Chuck Ebbert
and Thomas Woerner .Tested-by: Thomas Woerner
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
16 Nov, 2007
1 commit
-
Reported by Chuck Ebbert as:
https://bugzilla.redhat.com/show_bug.cgi?id=259501#c14
This routine is called each time hash should be replaced, nf_conn has
extension list which contains pointers to connection tracking users
(like nat, which is right now the only such user), so when replace takes
place it should copy own extensions. Loop above checks for own
extension, but tries to move higer-layer one, which can lead to above
oops.Signed-off-by: Evgeniy Polyakov
Signed-off-by: David S. Miller
11 Jul, 2007
1 commit
-
Old space allocator of conntrack had problems about extensibility.
- It required slab cache per combination of extensions.
- It expected what extensions would be assigned, but it was impossible
to expect that completely, then we allocated bigger memory object than
really required.
- It needed to search helper twice due to lock issue.Now basic informations of a connection are stored in 'struct nf_conn'.
And a storage for extension (helper, NAT) is allocated by kmalloc.Signed-off-by: Yasuyuki Kozakai
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
