This patch updates the HCI security filter with support for the Extended
Inquiry Response (EIR) feature.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch makes another bunch of functions static.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch moves rfcomm_crc_table[] into the RFCOMM core, because there
is no need to keep it in a separate file.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

This reverts 747c5534 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: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

Convert nanoseconds to microseconds correctly.

Spotted by Steve Dickson <SteveD@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NJames Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

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: NDavid Engel <gigem@comcast.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

Signed-off-by: NRalf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

Add kernel-doc to skbuff.h, skbuff.c to eliminate kernel-doc warnings.
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NJames Morris <jmorris@namei.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NJames Morris <jmorris@namei.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NPaul E. McKenney <paulmck@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHarald Welte <laforge@netfilter.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NRobert Olsson <robert.olsson@its.uu.se>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

Fix some cosmetic issues. Indentation, spelling errors, and some whitespace.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NRobert Olsson <robert.olsson@its.uu.se>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

These are cleanup patches for pktgen that can go in 2.6.15
Can use kzalloc in a couple of places.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NRobert Olsson <robert.olsson@its.uu.se>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NRobert Olsson <robert.olsson@its.uu.se>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NJohn Hawkes <hawkes@sgi.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

Signed-off-by: NPatrick Caulfield <patrick@tykepenguin.com>
Signed-off-by: NSteven Whitehouse <steve@chygwyn.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

Signed-off-by: NJochen Friedrich <jochen@scram.de>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

Signed-off-by: NYan Zheng <yanzheng@21cn.com>
Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NHerbert Xu <herbert@gondor.apana.org.au>

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: NHerbert Xu <herbert@gondor.apana.org.au>

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: NHerbert Xu <herbert@gondor.apana.org.au>

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: NJulian Anastasov <ja@ssi.bg>
Signed-off-by: NHarald Welte <laforge@netfilter.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

* Use GFP mask on TX skb allocation.
* Use the tx_headroom and reserve requested space.
Signed-off-by: NMichael Buesch <mbuesch@freenet.de>
Signed-off-by: NJames Ketrenos <jketreno@linux.intel.com>

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: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NIan McDonald <imcdnzl@gmail.com>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

David S. Miller <davem@davemloft.net> 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: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NIan McDonald <imcdnzl@gmail.com>
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>

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: NJames Ketrenos <jketreno@linux.intel.com>

Signed-off-by: NJames Ketrenos <jketreno@linux.intel.com>

 Remove some senseless wrappers.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

 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: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

 Add support for privacy to the krb5 rpcsec_gss mechanism.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>