linux-toradex.git/net, branch v2.6.30.2

Revert "ipv4: arp announce, arp_proxy and windows ip conflict verification"

2009-07-20T03:38:54+00:00

commit f8a68e752bc4e39644843403168137663c984524 upstream.

This reverts commit 73ce7b01b4496a5fbf9caf63033c874be692333f.

After discovering that we don't listen to gratuitious arps in 2.6.30
I tracked the failure down to this commit.

The patch makes absolutely no sense.  RFC2131 RFC3927 and RFC5227.
are all in agreement that an arp request with sip == 0 should be used
for the probe (to prevent learning) and an arp request with sip == tip
should be used for the gratitous announcement that people can learn
from.

It appears the author of the broken patch got those two cases confused
and modified the code to drop all gratuitous arp traffic.  Ouch!

Signed-off-by: Eric W. Biederman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix in nl80211_set_reg()

2009-07-02T23:50:10+00:00

commit 61405e97788b1bc4e7c5be5b4ec04a73fc11bac2 upstream.

There is a race on access to last_request and its alpha2
through reg_is_valid_request() and us possibly processing
first another regulatory request on another CPU. We avoid
this improbably race by locking with the cfg80211_mutex as
we should have done in the first place. While at it add
the assert on locking on reg_is_valid_request().

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: return immediately if num reg rules > NL80211_MAX_SUPP_REG_RULES

2009-07-02T23:50:09+00:00

commit 4776c6e7f66f853011bc1fd6fe37fa63f0b6982c upstream.

This has no functional change except we save a kfree(rd) and
allows us to clean this code up a bit after this. We do
avoid an unnecessary kfree(NULL) but calling that was OK too.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: cleanup return calls on nl80211_set_reg()

2009-07-02T23:50:08+00:00

commit d0e18f833d23afefb6751a21d14a2cd71d2d4d66 upstream.

This has no functional change, but it will make the race
fix easier to spot in my next patch.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix for duplicate userspace replies

2009-07-02T23:50:07+00:00

commit 729e9c7663190d71fe5e29831634df80f38199c1 upstream.

This fixes an incorrect assumption (BUG_ON) made in
cfg80211 when handling country IE regulatory requests.
The assumption was that we won't try to call_crda()
twice for the same event and therefore we will not
recieve two replies through nl80211 for the regulatory
request. As it turns out it is true we don't call_crda()
twice for the same event, however, kobject_uevent_env()
*might* send the udev event twice and/or userspace can
simply process the udev event twice. We remove the BUG_ON()
and simply ignore the duplicate request.

For details refer to this thread:

http://marc.info/?l=linux-wireless&m=124149987921337&w=2

Reported-by: Maxim Levitsky 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix minstrel single-rate memory corruption

2009-07-02T23:50:07+00:00

commit 5ee58d7e6ad019675b4090582aec4fa1180d8703 upstream.

The minstrel rate controller periodically looks up rate indexes in
a sampling table.  When accessing a specific row and column, minstrel
correctly does a bounds check which, on the surface, appears to handle
the case where mi->n_rates < 2.  However, mi->sample_idx is actually
defined as an unsigned, so the right hand side is taken to be a huge
positive number when negative, and the check will always fail.

Consequently, the RC will overrun the array and cause random memory
corruption when communicating with a peer that has only a single rate.
The max value of mi->sample_idx is around 25 so casting to int should
have no ill effects.

Without the change, uptime is a few minutes under load with an AP
that has a single hard-coded rate, and both the AP and STA could
potentially crash.  With the change, both lasted 12 hours with a
steady load.

Thanks to Ognjen Maric for providing the single-rate clue so I could
reproduce this.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=12490 on the
regression list (also http://bugzilla.kernel.org/show_bug.cgi?id=13000).

Reported-by: Sergey S. Kostyliov 
Reported-by: Ognjen Maric 
Signed-off-by: Bob Copeland 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

x25: Fix sleep from timer on socket destroy.

2009-07-02T23:49:43+00:00

[ Upstream commit 14ebaf81e13ce66bff275380b246796fd16cbfa1 ]

If socket destuction gets delayed to a timer, we try to
lock_sock() from that timer which won't work.

Use bh_lock_sock() in that case.

Signed-off-by: David S. Miller 
Tested-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

ipv4 routing: Ensure that route cache entries are usable and reclaimable with caching is off

2009-07-02T23:49:41+00:00

[ Upstream commit b6280b47a7a42970d098a3059f4ebe7e55e90d8d ]

When route caching is disabled (rt_caching returns false), We still use route
cache entries that are created and passed into rt_intern_hash once.  These
routes need to be made usable for the one call path that holds a reference to
them, and they need to be reclaimed when they're finished with their use.  To be
made usable, they need to be associated with a neighbor table entry (which they
currently are not), otherwise iproute_finish2 just discards the packet, since we
don't know which L2 peer to send the packet to.  To do this binding, we need to
follow the path a bit higher up in rt_intern_hash, which calls
arp_bind_neighbour, but not assign the route entry to the hash table.
Currently, if caching is off, we simply assign the route to the rp pointer and
are reutrn success.  This patch associates us with a neighbor entry first.

Secondly, we need to make sure that any single use routes like this are known to
the garbage collector when caching is off.  If caching is off, and we try to
hash in a route, it will leak when its refcount reaches zero.  To avoid this,
this patch calls rt_free on the route cache entry passed into rt_intern_hash.
This places us on the gc list for the route cache garbage collector, so that
when its refcount reaches zero, it will be reclaimed (Thanks to Alexey for this
suggestion).

I've tested this on a local system here, and with these patches in place, I'm
able to maintain routed connectivity to remote systems, even if I set
/proc/sys/net/ipv4/rt_cache_rebuild_count to -1, which forces rt_caching to
return false.

Signed-off-by: Neil Horman 
Reported-by: Jarek Poplawski 
Reported-by: Maxime Bizon 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv4: fix NULL pointer + success return in route lookup path

2009-07-02T23:49:40+00:00

[ Upstream commit 73e42897e8e5619eacb787d2ce69be12f47cfc21 ]

Don't drop route if we're not caching

	I recently got a report of an oops on a route lookup.  Maxime was
testing what would happen if route caching was turned off (doing so by setting
making rt_caching always return 0), and found that it triggered an oops.  I
looked at it and found that the problem stemmed from the fact that the route
lookup routines were returning success from their lookup paths (which is good),
but never set the **rp pointer to anything (which is bad).  This happens because
in rt_intern_hash, if rt_caching returns false, we call rt_drop and return 0.
This almost emulates slient success.  What we should be doing is assigning *rp =
rt and _not_ dropping the route.  This way, during slow path lookups, when we
create a new route cache entry, we don't immediately discard it, rather we just
don't add it into the cache hash table, but we let this one lookup use it for
the purpose of this route request.  Maxime has tested and reports it prevents
the oops.  There is still a subsequent routing issue that I'm looking into
further, but I'm confident that, even if its related to this same path, this
patch makes sense to take.

Signed-off-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6

2009-06-09T15:47:27+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
  cls_cgroup: Fix oops when user send improperly 'tc filter add' request
  r8169: fix crash when large packets are received