If module initialisation failed (e.g. because the bonding sysfs entry
cannot be created), kernel panics:
 IP: [<ffffffff8024910a>] destroy_workqueue+0x2d/0x146
Call Trace:
 [<ffffffff808268c4>] bond_destructor+0x28/0x78
 [<ffffffff80b64471>] netdev_run_todo+0x231/0x25a
 [<ffffffff80b6dbcd>] rtnl_unlock+0x9/0xb
 [<ffffffff81567907>] bonding_init+0x83e/0x84a

Remove the calls to bond_work_cancel_all() and destroy_workqueue();
both are also called/scheduled via bond_free_all().

bond_destroy_sysfs is unecessary because the sysfs entry has
not been created in the error case.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>

ENOSYS makes modutils complain about missing kernel module support.
Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>

This fixes the use of fwmarks to denote IPv4 virtual services
which was unfortunately broken as a result of the integration
of IPv6 support into IPVS, which was included in 2.6.28.

The problem arises because fwmarks are stored in the 4th octet
of a union nf_inet_addr .all, however in the case of IPv4 only
the first octet, corresponding to .ip, is assigned and compared.

In other words, using .all = { 0, 0, 0, htonl(svc->fwmark) always
results in a value of 0 (32bits) being stored for IPv4. This means
that one fwmark can be used, as it ends up being mapped to 0, but things
break down when multiple fwmarks are used, as they all end up being mapped
to 0.

As fwmarks are 32bits a reasonable fix seems to be to just store the fwmark
in .ip, and comparing and storing .ip when fwmarks are used.

This patch makes the assumption that in calls to ip_vs_ct_in_get()
and ip_vs_sched_persist() if the proto parameter is IPPROTO_IP then
we are dealing with an fwmark. I believe this is valid as ip_vs_in()
does fairly strict filtering on the protocol and IPPROTO_IP should
not be used in these calls unless explicitly passed when making
these calls for fwmarks in ip_vs_sched_persist().
Tested-by: Fabien Duchêne <fabien.duchene@student.uclouvain.be>
Cc: Joseph Mack NA3T <jmack@wm7d.net>
Cc: Julius Volz <julius.volz@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

This code is used as a library by several device drivers,
which select INET_LRO.

If some are modules and some are statically built into the
kernel, we get build failures if INET_LRO is modular.
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Ashish Karkare <akarkare@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Commit ac45f602 ("net: infrastructure
for hardware time stamping") added two skb initialization actions to
__alloc_skb(), which need to be added to skb_recycle_check() as well.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add barrier() to bnx2_get_hw_{tx|rx}_cons() to fix this issue:

http://bugzilla.kernel.org/show_bug.cgi?id=12698

This issue was reported by multiple i386 users.  Without barrier(),
the compiled code looks like the following where %eax contains the
address of the tx_cons or rx_cons in the DMA status block.  The
status block contents can change between the cmpb and the movzwl
instruction.  The driver would crash if the value was not 0xff during
the cmpb instruction, but changed to 0xff during the movzwl
instruction.

6828:	80 38 ff             	cmpb   $0xff,(%eax)
682b:	0f b7 10             	movzwl (%eax),%edx

With the added barrier(), the compiled code now looks correct:

683d:	0f b7 10             	movzwl (%eax),%edx
6840:	0f b6 c2             	movzbl %dl,%eax
6843:	3d ff 00 00 00       	cmp    $0xff,%eax

Thanks to Pascal de Bruijn <pmjdebruijn@pcode.nl> for reporting the
problem and Holger Noefer <hnoefer@pironet-ndh.com> for patiently
testing test patches for us.

Also updated version to 2.0.1.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When no limit is given, the bfifo uses a default of tx_queue_len * mtu.
Packets handled by qdiscs include the link layer header, so this should
be taken into account, similar to what other qdiscs do.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

The setup_rctl call was making a call into the ring structure after it had
been freed.  This was causing a panic on shutdown.  This call wasn't
necessary since it is possible to get the needed index from
adapter->vfs_allocated_count.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When a new wimax_dev is created, it's state has to be __WIMAX_ST_NULL
until wimax_dev_add() is succesfully called. This allows calls into
the stack that happen before said time to be rejected.

Until now, the state was being set (by mistake) to UNINITIALIZED,
which was allowing calls such as wimax_report_rfkill_hw() to go
through even when a call to wimax_dev_add() had failed; that was
causing an oops when touching uninitialized data.

This situation is normal when the device starts reporting state before
the whole initialization has been completed. It just has to be dealt
with.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>

When sending a message to user space using wimax_msg(), if nla_put()
fails, correctly interpret the return code from wimax_msg_alloc() as
an err ptr and return the error code instead of crashing (as it is
assuming than non-NULL means the pointer is ok).
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>

Setting the name of a sysfs device has to be done in a context that can
actually sleep. It allocates its memory with GFP_KERNEL. Previously it
was a static (size limited) string and that got changed to accommodate
longer device names. So move the dev_set_name() just before calling
device_add() which is executed in a work queue.

This fixes the following error:

[  110.012125] BUG: sleeping function called from invalid context at mm/slub.c:1595
[  110.012135] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
[  110.012141] 2 locks held by swapper/0:
[  110.012145]  #0:  (hci_task_lock){++.-.+}, at: [<ffffffffa01f822f>] hci_rx_task+0x2f/0x2d0 [bluetooth]
[  110.012173]  #1:  (&hdev->lock){+.-.+.}, at: [<ffffffffa01fb9e2>] hci_event_packet+0x72/0x25c0 [bluetooth]
[  110.012198] Pid: 0, comm: swapper Tainted: G        W 2.6.30-rc4-g953cdaa #1
[  110.012203] Call Trace:
[  110.012207]  <IRQ>  [<ffffffff8023eabd>] __might_sleep+0x14d/0x170
[  110.012228]  [<ffffffff802cfbe1>] __kmalloc+0x111/0x170
[  110.012239]  [<ffffffff803c2094>] kvasprintf+0x64/0xb0
[  110.012248]  [<ffffffff803b7a5b>] kobject_set_name_vargs+0x3b/0xa0
[  110.012257]  [<ffffffff80465326>] dev_set_name+0x76/0xa0
[  110.012273]  [<ffffffffa01fb9e2>] ? hci_event_packet+0x72/0x25c0 [bluetooth]
[  110.012289]  [<ffffffffa01ffc1d>] hci_conn_add_sysfs+0x3d/0x70 [bluetooth]
[  110.012303]  [<ffffffffa01fba2c>] hci_event_packet+0xbc/0x25c0 [bluetooth]
[  110.012312]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
[  110.012328]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
[  110.012343]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
[  110.012347]  [<ffffffff805e88c5>] ? _read_unlock+0x75/0x80
[  110.012354]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
[  110.012360]  [<ffffffffa01f8403>] hci_rx_task+0x203/0x2d0 [bluetooth]
[  110.012365]  [<ffffffff80250ab5>] tasklet_action+0xb5/0x160
[  110.012369]  [<ffffffff8025116c>] __do_softirq+0x9c/0x150
[  110.012372]  [<ffffffff805e850f>] ? _spin_unlock+0x3f/0x80
[  110.012376]  [<ffffffff8020cbbc>] call_softirq+0x1c/0x30
[  110.012380]  [<ffffffff8020f01d>] do_softirq+0x8d/0xe0
[  110.012383]  [<ffffffff80250df5>] irq_exit+0xc5/0xe0
[  110.012386]  [<ffffffff8020e71d>] do_IRQ+0x9d/0x120
[  110.012389]  [<ffffffff8020c3d3>] ret_from_intr+0x0/0xf
[  110.012391]  <EOI>  [<ffffffff80431832>] ? acpi_idle_enter_bm+0x264/0x2a6
[  110.012399]  [<ffffffff80431828>] ? acpi_idle_enter_bm+0x25a/0x2a6
[  110.012403]  [<ffffffff804f50d5>] ? cpuidle_idle_call+0xc5/0x130
[  110.012407]  [<ffffffff8020a4b4>] ? cpu_idle+0xc4/0x130
[  110.012411]  [<ffffffff805d2268>] ? rest_init+0x88/0xb0
[  110.012416]  [<ffffffff807e2fbd>] ? start_kernel+0x3b5/0x412
[  110.012420]  [<ffffffff807e2281>] ? x86_64_start_reservations+0x91/0xb5
[  110.012424]  [<ffffffff807e2394>] ? x86_64_start_kernel+0xef/0x11b

Based on a report by Davide Pesavento <davidepesa@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Hugo Mildenberger <hugo.mildenberger@namir.de>
Tested-by: Bing Zhao <bzhao@marvell.com>

This patch fixes the wrong message type that are triggered by
user updates, the following commands:

(term1)# conntrack -I -p tcp -s 1.1.1.1 -d 2.2.2.2 -t 10 --sport 10 --dport 20 --state LISTEN
(term1)# conntrack -U -p tcp -s 1.1.1.1 -d 2.2.2.2 -t 10 --sport 10 --dport 20 --state SYN_SENT
(term1)# conntrack -U -p tcp -s 1.1.1.1 -d 2.2.2.2 -t 10 --sport 10 --dport 20 --state SYN_RECV

only trigger event message of type NEW, when only the first is NEW
while others should be UPDATE.

(term2)# conntrack -E
    [NEW] tcp      6 10 LISTEN src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0
    [NEW] tcp      6 10 SYN_SENT src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0
    [NEW] tcp      6 10 SYN_RECV src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0

This patch also removes IPCT_REFRESH from the bitmask since it is
not of any use.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>

This patch fixes a problem when you use 32 nodes in the cluster
match:

% iptables -I PREROUTING -t mangle -i eth0 -m cluster \
  --cluster-total-nodes  32  --cluster-local-node  32 \
  --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 0xffff
iptables: Invalid argument. Run `dmesg' for more information.
% dmesg | tail -1
xt_cluster: this node mask cannot be higher than the total number of nodes

The problem is related to this checking:

if (info->node_mask >= (1 << info->total_nodes)) {
	printk(KERN_ERR "xt_cluster: this node mask cannot be "
			"higher than the total number of nodes\n");
	return false;
}

(1 << 32) is 1. Thus, the checking fails.

BTW, I said this before but I insist: I have only tested the cluster
match with 2 nodes getting ~45% extra performance in an active-active setup.
The maximum limit of 32 nodes is still completely arbitrary. I'd really
appreciate if people that have more nodes in their setups let me know.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>

As packets ending with NEXTHDR_NONE don't have a last extension header,
the check for the length needs to be after the check for NEXTHDR_NONE.
Signed-off-by: Christoph Paasch <christoph.paasch@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>

Pointed out by Dave Miller:

  CHECK   include/linux/netfilter (57 files)
/home/davem/src/GIT/net-2.6/usr/include/linux/netfilter/xt_LED.h:6: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: Patrick McHardy <kaber@trash.net>

a recent fix to e1000 (commit 15b2bee2) caused KVM/QEMU/VMware based
virtualized e1000 interfaces to begin failing when resetting.

This is because the driver in a virtual environment doesn't
get to run instructions *AT ALL* when an interrupt is asserted.
The interrupt code runs immediately and this recent bug fix
allows an interrupt to be possible when the interrupt handler
will reject it (due to the new code), when being called from
any path in the driver that holds the E1000_RESETTING flag.

the driver should use the __E1000_DOWN flag instead of the
__E1000_RESETTING flag to prevent interrupt execution
while reconfiguring the hardware.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix locking issue in alb MAC address management; removed
incorrect locking and replaced with correct locking.  This bug was
introduced in commit 059fe7a5
("bonding: Convert locks to _bh, rework alb locking for new locking")

	Bug reported by Paul Smith <paul@mad-scientist.net>, who also
tested the fix.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Due to a semantic changes in flush_workqueue() the current approach of
synchronizing the sysfs handling for connections doesn't work anymore. The
whole approach is actually fully broken and based on assumptions that are
no longer valid.

With the introduction of Simple Pairing support, the creation of low-level
ACL links got changed. This change invalidates the reason why in the past
two independent work queues have been used for adding/removing sysfs
devices. The adding of the actual sysfs device is now postponed until the
host controller successfully assigns an unique handle to that link. So
the real synchronization happens inside the controller and not the host.

The only left-over problem is that some internals of the sysfs device
handling are not initialized ahead of time. This leaves potential access
to invalid data and can cause various NULL pointer dereferences. To fix
this a new function makes sure that all sysfs details are initialized
when an connection attempt is made. The actual sysfs device is only
registered when the connection has been successfully established. To
avoid a race condition with the registration, the check if a device is
registered has been moved into the removal work.

As an extra protection two flush_work() calls are left in place to
make sure a previous add/del work has been completed first.

Based on a report by Marc Pignat <marc.pignat@hevs.ch>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Tested-by: Roger Quadros <ext-roger.quadros@nokia.com>
Tested-by: Marc Pignat <marc.pignat@hevs.ch>

pid doesn't count with some band having more bitrates than the one
associated the first time.
Fix that by counting the maximal available bitrate count and allocate
big enough space.

Secondly, fix touching uninitialized memory which causes panics.
Index sucked from this random memory points to the hell.
The fix is to sort the rates on each band change.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

minstrel doesn't count max rate count in fact, since it doesn't use
a loop variable `i' and hence allocs space only for bitrates found in
the first band.

Fix it by involving the `i' as an index so that it traverses all the
bands now and finds the real max bitrate count.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

During initialization we would not have received any beacons
so skip processing reg beacon hints, also adds a check to
reg_is_world_roaming() for last_request before accessing its
fields.

This should fix this:

BUG: unable to handle kernel NULL pointer dereference at

IP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295

*pdpt = 0000000008bf1001 *pde = 0000000000000000
Oops: 0000 [#1]
last sysfs file: /sys/class/backlight/eeepc/brightness
Modules linked in: ath5k(+) mac80211 led_class cfg80211
go_bit cfbcopyarea cfbimgblt cfbfillrect ipv6
ydev usual_tables(P) snd_hda_codec_realtek snd_hda_intel
nd_hwdep uhci_hcd snd_pcm_oss snd_mixer_oss i2c_i801
e serio_raw i2c_core pcspkr atl2 snd_pcm intel_agp
re agpgart eeepc_laptop snd_page_alloc ac video backlight
rfkill button processor evdev thermal fan ata_generic

Pid: 2909, comm: modprobe Tainted: Pc #112) 701
EIP: 0060:[<e0171332>] EFLAGS: 00010246 CPU: 0
EIP is at wiphy_update_regulatory+0x20f/0x295 [cfg80211]
EAX: 00000000 EBX: c5da0000 ECX: 00000000 EDX: c5da0060
ESI: 0000001a EDI: c5da0060 EBP: df3bdd70 ESP: df3bdd40
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process modprobe (pid: 2909, ti=df3bc000 task=c5d030000)
Stack:
 df3bdd90 c5da0060 c04277e0 00000001 00000044 c04277e402
 00000002 c5da0000 0000001a c5da0060 df3bdda8 e01706a2 02
 00000282 000080d0 00000068 c5d53500 00000080 0000028240
Call Trace:
 [<e01706a2>] ? wiphy_register+0x122/0x1b7 [cfg80211]
 [<e0328e02>] ? ieee80211_register_hw+0xd8/0x346
 [<e06a7c9f>] ? ath5k_hw_set_bssid_mask+0x71/0x78 [ath5k]
 [<e06b0c52>] ? ath5k_pci_probe+0xa5c/0xd0a [ath5k]
 [<c01a6037>] ? sysfs_find_dirent+0x16/0x27
 [<c01fec95>] ? local_pci_probe+0xe/0x10
 [<c01ff526>] ? pci_device_probe+0x48/0x66
 [<c024c9fd>] ? driver_probe_device+0x7f/0xf2
 [<c024cab3>] ? __driver_attach+0x43/0x5f
 [<c024c0af>] ? bus_for_each_dev+0x39/0x5a
 [<c024c8d0>] ? driver_attach+0x14/0x16
 [<c024ca70>] ? __driver_attach+0x0/0x5f
 [<c024c5b3>] ? bus_add_driver+0xd7/0x1e7
 [<c024ccb9>] ? driver_register+0x7b/0xd7
 [<c01ff827>] ? __pci_register_driver+0x32/0x85
 [<e00a8018>] ? init_ath5k_pci+0x18/0x30 [ath5k]
 [<c0101131>] ? _stext+0x49/0x10b
 [<e00a8000>] ? init_ath5k_pci+0x0/0x30 [ath5k]
 [<c012f452>] ? __blocking_notifier_call_chain+0x40/0x4c
 [<c013a714>] ? sys_init_module+0x87/0x18b
 [<c0102804>] ? sysenter_do_call+0x12/0x22
Code: b8 da 17 e0 83 c0 04 e8 92 f9 ff ff 84 c0 75 2a 8b
85 c0 74 0c 83 c0 04 e8 7c f9 ff ff 84 c0 75 14 a1 bc da
4 03 74 66 8b 4d d4 80 79 08 00 74 5d a1 e0 d2 17 e0 48
EIP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295
SP 0068:df3bdd40
CR2: 0000000000000004
---[ end trace 830f2dd2a95fd1a8 ]---

This issue is hard to reproduce, but it was noticed and discussed on
this thread:

http://marc.info/?t=123938022700005&r=1&w=2

Cc: stable@kernel.org
Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We forgot to lock using the cfg80211_mutex in
wiphy_apply_custom_regulatory(). Without the lock
there is possible race between processing a reply from CRDA
and a driver calling wiphy_apply_custom_regulatory(). During
the processing of the reply from CRDA we free last_request and
wiphy_apply_custom_regulatory() eventually accesses an
element from last_request in the through freq_reg_info_regd().

This is very difficult to reproduce (I haven't), it takes us
3 hours and you need to be banging hard, but the race is obvious
by looking at the code.

This should only affect those who use this caller, which currently
is ath5k, ath9k, and ar9170.

EIP: 0060:[<f8ebec50>] EFLAGS: 00210282 CPU: 1
EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211]
EAX: 00000000 EBX: f7ca0060 ECX: f5183d94 EDX: 0024cde0
ESI: f8f56edc EDI: 00000000 EBP: 00000000 ESP: f5183d44
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 14617, ti=f5182000 task=f3934d10 task.ti=f5182000)
Stack: c0505300 f7ca0ab4 f5183d94 0024cde0 f8f403a6 f8f63160 f7ca0060 00000000
00000000 f8ebedf8 f5183d90 f8f56edc 00000000 00000004 00000f40 f8f56edc
f7ca0060 f7ca1234 00000000 00000000 00000000 f7ca14f0 f7ca0ab4 f7ca1289
Call Trace:
[<f8ebedf8>] wiphy_apply_custom_regulatory+0x8f/0x122 [cfg80211]
[<f8f3f798>] ath_attach+0x707/0x9e6 [ath9k]
[<f8f45e46>] ath_pci_probe+0x18d/0x29a [ath9k]
[<c023c7ba>] pci_device_probe+0xa3/0xe4
[<c02a860b>] really_probe+0xd7/0x1de
[<c02a87e7>] __driver_attach+0x37/0x55
[<c02a7eed>] bus_for_each_dev+0x31/0x57
[<c02a83bd>] driver_attach+0x16/0x18
[<c02a78e6>] bus_add_driver+0xec/0x21b
[<c02a8959>] driver_register+0x85/0xe2
[<c023c9bb>] __pci_register_driver+0x3c/0x69
[<f8e93043>] ath9k_init+0x43/0x68 [ath9k]
[<c010112b>] _stext+0x3b/0x116
[<c014a872>] sys_init_module+0x8a/0x19e
[<c01049ad>] sysenter_do_call+0x12/0x21
[<ffffe430>] 0xffffe430
=======================
Code: 0f 94 c0 c3 31 c0 c3 55 57 56 53 89 c3 83 ec 14 8b 74 24 2c 89 54 24 0c 89 4c 24 08 85 f6 75
06 8b 35 c8 bb ec f8 a1 cc bb ec f8 <8b> 40 04 83 f8 03 74 3a 48 74 37 8b 43 28 85 c0 74 30 89 c6
8b
EIP: [<f8ebec50>] freq_reg_info_regd+0x24/0x121 [cfg80211] SS:ESP 0068:f5183d44

Cc: stable@kernel.org
Reported-by: Nataraj Sadasivam <Nataraj.Sadasivam@Atheros.com>
Reported-by: Vivek Natarajan <Vivek.Natarajan@Atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We need to be symmetrical in what is done when key is set and cleared.
This is important wrt the key flags as they are used during key
clearing and if they are not set when the key is set the key cannot be
cleared completely.

This addresses the many occurences of the WARN found in
iwl_set_tkip_dynamic_key_info() and tracked in
http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key

If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key()
pair a few times in a row will cause that we run out of key space.
This is because the index stored in the key flags is used by
iwl_remove_dynamic_key() to decide if it should remove the key.
Unfortunately the key flags, and hence the key index is currently only
set at the time the key is written to the device (in
iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info().
Fix this by setting flags in iwl_set_tkip_dynamic_key_info().
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Another bug in the "cfg80211: do not replace BSS structs" patch,
a forgotten length update leads to bogus data being stored and
passed to userspace, often truncated.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The fragmentation threshold is defined to be including the
FCS, and the code that sets the TX_FRAGMENTED flag correctly
accounts for those four bytes. The code that verifies this
doesn't though, which could lead to spurious warnings and
frames being dropped although everything is ok. Correct the
code by accounting for the FCS.

(JWL -- The problem is described here:
 http://article.gmane.org/gmane.linux.kernel.wireless.general/32205 )
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

It does not make sense to apply EXPORT_SYMBOL to a static symbol.  Fixes
this build error:

drivers/net/wireless/iwlwifi/iwl3945-base.c:1697: error: __ksymtab_iwl3945_rx_queue_reset causes a section type conflict
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This introduces a CDC Ethernet Emulation Model (EEM) host side
driver to support USB EEM devices.

EEM is different from the Ethernet Control Model (ECM) currently
supported by the "CDC Ethernet" driver.  One key difference is
that it doesn't require of USB interface alternate settings to
manage interface state; some maldesigned hardware can't handle
that part of USB.  It also avoids a separate USB interface for
control and status updates.

[ dbrownell@users.sourceforge.net: fix skb leaks, add rx packet
checks, improve fault handling, EEM conformance updates, cleanup ]
Signed-off-by: Omar Laazimani <omar.oberthur@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

tcp_prequeue() refers to the constant value (TCP_RTO_MIN) regardless of
the actual value might be tuned. The following patches fix this and make
tcp_prequeue get the actual value returns from tcp_rto_min().
Signed-off-by: Satoru SATOH <satoru.satoh@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch fixes an invalid pointer access in case the receive queue
holds no pointer to the next skb when the queue is empty.
Signed-off-by: Hannes Hering <hering2@de.ibm.com>
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Doing it in reverse order causes uevent to be sent before
we have a MAC address, which confuses udev.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Commit 0ba25ff4 ("br2684: convert to
net_device_ops") inadvertently deleted the initialization of the net_dev
pointer in the br2684_dev structure, leading to crashes.  This patch
adds it back.
Reported-by: Mikko Vinni <mmvinni@yahoo.com>
Tested-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: David S. Miller <davem@davemloft.net>

The kernel should only be using the high 16 bits of a kernel
generated priority. Filter priorities in all other cases only
use the upper 16 bits of the u32 'prio' field of 'struct tcf_proto',
but when the kernel generates the priority of a filter is saves all
32 bits which can result in incorrect lookup failures when a filter
needs to be deleted or modified.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>