24 Apr, 2009
1 commit
-
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (94 commits)
netfilter: ctnetlink: fix gcc warning during compilation
net/netrom: Fix socket locking
netlabel: Always remove the correct address selector
ucc_geth.c: Fix upsmr setting in RMII mode
8139too: fix HW initial flow
af_iucv: Fix race when queuing incoming iucv messages
af_iucv: Test additional sk states in iucv_sock_shutdown
af_iucv: Reject incoming msgs if RECV_SHUTDOWN is set
af_iucv: fix oops in iucv_sock_recvmsg() for MSG_PEEK flag
af_iucv: consider state IUCV_CLOSING when closing a socket
iwlwifi: DMA fixes
iwlwifi: add debugging for TX path
mwl8: fix build warning.
mac80211: fix alignment calculation bug
mac80211: do not print WARN if config interface
iwl3945: use cancel_delayed_work_sync to cancel rfkill_poll
iwlwifi: fix EEPROM validation mask to include OTP only devices
atmel: fix netdev ops conversion
pcnet_cs: add cis(firmware) of the Allied Telesis LA-PCM
mlx4_en: Fix cleanup if workqueue create in mlx4_en_add() fails
...
22 Apr, 2009
11 commits
-
This patch fixes a (bogus?) gcc warning during compilation:
net/netfilter/nf_conntrack_netlink.c:1234: warning: 'helpname' may be used uninitialized in this function
net/netfilter/nf_conntrack_netlink.c:991: warning: 'helpname' may be used uninitialized in this functionIn fact, helpname is initialized by ctnetlink_parse_help() so
I cannot see a way to use it without being initialized.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: David S. Miller -
Patch "af_rose/x25: Sanity check the maximum user frame size"
(commit 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9) from Alan Cox got
locking wrong. If we bail out due to user frame size being too large,
we must unlock the socket beforehand.Signed-off-by: Jean Delvare
Signed-off-by: David S. Miller -
The NetLabel address selector mechanism has a problem where it can get
mistakenly remove the wrong selector when similar addresses are used. The
problem is caused when multiple addresses are configured that have different
netmasks but the same address, e.g. 127.0.0.0/8 and 127.0.0.0/24. This patch
fixes the problem.Reported-by: Etienne Basset
Signed-off-by: Paul Moore
Acked-by: James Morris
Tested-by: Etienne Basset
Signed-off-by: David S. Miller -
AF_IUCV runs into a race when queuing incoming iucv messages
and receiving the resulting backlog.If the Linux system is under pressure (high load or steal time),
the message queue grows up, but messages are not received and queued
onto the backlog queue. In that case, applications do not
receive any data with recvmsg() even if AF_IUCV puts incoming
messages onto the message queue.The race can be avoided if the message queue spinlock in the
message_pending callback is spreaded across the entire callback
function.Signed-off-by: Hendrik Brueckner
Signed-off-by: Ursula Braun
Signed-off-by: David S. Miller -
Add few more sk states in iucv_sock_shutdown().
Signed-off-by: Hendrik Brueckner
Signed-off-by: Ursula Braun
Signed-off-by: David S. Miller -
Reject incoming iucv messages if the receive direction has been shut down.
It avoids that the queue of outstanding messages increases and exceeds the
message limit of the iucv communication path.Signed-off-by: Hendrik Brueckner
Signed-off-by: Ursula Braun
Signed-off-by: David S. Miller -
If iucv_sock_recvmsg() is called with MSG_PEEK flag set, the skb is enqueued
twice. If the socket is then closed, the pointer to the skb is freed twice.Remove the skb_queue_head() call for MSG_PEEK, because the skb_recv_datagram()
function already handles MSG_PEEK (does not dequeue the skb).Signed-off-by: Hendrik Brueckner
Signed-off-by: Ursula Braun
Signed-off-by: David S. Miller -
Make sure a second invocation of iucv_sock_close() guarantees proper
freeing of an iucv path.Signed-off-by: Ursula Braun
Signed-off-by: David S. Miller -
In non-SMP mode, the variable section attribute specified by DECLARE_PER_CPU()
does not agree with that specified by DEFINE_PER_CPU(). This means that
architectures that have a small data section references relative to a base
register may throw up linkage errors due to too great a displacement between
where the base register points and the per-CPU variable.On FRV, the .h declaration says that the variable is in the .sdata section, but
the .c definition says it's actually in the .data section. The linker throws
up the following errors:kernel/built-in.o: In function `release_task':
kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.oTo fix this, DECLARE_PER_CPU() should simply apply the same section attribute
as does DEFINE_PER_CPU(). However, this is made slightly more complex by
virtue of the fact that there are several variants on DEFINE, so these need to
be matched by variants on DECLARE.Signed-off-by: David Howells
Signed-off-by: Linus Torvalds -
When checking whether or not a given frame needs to be
moved to be properly aligned to a 4-byte boundary, we
use & 4 which wasn't intended, this code should check
the lowest two bits.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
It is expected that config interface will always succeed as mac80211
will only request what driver supports. The exception here is when a
device has rfkill enabled. At this time the rfkill state is unknown to
mac80211 and config interface can fail. When this happens we deal with
this error instead of printing a WARN.Signed-off-by: Reinette Chatre
Signed-off-by: John W. Linville
21 Apr, 2009
4 commits
-
"mac80211: fix basic rates setting from association response"
introduced a copy/paste error.Unfortunately, this not just leads to wrong data being passed
to the driver but is remotely exploitable for some hardware or
driver combinations.Signed-off-by: Johannes Berg
Cc: stable@kernel.org [2.6.29]
Signed-off-by: John W. Linville -
Currently beacon loss detection triggers after a scan. A probe request
is sent and a message like this is printed to the log:wlan0: beacon loss from AP 00:12:17:e7:98:de - sending probe request
But in fact there is no beacon loss, the beacons are just not received
because of the ongoing scan. Fix it by updating last_beacon after
the scan has finished.Reported-by: Jaswinder Singh Rajput
Signed-off-by: Kalle Valo
Acked-by: Johannes Berg
Signed-off-by: John W. Linville -
One of the code paths sending deauth/disassoc events ends up calling
this function with rcu_read_lock held, so we must use GFP_ATOMIC in
allocation routines.Reported-by: Johannes Berg
Signed-off-by: Jouni Malinen
Signed-off-by: John W. Linville -
Remove this unused Kconfig variable, which Intel apparently once
promised to make use of but never did.Signed-off-by: Robert P. J. Day
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
20 Apr, 2009
9 commits
-
This loop over fragments in napi_fraginfo_skb() was "interesting".
Signed-off-by: Ben Hutchings
Signed-off-by: David S. Miller -
Signed-off-by: Marcin Slusarz
Signed-off-by: David S. Miller -
Just noticed while doing some new work that the recent
mid-wq adjustment logic will misbehave when FACK is not
in use (happens either due sysctl'ed off or auto-detected
reordering) because I forgot the relevant TCPCB tagbit.Signed-off-by: Ilpo Järvinen
Signed-off-by: David S. Miller -
Alex Sidorenko reported:
"while experimenting with 'netem' we have found some strange behaviour. It
seemed that ingress delay as measured by 'ping' command shows up on some
hosts but not on others.After some investigation I have found that the problem is that skbuff->tstamp
field value depends on whether there are any packet sniffers enabled. That
is:- if any ptype_all handler is registered, the tstamp field is as expected
- if there are no ptype_all handlers, the tstamp field does not show the delay"This patch prevents unnecessary update of tstamp in dev_queue_xmit_nit()
on ingress path (with act_mirred) adding a check, so minimal overhead on
the fast path, but only when sniffers etc. are active.Since netem at ingress seems to logically emulate a network before a host,
tstamp is zeroed to trigger the update and pretend delays are from the
outside.Reported-by: Alex Sidorenko
Tested-by: Alex Sidorenko
Signed-off-by: Jarek Poplawski
Signed-off-by: David S. Miller -
This has been broken for a while. I happened to catch it testing because one
app "knew" that the top line of the calls data was the policy line and got
confused.Put the header back.
Signed-off-by: Alan Cox
Signed-off-by: David S. Miller -
The Broadcom chips with 2.1 firmware handle the fallback case to a SCO
link wrongly when setting up eSCO connections.< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 11 voice setting 0x0060
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 1 bdaddr 00:1E:3A:xx:xx:xx type SCO encrypt 0x01The Link Manager negotiates the fallback to SCO, but then sends out
a Connect Complete event. This is wrong and the Link Manager should
actually send a Synchronous Connection Complete event if the Setup
Synchronous Connection has been used. Only the remote side is allowed
to use Connect Complete to indicate the missing support for eSCO in
the host stack.This patch adds a workaround for this which clearly should not be
needed, but reality is that broken Broadcom devices are deployed.Based on a report by Ville Tervo
Signed-off-by: Marcel Holtman
-
Some Bluetooth chips (like the ones from Texas Instruments) don't do
proper eSCO negotiations inside the Link Manager. They just return an
error code and in case of the Kyocera ED-8800 headset it is just a
random error.< HCI Command: Setup Synchronous Connection 0x01|0x0028) plen 17
handle 1 voice setting 0x0060
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x1f handle 257 bdaddr 00:14:0A:xx:xx:xx type eSCO
Error: Unspecified ErrorIn these cases it is up to the host stack to fallback to a SCO setup
and so retry with SCO parameters.Based on a report by Nick Pelly
Signed-off-by: Marcel Holtmann
-
There is a missing call to rfcomm_dlc_clear_timer in the case that
DEFER_SETUP is used and so the connection gets disconnected after the
timeout even if it was successfully accepted previously.This patch adds a call to rfcomm_dlc_clear_timer to rfcomm_dlc_accept
which will get called when the user accepts the connection by calling
read() on the socket.Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
18 Apr, 2009
7 commits
-
Check whether the underlying device provides a set of ethtool ops before
checking for individual handlers to avoid NULL pointer dereferences.Reported-by: Art van Breemen
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller -
The TIM IE must not be shorter than 4 bytes, so verify that
when parsing it.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
Instead, allocate extra IE memory if necessary. Normally,
this isn't even necessary since there's enough space.This is a better way of correcting the "held BSS can
disappear" issue, but also a lot more code. It is also
necessary for proper auth/assoc BSS handling in the
future.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
When we receive a probe response frame we can replace the
BSS struct in our list -- but if that struct is held then
we need to hold the new one as well.We really should fix this completely and not replace the
struct, but this is a bandaid for now.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
Using the scan_sdata variable here is terribly wrong,
if there has never been a scan then we fail. However,
we need a bandaid...Signed-off-by: Johannes Berg
Cc: stable@kernel.org [2.6.29]
Signed-off-by: John W. Linville
17 Apr, 2009
6 commits
-
With this patch, nfnetlink returns -ENOMEM instead of -EPERM if we
fail to create the nfnetlink netlink socket during the module
loading. This is exactly what rtnetlink does in this case.Ideally, it would be better if we propagate the error that has
happened in netlink_kernel_create(), however, this function still
does not implement this yet.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Patrick McHardy -
This patch fixes an inconsistency that results in no error reports
to user-space listeners if we fail to allocate the event message.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Patrick McHardy -
After calling skb_gro_receive skb->len can no longer be relied
on since if the skb was merged using frags, then its pages will
have been removed and the length reduced.This caused tcp_gro_receive to prematurely end merging which
resulted in suboptimal performance with ixgbe.The fix is to store skb->len on the stack.
Reported-by: Mark Wagner
Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller -
Since commit ead2ceb0ec9f85cff19c43b5cdb2f8a054484431 ("Network Drop
Monitor: Adding kfree_skb_clean for non-drops and modifying
end-of-line points for skbs") so called end-of-line points for skb's
should use consume_skb() to free the socket buffer.In opposite to consume_skb() the function kfree_skb() is intended to
be used for unexpected skb drops e.g. in error conditions that now can
trigger the network drop monitor if enabled.This patch moves the skb end-of-line point in af_can.c to use
consume_skb().Signed-off-by: Oliver Hartkopp
Signed-off-by: David S. Miller -
The removal of the SAME target accidentally removed one feature that is
not available from the normal NAT targets so far, having multi-range
mappings that use the same mapping for each connection from a single
client. The current behaviour is to choose the address from the range
based on source and destination IP, which breaks when communicating
with sites having multiple addresses that require all connections to
originate from the same IP address.Introduce a IP_NAT_RANGE_PERSISTENT option that controls whether the
destination address is taken into account for selecting addresses.http://bugzilla.kernel.org/show_bug.cgi?id=12954
Signed-off-by: Patrick McHardy
16 Apr, 2009
2 commits
-
mac80211: Fragmentation threshold (typo)
ieee80211_ioctl_siwfrag() sets the fragmentation_threshold to 2352
when frame fragmentation is to be disabled, yet the corresponding
'get' function tests for 2353 bytes instead.This causes user-space tools to display a fragmentation threshold
of 2352 bytes even if fragmentation has been disabled.Signed-off-by: Gerrit Renker
Signed-off-by: John W. Linville -
On Sunday 05 April 2009 11:29:38 Michael Buesch wrote:
> On Sunday 05 April 2009 11:23:59 Jaswinder Singh Rajput wrote:
> > With latest linus tree I am getting, .config file attached:
> >
> > [ 22.895051] r8169: eth0: link down
> > [ 22.897564] ADDRCONF(NETDEV_UP): eth0: link is not ready
> > [ 22.928047] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > [ 22.982292] libvirtd used greatest stack depth: 4200 bytes left
> > [ 63.709879] wlan0: authenticate with AP 00:11:95:9e:df:f6
> > [ 63.712096] wlan0: authenticated
> > [ 63.712127] wlan0: associate with AP 00:11:95:9e:df:f6
> > [ 63.726831] wlan0: RX AssocResp from 00:11:95:9e:df:f6 (capab=0x471 status=0 aid=1)
> > [ 63.726855] wlan0: associated
> > [ 63.730093] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> > [ 74.296087] wlan0: no IPv6 routers present
> > [ 79.349044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 119.358200] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 179.354292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 259.366044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 359.348292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 361.953459] packagekitd used greatest stack depth: 4160 bytes left
> > [ 478.824258] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 598.813343] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 718.817292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 838.824567] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 958.815402] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1078.848434] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1198.822913] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1318.824931] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1438.814157] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1558.827336] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1678.823011] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1798.830589] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 1918.828044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2038.827224] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2116.517152] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2158.840243] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
> > [ 2278.827427] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
>
>
> I think this message should only show if CONFIG_MAC80211_VERBOSE_DEBUG is set.
> It's kind of expected that we lose a beacon once in a while, so we shouldn't print
> verbose messages to the kernel log (even if they are KERN_DEBUG).
>
> And besides that, I think one can easily remotely trigger this message and flood the logs.
> So it should probably _also_ be ratelimited.Something like this:
Signed-off-by: Michael Buesch
