| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
|
|
|
|
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
|
|
Signed-off-by: Trond Myklebust <[email protected]>
|
|
|
|
|
|
This reverts 747c5534c9a6da4aa87e7cdc2209ea98ea27f381 commit.
|
|
This bug is responsible for causing the infamous "Treason uncloaked"
messages that's been popping up everywhere since the printk was added.
It has usually been blamed on foreign operating systems. However,
some of those reports implicate Linux as both systems are running
Linux or the TCP connection is going across the loopback interface.
In fact, there really is a bug in the Linux TCP header prediction code
that's been there since at least 2.1.8. This bug was tracked down with
help from Dale Blount.
The effect of this bug ranges from harmless "Treason uncloaked"
messages to hung/aborted TCP connections. The details of the bug
and fix is as follows.
When snd_wnd is updated, we only update pred_flags if
tcp_fast_path_check succeeds. When it fails (for example,
when our rcvbuf is used up), we will leave pred_flags with
an out-of-date snd_wnd value.
When the out-of-date pred_flags happens to match the next incoming
packet we will again hit the fast path and use the current snd_wnd
which will be wrong.
In the case of the treason messages, it just happens that the snd_wnd
cached in pred_flags is zero while tp->snd_wnd is non-zero. Therefore
when a zero-window packet comes in we incorrectly conclude that the
window is non-zero.
In fact if the peer continues to send us zero-window pure ACKs we
will continue making the same mistake. It's only when the peer
transmits a zero-window packet with data attached that we get a
chance to snap out of it. This is what triggers the treason
message at the next retransmit timeout.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Convert nanoseconds to microseconds correctly.
Spotted by Steve Dickson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Although this message is having the intended effect of causing wireless
driver maintainers to upgrade their code, I never should have merged this
patch in its present form. Leading to tons of bug reports and unhappy
users.
Some wireless apps poll for statistics regularly, which leads to a printk()
every single time they ask for stats. That's a little bit _too_ much of a
reminder that the driver is using an old API.
Change this to printing out the message once, per kernel boot.
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
|
|
James Ketrenos wrote:
> [3/4] Use the tx_headroom and reserve requested space.
This patch introduced a compile problem; patch below corrects this.
Fixed compilation error due to not passing tx_headroom in
ieee80211_tx_frame.
Signed-off-by: James Ketrenos <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
|
|
Fix setting of the broadcast address when the netmask is set via
SIOCSIFNETMASK in Linux 2.6. The code wanted the old value of
ifa->ifa_mask but used it after it had already been overwritten with
the new value.
Signed-off-by: David Engel <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Signed-off-by: Ralf Baechle DL5RB <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Add kernel-doc to skbuff.h, skbuff.c to eliminate kernel-doc warnings.
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
skb_prev is assigned from skb, which cannot be NULL. This patch removes the
unnecessary NULL check.
Signed-off-by: Jayachandran C. <c.jayachandran at gmail.com>
Acked-by: James Morris <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Remove the variable nlk & call to nlk_sk as it does not have any side effect.
Signed-off-by: Jayachandran C. <c.jayachandran at gmail.com>
Acked-by: James Morris <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Now that we've switched over to storing MTUs in the xfrm_dst entries,
we no longer need the dst's get_mss methods. This patch gets rid of
them.
It also documents the fact that our MTU calculation is not optimal
for ESP.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
This patch kills a redundant rcu_dereference on fa->fa_info in fib_trie.c.
As this dereference directly follows a list_for_each_entry_rcu line, we
have already taken a read barrier with respect to getting an entry from
the list.
This read barrier guarantees that all values read out of fa are valid.
In particular, the contents of structure pointed to by fa->fa_info is
initialised before fa->fa_info is actually set (see fn_trie_insert);
the setting of fa->fa_info itself is further separated with a write
barrier from the insertion of fa into the list.
Therefore by taking a read barrier after obtaining fa from the list
(which is given by list_for_each_entry_rcu), we can be sure that
fa->fa_info contains a valid pointer, as well as the fact that the
data pointed to by fa->fa_info is itself valid.
Signed-off-by: Herbert Xu <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
It's fairly simple to resize the hash table, but currently you need to
remove and reinsert the module. That's bad (we lose connection
state). Harald has even offered to write a daemon which sets this
based on load.
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Harald Welte <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
The code to handle the /proc interface can be cleaned up in several places:
* use seq_file for read
* don't need to remember all the filenames separately
* use for_online_cpu's
* don't vmalloc a buffer for small command from user.
Committer note:
This patch clashed with John Hawkes's "[NET]: Wider use of for_each_*cpu()",
so I fixed it up manually.
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Robert Olsson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Fix some cosmetic issues. Indentation, spelling errors, and some whitespace.
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Robert Olsson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
These are cleanup patches for pktgen that can go in 2.6.15
Can use kzalloc in a couple of places.
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Robert Olsson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
pktgen is calling kmalloc GFP_KERNEL and vmalloc with lock held.
The simplest fix is to turn the lock into a semaphore, since the
thread lock is only used for admin control from user context.
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Robert Olsson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
In 'net' change the explicit use of for-loops and NR_CPUS into the
general for_each_cpu() or for_each_online_cpu() constructs, as
appropriate. This widens the scope of potential future optimizations
of the general constructs, as well as takes advantage of the existing
optimizations of first_cpu() and next_cpu(), which is advantageous
when the true CPU count is much smaller than NR_CPUS.
Signed-off-by: John Hawkes <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Signed-off-by: Patrick Caulfield <[email protected]>
Signed-off-by: Steven Whitehouse <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Signed-off-by: Jochen Friedrich <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Signed-off-by: Yan Zheng <[email protected]>
Acked-by: YOSHIFUJI Hideaki <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
neigh_changeaddr attempts to delete neighbour timers without setting
nud_state. This doesn't work because the timer may have already fired
when we acquire the write lock in neigh_changeaddr. The result is that
the timer may keep firing for quite a while until the entry reaches
NEIGH_FAILED.
It should be setting the nud_state straight away so that if the timer
has already fired it can simply exit once we relinquish the lock.
In fact, this whole function is simply duplicating the logic in
neigh_ifdown which in turn is already doing the right thing when
it comes to deleting timers and setting nud_state.
So all we have to do is take that code out and put it into a common
function and make both neigh_changeaddr and neigh_ifdown call it.
Signed-off-by: Herbert Xu <[email protected]>
|
|
neigh_add_timer cannot use add_timer unconditionally. The reason is that
by the time it has obtained the write lock someone else (e.g., neigh_update)
could have already added a new timer.
So it should only use mod_timer and deal with its return value accordingly.
This bug would have led to rare neighbour cache entry leaks.
Signed-off-by: Herbert Xu <[email protected]>
|
|
Stack traces are very helpful in determining the exact nature of a bug.
So let's print a stack trace when the timer is added twice.
Signed-off-by: Herbert Xu <[email protected]>
|
|
IPVS used flag NFC_IPVS_PROPERTY in nfcache but as now nfcache was removed the
new flag 'ipvs_property' still needs to be copied. This patch should be
included in 2.6.14.
Further comments from Harald Welte:
Sorry, seems like the bug was introduced by me.
Signed-off-by: Julian Anastasov <[email protected]>
Signed-off-by: Harald Welte <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
* Use GFP mask on TX skb allocation.
* Use the tx_headroom and reserve requested space.
Signed-off-by: Michael Buesch <[email protected]>
Signed-off-by: James Ketrenos <[email protected]>
|
|
It is legitimate to call tcp_fragment with len == skb->len since
that is done for FIN packets and the FIN flag counts as one byte.
So we should only check for the len > skb->len case.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Turns out the problem has nothing to do with use-after-free or double-free.
It's just that we're not clearing the CB area and DCCP unlike TCP uses a CB
format that's incompatible with IP.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Ian McDonald <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
icmp_send doesn't use skb->sk at all so even if skb->sk has already
been freed it can't cause crash there (it would've crashed somewhere
else first, e.g., ip_queue_xmit).
I found a double-free on an skb that could explain this though.
dccp_sendmsg and dccp_write_xmit are a little confused as to what
should free the packet when something goes wrong. Sometimes they
both go for the ball and end up in each other's way.
This patch makes dccp_write_xmit always free the packet no matter
what. This makes sense since dccp_transmit_skb which in turn comes
from the fact that ip_queue_xmit always frees the packet.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
David S. Miller <[email protected]> wrote:
> One thing you can probably do for this bug is to mark data packets
> explicitly somehow, perhaps in the SKB control block DCCP already
> uses for other data. Put some boolean in there, set it true for
> data packets. Then change the test in dccp_transmit_skb() as
> appropriate to test the boolean flag instead of "skb_cloned(skb)".
I agree. In fact we already have that flag, it's called skb->sk.
So here is patch to test that instead of skb_cloned().
Signed-off-by: Herbert Xu <[email protected]>
Acked-by: Ian McDonald <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Without this patch, if you try and use a key that has not been
configured, for example:
% iwconfig eth1 key deadbeef00 [2]
without having configured key [1], then the active key will still be
[1], but privacy will now be enabled. Transmission of a packet in this
situation will result in a kernel oops.
Signed-off-by: James Ketrenos <[email protected]>
|
|
Signed-off-by: James Ketrenos <[email protected]>
|
|
Remove some senseless wrappers.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
Not only are the qop parameters that are passed around throughout the gssapi
unused by any currently implemented mechanism, but there appears to be some
doubt as to whether they will ever be used. Let's just kill them off for now.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
Add support for privacy to the krb5 rpcsec_gss mechanism.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
The code this was originally derived from processed wrap and mic tokens using
the same functions. This required some contortions, and more would be required
with the addition of xdr_buf's, so it's better to separate out the two code
paths.
In preparation for adding privacy support, remove the last vestiges of the
old wrap token code.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
Factor out some code that will be shared by privacy crypto routines
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
Add the code to the client side to handle privacy. This is dead code until
we actually add privacy support to krb5.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
Various xdr encode routines use au_rslack to guess where the reply argument
will end up, so we can set up the xdr_buf to recieve data into the right place
for zero copy.
Currently we calculate the au_rslack estimate when we check the verifier.
Normally this only depends on the verifier size. In the integrity case we add
a few bytes to allow for a length and sequence number.
It's a bit simpler to calculate only the verifier size when we check the
verifier, and delay the full calculation till we unwrap.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
For privacy we need to allocate extra pages to hold encrypted page data when
wrapping requests. This allocation may fail, and we handle that case by
waiting and retrying.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
For privacy, we need to allocate pages to store the encrypted data (passed
in pages can't be used without the risk of corrupting data in the page cache).
So we need a way to free that memory after the request has been transmitted.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
Add support for privacy to generic gss-api code. This is dead code until we
have both a mechanism that supports privacy and code in the client or server
that uses it.
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|