b43: Fix warning at drivers/mmc/core/core.c:237 in mmc_wait_for_cmd

commit 9f2a0fac625bcef9c579bcf0b0c904ab1a56e7c4 upstream.

On module removal, the sdio version of b43 generates the following warning:

[  851.560519] ------------[ cut here ]------------
[  851.560531] WARNING: at drivers/mmc/core/core.c:237 mmc_wait_for_cmd+0x88/0x90()
[  851.560534] Hardware name: 20552PG
[  851.560536] Modules linked in: b43(-) ssb mmc_block binfmt_misc rfcomm sco bnep ppdev l2cap ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel kvm arc4 iwlagn snd_hda_codec_conexant snd_hda_intel snd_hda_codec iwlcore snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq r852 joydev snd_timer sm_common pcmcia nand snd_seq_device cfg80211 sdhci_pci btusb psmouse tpm_tis yenta_socket nand_ids lp snd pcmcia_rsrc nand_ecc bluetooth sdhci tpm pcmcia_core parport mtd snd_page_alloc serio_raw tpm_bios soundcore nvram led_class sha256_generic aes_i586 aes_generic dm_crypt i915 drm_kms_helper drm ahci intel_agp i2c_algo_bit intel_gtt e1000e libahci video agpgart output
[  851.560620] Pid: 2504, comm: rmmod Not tainted 2.6.36-titan0+ #1
[  851.560622] Call Trace:
[  851.560631]  [<c014a102>] warn_slowpath_common+0x72/0xa0
[  851.560636]  [<c04d94c8>] ? mmc_wait_for_cmd+0x88/0x90
[  851.560641]  [<c04d94c8>] ? mmc_wait_for_cmd+0x88/0x90
[  851.560645]  [<c014a152>] warn_slowpath_null+0x22/0x30
[  851.560649]  [<c04d94c8>] mmc_wait_for_cmd+0x88/0x90
[  851.560655]  [<c0401585>] ? device_release+0x25/0x80
[  851.560660]  [<c04df210>] mmc_io_rw_direct_host+0xa0/0x150
[  851.560665]  [<c04df370>] mmc_io_rw_direct+0x30/0x40
[  851.560669]  [<c04e06e7>] sdio_disable_func+0x37/0xa0
[  851.560683]  [<f8dfcb80>] b43_sdio_remove+0x30/0x50 [b43]
[  851.560687]  [<c04df8cc>] sdio_bus_remove+0x1c/0x60
[  851.560692]  [<c016d39f>] ? blocking_notifier_call_chain+0x1f/0x30
[  851.560697]  [<c0404991>] __device_release_driver+0x51/0xb0
[  851.560701]  [<c0404a7f>] driver_detach+0x8f/0xa0
[  851.560705]  [<c0403c83>] bus_remove_driver+0x63/0xa0
[  851.560709]  [<c0405039>] driver_unregister+0x49/0x80
[  851.560713]  [<c0405039>] ? driver_unregister+0x49/0x80
[  851.560718]  [<c04dfad7>] sdio_unregister_driver+0x17/0x20
[  851.560727]  [<f8dfcb42>] b43_sdio_exit+0x12/0x20 [b43]
[  851.560734]  [<f8dfe76f>] b43_exit+0x17/0x3c [b43]
[  851.560740]  [<c017fb8d>] sys_delete_module+0x13d/0x200
[  851.560747]  [<c01fd7d2>] ? do_munmap+0x212/0x300
[  851.560752]  [<c010311f>] sysenter_do_call+0x12/0x28
[  851.560757] ---[ end trace 31e14488072d2f7d ]---
[  851.560759] ------------[ cut here ]------------

The warning is caused by b43 not claiming the device before calling
sdio_disable_func().

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Arnd Hannemann <arnd@arndnet.de>
Tested-by: Arnd Hannemann <arnd@arndnet.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
econet: Fix redeclaration of symbol len

commit 9e8342971d44ce86d8567047f5366fc1c06a75ed upstream.

Function argument len was redeclarated within the
function. This patch fix the redeclaration of symbol 'len'.

Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Adjusted to apply to 2.6.32 by dann frazier <dannf@debian.org>]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
econet: fix CVE-2010-3848

commit a27e13d370415add3487949c60810e36069a23a6 upstream.

Don't declare variable sized array of iovecs on the stack since this
could cause stack overflow if msg->msgiovlen is large.  Instead, coalesce
the user-supplied data into a new buffer and use a single iovec for it.

Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Adjusted to apply to 2.6.32 by dann frazier <dannf@debian.org>]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
econet: fix CVE-2010-3848

commit a27e13d370415add3487949c60810e36069a23a6 upstream.

Don't declare variable sized array of iovecs on the stack since this
could cause stack overflow if msg->msgiovlen is large.  Instead, coalesce
the user-supplied data into a new buffer and use a single iovec for it.

Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Adjusted to apply to 2.6.32 by dann frazier <dannf@debian.org>]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
dell-laptop: Add another Dell laptop to the DMI whitelist

commit cb6a7937f4328a267e0806680ade500ed2c3c01a upstream.

The Latitude C640 has another variation of dell in its DMI vendor entry.
Add it to the whitelist in order to enjoy the sweet fruits of software
backlight toggling.

Signed-off-by: Erik Andren <erik.andren@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
dell-laptop: Add another Dell laptop family to the DMI whitelist

commit 410d44c74cf9942e3055d5b7d73953fac8efbacb upstream.

This is to support Precision M4500 and others.

Signed-off-by: Rezwanul Kabir <Rezwanul_Kabir@dell.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
scsi_dh_emc: fix mode select request setup

commit 6c71dcb28ff9b63b814a0b76a256f5dae08d3e0d upstream.

This patch fixes the request setup code for mode selects. I got the fixes from
Hannes Reinecke while trying to hunt down some problems and merged it
into one patch. I am sending it because Hannes is busy with other things.

The patch fixes:
- setting of the length for mode selects.
- setting of the data direction for mode select 10.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
scsi_dh_emc: request flag cleanup

commit 5738d4449c1baf05e8345684d12371f76296473d upstream.

blk_get_request sets the cmd_flags, so we should not and do not
need to set them. If we did set them to a different value then
it can cause a oops in the elevator code.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cifs: fix another memleak, in cifs_root_iget

commit a7851ce73b9fdef53f251420e6883cf4f3766534 upstream.

cifs_root_iget allocates full_path through
cifs_build_path_to_root, but fails to kfree it upon
cifs_get_inode_info* failure.

Make all failure exit paths traverse clean up
handling at the end of the function.

Signed-off-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Reviewed-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e1000e: Reset 82577/82578 PHY before first PHY register read

commit 627c8a041f7aaaea93c766f69bd61d952a277586 upstream.

Reset the PHY before first accessing it.  Doing so, ensure that the PHY is
in a known good state before we read/write PHY registers. This fixes a
driver probe failure.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Backported to 2.6.32 by dann frazier <dannf@debian.org>]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e1000: fix Tx hangs by disabling 64-bit DMA

commit e508be174ad36b0cf9b324cd04978c2b13c21502 upstream.

Several users report issues with 32-bit adapters when plugged
into PCI slots in machines with >= 4GB ram.  In particular AMD
systems with HyperTransport to PCI bridges seem to trigger the
issue, but it isn't limited to only them.

This issue is not easily reproducible here, yet still continues
to occur in the field.  For e1000 on PCI devices, just disable DMA
addresses over the 4GB boundary when in PCI (not PCI-X) mode, to
prevent the issue from continuing to pop up.  The performance
impact for this is negligible.

The code was refactored to move the init of the hw struct to its
own function. This allows the init to be called very early in
probe, which then allows using hw-> members for this fix.

A slight refactor to the DMA mask code was done for minor
correctness based on the instructions in DMA-API-HOWTO.

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>
[bwh: Adjust for 2.6.32]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
btrfs: Require CAP_SYS_ADMIN for filesystem rebalance

commit 6f88a4403def422bd8e276ddf6863d6ac71435d2 upstream.

Filesystem rebalancing (BTRFS_IOC_BALANCE) affects the entire
filesystem and may run uninterruptibly for a long time.  This does not
seem to be something that an unprivileged user should be able to do.

Reported-by: Aron Xu <happyaron.xu@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
af_unix: limit recursion level

commit 25888e30319f8896fc656fc68643e6a078263060 upstream.

Its easy to eat all kernel memory and trigger NMI watchdog, using an
exploit program that queues unix sockets on top of others.

lkml ref : http://lkml.org/lkml/2010/11/25/8

This mechanism is used in applications, one choice we have is to have a
recursion limit.

Other limits might be needed as well (if we queue other types of files),
since the passfd mechanism is currently limited by socket receive queue
sizes only.

Add a recursion_level to unix socket, allowing up to 4 levels.

Each time we send an unix socket through sendfd mechanism, we copy its
recursion level (plus one) to receiver. This recursion level is cleared
when socket receive queue is emptied.

Reported-by: Марк Коренберг <socketpair@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Adjust for 2.6.32]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
af_unix: limit unix_tot_inflight

commit 9915672d41273f5b77f1b3c29b391ffb7732b84b upstream.

Vegard Nossum found a unix socket OOM was possible, posting an exploit
program.

My analysis is we can eat all LOWMEM memory before unix_gc() being
called from unix_release_sock(). Moreover, the thread blocked in
unix_gc() can consume huge amount of time to perform cleanup because of
huge working set.

One way to handle this is to have a sensible limit on unix_tot_inflight,
tested from wait_for_unix_gc() and to force a call to unix_gc() if this
limit is hit.

This solves the OOM and also reduce overall latencies, and should not
slowdown normal workloads.

Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
init, sched: Fix race between init and kthreadd

commit b433c3d4549ae74935b585115f076c6fb7bc48fe upstream.

Ilya reported that on a very slow machine he could reliably
reproduce a race between forking init and kthreadd. We first
fork init so that it  obtains pid-1, however since the scheduler
is already fully running at this point it can preempt and run
the init thread before we spawn and set kthreadd_task.

The init thread can then attempt spawning kthreads without
kthreadd being present which results in an OOPS.

Reported-by: Ilya Loginov <isloginov@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <1277736661.3561.110.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
backlight: MacBookAir3,1(3,2) mbp-nvidia-bl support

commit bd760e1e5b34351e0705705e5163cb89c1316d71 upstream.

Add support for the MacBookAir3,1 and MacBookAir3,2 to the mbp-nvidia-bl
driver.

Signed-off-by: Edgar (gimli) Hucek <gimli@dark-green.com>
Acked-by: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bonding: Ensure that we unshare skbs prior to calling pskb_may_pull

commit b30532515f0a62bfe17207ab00883dd262497006 upstream.

Recently reported oops:

kernel BUG at net/core/skbuff.c:813!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/net/bond0/broadcast
CPU 8
Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
scsi_transport_sas dm_mod [last unloaded: microcode]

Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
scsi_transport_sas dm_mod [last unloaded: microcode]
Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22
-[7870AC1]-
RIP: 0010:[<ffffffff81405b16>]  [<ffffffff81405b16>]
pskb_expand_head+0x36/0x1e0
RSP: 0018:ffff880028303b70  EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80
RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64
R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000
R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0)
Stack:
 ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000
<0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00
<0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a
Call Trace:
<IRQ>
 [<ffffffff8104fff9>] ? __wake_up_common+0x59/0x90
 [<ffffffff81407f7a>] __pskb_pull_tail+0x2aa/0x360
 [<ffffffffa0244530>] bond_arp_rcv+0x2c0/0x2e0 [bonding]
 [<ffffffff814a0857>] ? packet_rcv+0x377/0x440
 [<ffffffff8140f21b>] netif_receive_skb+0x2db/0x670
 [<ffffffff8140f788>] napi_skb_finish+0x58/0x70
 [<ffffffff8140fc89>] napi_gro_receive+0x39/0x50
 [<ffffffffa01286eb>] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe]
 [<ffffffffa01290f6>] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe]
 [<ffffffff8140fe53>] net_rx_action+0x103/0x210
 [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0
 [<ffffffff810d8740>] ? handle_IRQ_event+0x60/0x170
 [<ffffffff810142cc>] call_softirq+0x1c/0x30
 [<ffffffff81015f35>] do_softirq+0x65/0xa0
 [<ffffffff810739d5>] irq_exit+0x85/0x90
 [<ffffffff814cf915>] do_IRQ+0x75/0xf0
 [<ffffffff81013ad3>] ret_from_intr+0x0/0x11
 <EOI>
 [<ffffffff8101bc01>] ? mwait_idle+0x71/0xd0
 [<ffffffff814cd80a>] ? atomic_notifier_call_chain+0x1a/0x20
 [<ffffffff81011e96>] cpu_idle+0xb6/0x110
 [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f

Resulted from bonding driver registering packet handlers via dev_add_pack and
then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET
sockets) gets called first, the delivered skb will have a user count > 1, which
causes pskb_may_pull to BUG halt when it does its skb_shared check.  Fix this by
calling skb_share_check prior to the may_pull call sites in the bonding driver
to clone the skb when needed.  Tested by myself and the reported successfully.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
HID: add MacBookAir 3,1 and 3,2 support

commit 99b9f758bbc904f22faffcf4d83205f4a5e7bc0c upstream.

This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the hid
driver.

Signed-off-by: Edgar (gimli) Hucek <gimli@dark-green.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
intel-iommu: Force-disable IOMMU for iGFX on broken Cantiga revisions.

commit 2d9e667efdfb4e986074d98e7d9a424003c7c43b upstream.

Certain revisions of this chipset appear to be broken. There is a shadow
GTT which mirrors the real GTT but contains pre-translated physical
addresses, for performance reasons. When a GTT update happens, the
translations are done once and the resulting physical addresses written
back to the shadow GTT.

Except sometimes, the physical address is actually written back to the
_real_ GTT, not the shadow GTT. Thus we start to see faults when that
physical address is fed through translation again.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ipg: Remove device claimed by dl2k from pci id table

commit 25cca5352712561fba97bd37c495593d641c1d39 upstream.

This patch removes D-Link DGE-550T PCI ID (1186:4000) from the ipg
driver. The ipg driver is for IP2000-based cards and the DGE-550T is
a DL2000-based card. The driver loads and works for a few moments, but
once a real workload is applied it stops operating. The ipg driver
claimed this ID since it was introduced in 2.6.24 and it's forced many
users to blacklist it.

The correct driver for this hardware is the dl2k driver, which has been
claiming this PCI ID since the 2.4 days.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>