commit dda1cd590f026ee78b6aa9efbb32f7e67304f712
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Mon May 7 08:55:30 2012 -0700
Linux 3.3.5
commit 9af2cbfa4d8279d29a7881079c9270f43e61ade7
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri May 4 12:09:39 2012 -0700
hfsplus: Fix potential buffer overflows
commit 6f24f892871acc47b40dd594c63606a17c714f77 upstream.
Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few
potential buffer overflows in the hfs filesystem. But as Timo Warns
pointed out, these changes also need to be made on the hfsplus
filesystem as well.
Reported-by: Timo Warns <warns@pre-sense.de>
Acked-by: WANG Cong <amwang@redhat.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Sage Weil <sage@newdream.net>
Cc: Eugene Teo <eteo@redhat.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Dave Anderson <anderson@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
commit 32ff66c2368d12c815d4a2a290c0e6825e6eb024
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Wed Apr 25 08:10:08 2012 -0700
iwlwifi: use 6000G2B for 6030 device series
commit 1ed2ec37b44e86eaa8e0a03b908a39c80f65ee45 upstream.
"iwlwifi: use correct released ucode version" change
the ucode api ok from 6000G2 to 6000G2B, but it shall belong
to 6030 device series, not the 6005 device series. Fix it
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4308e17eee55ef3ff85da506e80902e3bc1b6c2
Author: Johannes Berg <johannes.berg@intel.com>
Date: Mon Apr 23 14:17:50 2012 -0700
iwlwifi: fix hardware queue programming
commit 5ef4acd58ab2abd0dd0c8e3cacd61a0dc5d73646 upstream.
Newer devices have 20 (5000 series) or 30 (6000 series)
hardware queues, rather than the 16 that 4965 had. This
was added to the driver a long time ago, but improperly:
the queue registers for the higher queues aren't just
continuations of the registers for the first 16 queues,
they are in other places. Therefore, the hardware would
lock up when trying to activate queue 16 or above and
the device would have to be restarted.
Thanks goes to Emmanuel who identified this and told me
how the queue programming should be done.
Note that we don't use queues 20 and higher today and
doing so needs more work than this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a2c73fba70c4b59b0060a80c634912af12a8bd2
Author: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Date: Sun Apr 22 07:55:27 2012 -0700
iwlwifi: use correct released ucode version
commit 78cbcf2b9dbe0565820dc7721316f9c401000a68 upstream.
Report correctly the latest released version
of the iwlwifi firmware for all
iwlwifi-supported devices.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8aef975a543c0d567dc2fe2eb527dd1f5cfc1e72
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Wed Apr 18 08:01:15 2012 -0700
iwlwifi: do not nulify ctx->vif on reset
commit 8db4c7e25d153fb049e81715d72fa3be3a0c3b69 upstream.
ctx->vif is dereferenced in different part of iwlwifi code, so do not
nullify it.
This should address at least one of the possible reasons of WARNING at
iwlagn_mac_remove_interface, and perhaps some random crashes when
firmware reset is performed.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2ba8c996f8fd34e8162b6fab6255a9eb6ad1b893
Author: Grazvydas Ignotas <notasas@gmail.com>
Date: Thu Apr 26 23:07:44 2012 +0300
wl1251: fix crash on remove due to leftover work item
commit 4c1bcdb5a3354b250b82a67549f57ac27a3bb85f upstream.
This driver currently leaves elp_work behind when stopping, which
occasionally results in data corruption because work function ends
up accessing freed memory, typical symptoms of this are various
worker_thread crashes. Fix it by cancelling elp_work.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e45014533b2e8b1c77c988280aa7a63e0c650aee
Author: Grazvydas Ignotas <notasas@gmail.com>
Date: Thu Apr 26 23:07:43 2012 +0300
wl1251: fix crash on remove due to premature kfree
commit 328c32f0f85467af5a6c4c3289e168d9ad2555af upstream.
Currently SDIO glue frees it's own structure before calling
wl1251_free_hw(), which in turn calls ieee80211_unregister_hw().
The later call may result in a need to communicate with the chip
to stop it (as it happens now if the interface is still up before
rmmod), which means calls are made back to the glue, resulting in
freed memory access.
Fix this by freeing glue data last.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01a1b33f017366c65a587f6e93d093d39b76f174
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Thu Apr 19 21:39:06 2012 -0500
rtlwifi: Fix oops on unload
commit 44eb65cfd8da4b9c231238998729e858e963a980 upstream.
Under some circumstances, a PCI-based driver reports the following OOPs:
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP
--snip--
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod
Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP:
0010:[<ffffffffa0418d39>] [<ffffffffa0418d39>]
rtl92ce_get_desc+0x19/0xd0 [rtl8192ce]
--snip--
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid:
19627, threadinfo ffff880050262000, task ffff8801156d5cc0)
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack:
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002
ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282
0000000180150014 ffff880050263fd8 ffff8801176c2810
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8
ffffffff810550e2 00000000000002c0 ffff8801176c0d40
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace:
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [<ffffffffa03348e7>]
_rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi]
--snip--
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48
83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66
66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1
e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP
[<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce]
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP <ffff880050263b58>
Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0
Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace
8636c766dcfbe0e6 ]---
This oops is due to interrupts not being disabled in this particular path.
Reported-by: Dave Airlie <airlied@gmail.com>
Tested-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a8abc1d0160641c79fbaafeedb57506beb3780e4
Author: Felix Fietkau <nbd@openwrt.org>
Date: Sun Apr 29 15:44:16 2012 +0200
mac80211: fix AP mode EAP tx for VLAN stations
commit 66f2c99af3d6f2d0aa1120884cf1c60613ef61c0 upstream.
EAP frames for stations in an AP VLAN are sent on the main AP interface
to avoid race conditions wrt. moving stations.
For that to work properly, sta_info_get_bss must be used instead of
sta_info_get when sending EAP packets.
Previously this was only done for cooked monitor injected packets, so
this patch adds a check for tx->skb->protocol to the same place.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a6aebd63e71e65c0823aa1866062489f85c72a4b
Author: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Date: Thu Apr 19 15:55:09 2012 -0400
ipw2200: Fix race condition in the command completion acknowledge
commit dd447319895d0c0af423e483d9b63f84f3f8869a upstream.
Driver incorrectly validates command completion: instead of waiting
for a command to be acknowledged it continues execution. Most of the
time driver gets acknowledge of the command completion in a tasklet
before it executes the next one. But sometimes it sends the next
command before it gets acknowledge for the previous one. In such a
case one of the following error messages appear in the log:
Failed to send SYSTEM_CONFIG: Already sending a command.
Failed to send ASSOCIATE: Already sending a command.
Failed to send TX_POWER: Already sending a command.
After that you need to reload the driver to get it working again.
This bug occurs during roaming (reported by Sam Varshavchik)
https://bugzilla.redhat.com/show_bug.cgi?id=738508
and machine booting (reported by Tom Gundersen and Mads Kiilerich)
https://bugs.archlinux.org/task/28097
https://bugzilla.redhat.com/show_bug.cgi?id=802106
This patch doesn't fix the delay issue during firmware load.
But at least device now works as usual after boot.
Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c87b1e67044ad344abd900f6ea4adc455b75c752
Author: Roland Stigge <stigge@antcom.de>
Date: Wed Apr 4 10:34:37 2012 +0200
i2c: pnx: Disable clk in suspend
commit 6c557cfee08751d22aed34840f389b846f0f4508 upstream.
In the driver's suspend function, clk_enable() was used instead of
clk_disable(). This is corrected with this patch.
Signed-off-by: Roland Stigge <stigge@antcom.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
[wsa: reworded commit header slightly]
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dcc81764edda16e022c9f0b96324e9efc22525c0
Author: Seth Forshee <seth.forshee@canonical.com>
Date: Wed Apr 25 17:28:00 2012 -0500
b43: only reload config after successful initialization
commit dbdedbdf4fbff3d4962a0786f37aa86dfdc48a7e upstream.
Commit 2a19032 (b43: reload phy and bss settings after core restarts)
introduced an unconditional call to b43_op_config() at the end of
b43_op_start(). When firmware fails to load this can wedge the system.
There's no need to reload the configuration after a failed
initialization anyway, so only make the call if initialization was
successful.
BugLink: http://bugs.launchpad.net/bugs/950295
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d8d813bd3bba242bebad2321ac1569fe79022122
Author: Lin Ming <ming.m.lin@intel.com>
Date: Thu May 3 22:15:07 2012 +0800
libata: skip old error history when counting probe trials
commit 6868225e3e92399068be9a5f1635752d91012ad5 upstream.
Commit d902747("[libata] Add ATA transport class") introduced
ATA_EFLAG_OLD_ER to mark entries in the error ring as cleared.
But ata_count_probe_trials_cb() didn't check this flag and it still
counts the old error history. So wrong probe trials count is returned
and it causes problem, for example, SATA link speed is slowed down from
3.0Gbps to 1.5Gbps.
Fix it by checking ATA_EFLAG_OLD_ER in ata_count_probe_trials_cb().
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f991cdfe593795bd1929dc60aa04e7aa045baea
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Mon Apr 30 09:18:01 2012 -0400
hwmon: (coretemp) fix oops on cpu unplug
commit b704871124b477807966f06789c2b32f2de58bf7 upstream.
coretemp tries to access core_data array beyond bounds on cpu unplug if
core id of the cpu if more than NUM_REAL_CORES-1.
BUG: unable to handle kernel NULL pointer dereference at 000000000000013c
IP: [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp]
PGD 673e5a067 PUD 66e9b3067 PMD 0
Oops: 0000 [#1] SMP
CPU 79
Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter nf_conntrack_ipv4 nf_defrag_ipv4 ip6_tables xt_state nf_conntrack coretemp crc32c_intel asix tpm_tis pcspkr usbnet iTCO_wdt i2c_i801 microcode mii joydev tpm i2c_core iTCO_vendor_support tpm_bios i7core_edac igb ioatdma edac_core dca megaraid_sas [last unloaded: oprofile]
Pid: 3315, comm: set-cpus Tainted: G W 3.4.0-rc5+ #2 QCI QSSC-S4R/QSSC-S4R
RIP: 0010:[<ffffffffa00159af>] [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp]
RSP: 0018:ffff880472fb3d48 EFLAGS: 00010246
RAX: 0000000000000124 RBX: 0000000000000034 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246
RBP: ffff880472fb3d88 R08: ffff88077fcd36c0 R09: 0000000000000001
R10: ffffffff8184bc48 R11: 0000000000000000 R12: ffff880273095800
R13: 0000000000000013 R14: ffff8802730a1810 R15: 0000000000000000
FS: 00007f694a20f720(0000) GS:ffff88077fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000013c CR3: 000000067209b000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process set-cpus (pid: 3315, threadinfo ffff880472fb2000, task ffff880471fa0000)
Stack:
ffff880277b4c308 0000000000000003 ffff880472fb3d88 0000000000000005
0000000000000034 00000000ffffffd1 ffffffff81cadc70 ffff880472fb3e14
ffff880472fb3dc8 ffffffff8161f48d ffff880471fa0000 0000000000000034
Call Trace:
[<ffffffff8161f48d>] notifier_call_chain+0x4d/0x70
[<ffffffff8107f1be>] __raw_notifier_call_chain+0xe/0x10
[<ffffffff81059d30>] __cpu_notify+0x20/0x40
[<ffffffff815fa251>] _cpu_down+0x81/0x270
[<ffffffff815fa477>] cpu_down+0x37/0x50
[<ffffffff815fd6a3>] store_online+0x63/0xc0
[<ffffffff813c7078>] dev_attr_store+0x18/0x30
[<ffffffff811f02cf>] sysfs_write_file+0xef/0x170
[<ffffffff81180443>] vfs_write+0xb3/0x180
[<ffffffff8118076a>] sys_write+0x4a/0x90
[<ffffffff816236a9>] system_call_fastpath+0x16/0x1b
Code: 48 c7 c7 94 60 01 a0 44 0f b7 ac 10 ac 00 00 00 31 c0 e8 41 b7 5f e1 41 83 c5 02 49 63 c5 49 8b 44 c4 10 48 85 c0 74 56 45 31 ff <39> 58 18 75 4e eb 1f 49 63 d7 4c 89 f7 48 89 45 c8 48 6b d2 28
RIP [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp]
RSP <ffff880472fb3d48>
CR2: 000000000000013c
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f24f9104f70cabc2534b16f94149d33127d249d5
Author: Dave Airlie <airlied@redhat.com>
Date: Wed May 2 20:26:24 2012 +0100
nouveau: initialise has_optimus variable.
commit addde4ec31456c5f1e9b61aae3edcfeb0f338f87 upstream.
We should initialise this to 0 really to avoid getting false positives.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1d6ec3a7ad57db0a71694aed3a37d9a89870d4b6
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Date: Tue May 1 08:15:42 2012 -0700
hwmon: (coretemp) Increase CPU core limit
commit bdc71c9a87b898e4c380c23b2e3e18071312ecde upstream.
CPU core ID is used to index the core_data[] array. The core ID is, however, not
sequential; 10-core CPUS can have a core ID as high as 25. Increase the limit to
32 to be able to deal with current CPUs.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a300c6a9c5f865eb559ed8e1096e24daa891cb72
Author: Matthew Garrett <mjg@redhat.com>
Date: Thu May 3 16:50:46 2012 -0400
efivars: Improve variable validation
commit 54b3a4d311c98ad94b737802a8b5f2c8c6bfd627 upstream.
Ben Hutchings pointed out that the validation in efivars was inadequate -
most obviously, an entry with size 0 would server as a DoS against the
kernel. Improve this based on his suggestions.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a10afa7444b9fafa9b13bd4d82c9eb093f09bc9
Author: majianpeng <majianpeng@gmail.com>
Date: Mon Apr 2 01:16:59 2012 +1000
md/raid5: Fix a bug about judging if the operation is syncing or replacing
commit c6d2e084c7411f61f2b446d94989e5aaf9879b0f upstream.
When create a raid5 using assume-clean and echo check or repair to
sync_action.Then component disks did not operated IO but the raid
check/resync faster than normal.
Because the judgement in function analyse_stripe():
if (do_recovery ||
sh->sector >= conf->mddev->recovery_cp)
s->syncing = 1;
else
s->replacing = 1;
When check or repair,the recovery_cp == MaxSectore,so syncing equal zero
not one.
This bug was introduced by commit 9a3e1101b827
md/raid5: detect and handle replacements during recovery.
so this patch is suitable for 3.3-stable.
Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 59a49b056b6f7a0207cbde94c7163ed365be82e1
Author: Oleg Nesterov <oleg@redhat.com>
Date: Mon Mar 19 17:03:41 2012 +0100
exit_signal: fix the "parent has changed security domain" logic
commit b6e238dceed36891cc633167afe7151f1f3d83c5 upstream.
exit_notify() changes ->exit_signal if the parent already did exec.
This doesn't really work, we are not going to send the signal now
if there is another live thread or the exiting task is traced. The
parent can exec before the last dies or the tracer detaches.
Move this check into do_notify_parent() which actually sends the
signal.
The user-visible change is that we do not change ->exit_signal,
and thus the exiting task is still "clone children" for
do_wait()->eligible_child(__WCLONE). Hopefully this is fine, the
current logic is racy anyway.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f799aa1565fc056504ba7473a09e8f0dee3a20b7
Author: Oleg Nesterov <oleg@redhat.com>
Date: Mon Mar 19 17:03:22 2012 +0100
exit_signal: simplify the "we have changed execution domain" logic
commit e636825346b36a07ccfc8e30946d52855e21f681 upstream.
exit_notify() checks "tsk->self_exec_id != tsk->parent_exec_id"
to handle the "we have changed execution domain" case.
We can change do_thread() to always set ->exit_signal = SIGCHLD
and remove this check to simplify the code.
We could change setup_new_exec() instead, this looks more logical
because it increments ->self_exec_id. But note that de_thread()
already resets ->exit_signal if it changes the leader, let's keep
both changes close to each other.
Note that we change ->exit_signal lockless, this changes the rules.
Thereafter ->exit_signal is not stable under tasklist but this is
fine, the only possible change is OLDSIG -> SIGCHLD. This can race
with eligible_child() but the race is harmless. We can race with
reparent_leader() which changes our ->exit_signal in parallel, but
it does the same change to SIGCHLD.
The noticeable user-visible change is that the execing task is not
"visible" to do_wait()->eligible_child(__WCLONE) right after exec.
To me this looks more logical, and this is consistent with mt case.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6b7b95e774e2e2b32631511ad7d4c2256f1b3162
Author: Peter Zijlstra <peterz@infradead.org>
Date: Thu Mar 1 15:04:46 2012 +0100
sched: Fix nohz load accounting -- again!
commit c308b56b5398779cd3da0f62ab26b0453494c3d4 upstream.
Various people reported nohz load tracking still being wrecked, but Doug
spotted the actual problem. We fold the nohz remainder in too soon,
causing us to loose samples and under-account.
So instead of playing catch-up up-front, always do a single load-fold
with whatever state we encounter and only then fold the nohz remainder
and play catch-up.
Reported-by: Doug Smythies <dsmythies@telus.net>
Reported-by: LesÃ…=82aw Kope=C4=87 <leslaw.kopec@nasza-klasa.pl>
Reported-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-4v31etnhgg9kwd6ocgx3rxl8@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Kerin Millar <kerframil@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4da7d6143870a2f81ceaeabdc64e0f74121e35b3
Author: Bojan Smojver <bojan@rexursive.com>
Date: Tue Apr 24 23:53:28 2012 +0200
PM / Hibernate: fix the number of pages used for hibernate/thaw buffering
commit f8262d476823a7ea1eb497ff9676d1eab2393c75 upstream.
Hibernation regression fix, since 3.2.
Calculate the number of required free pages based on non-high memory
pages only, because that is where the buffers will come from.
Commit 081a9d043c983f161b78fdc4671324d1342b86bc introduced a new buffer
page allocation logic during hibernation, in order to improve the
performance. The amount of pages allocated was calculated based on total
amount of pages available, although only non-high memory pages are
usable for this purpose. This caused hibernation code to attempt to over
allocate pages on platforms that have high memory, which led to hangs.
Signed-off-by: Bojan Smojver <bojan@rexursive.com>
Signed-off-by: Rafael J. Wysocki <rjw@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da42136018f3a2e187ab1976f7f0a5768c3bda24
Author: Timur Tabi <timur@freescale.com>
Date: Wed Nov 30 10:19:17 2011 -0600
powerpc/85xx: don't call of_platform_bus_probe() twice
commit 8a95bc8dfe06982fc2b8a0a2adda7baa2346a17b upstream.
Commit 46d026ac ("powerpc/85xx: consolidate of_platform_bus_probe calls")
replaced platform-specific of_device_id tables with a single function
that probes the most of the busses in 85xx device trees. If a specific
platform needed additional busses probed, then it could call
of_platform_bus_probe() again. Typically, the additional platform-specific
busses are children of existing busses that have already been probed.
of_platform_bus_probe() does not handle those child busses automatically.
Unfortunately, this doesn't actually work. The second (platform-specific)
call to of_platform_bus_probe() never finds any of the busses it's asked
to find.
To remedy this, the platform-specific of_device_id tables are eliminated,
and their entries are merged into mpc85xx_common_ids[], so that all busses
are probed at once.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50d61918ff77bd2e0355c124e73595cdea3fa177
Author: Matt Fleming <matt.fleming@intel.com>
Date: Sun Apr 15 16:06:04 2012 +0100
x86, efi: Add dedicated EFI stub entry point
commit b1994304fc399f5d3a5368c81111d713490c4799 upstream.
The method used to work out whether we were booted by EFI firmware or
via a boot loader is broken. Because efi_main() is always executed
when booting from a boot loader we will dereference invalid pointers
either on the stack (CONFIG_X86_32) or contained in %rdx
(CONFIG_X86_64) when searching for an EFI System Table signature.
Instead of dereferencing these invalid system table pointers, add a
new entry point that is only used when booting from EFI firmware, when
we know the pointer arguments will be valid. With this change legacy
boot loaders will no longer execute efi_main(), but will instead skip
EFI stub initialisation completely.
[ hpa: Marking this for urgent/stable since it is a regression when
the option is enabled; without the option the patch has no effect ]
Signed-off-by: Matt Fleming <matt.hfleming@intel.com>
Link: http://lkml.kernel.org/r/1334584744.26997.14.camel@mfleming-mobl1.ger.corp.intel.com
Reported-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7229d3aea8bd7b60eaad158c2b9e749fff41940b
Author: H. Peter Anvin <hpa@zytor.com>
Date: Thu Mar 22 11:08:18 2012 -0700
x86, boot: Correct CFLAGS for hostprogs
commit 446e1c86d51d0823e003a43a2b85c430efce2733 upstream.
This is a partial revert of commit:
d40f833 "Restrict CFLAGS for hostprogs"
The endian-manipulation macros in tools/include need <linux/types.h>,
but the hostprogs in arch/x86/boot need several headers from the
kernel build tree, which means we have to add the kernel headers to
the include path. This picks up <linux/types.h> from the kernel tree,
which gives a warning.
Since this use of <linux/types.h> is intentional, add
-D__EXPORTED_HEADERS__ to the command line to silence the warning.
A better way to fix this would be to always install the exported
kernel headers into $(objtree)/usr/include as a standard part of the
kernel build, but that is a lot more involved.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-5-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 82c4c5d001608a9a3194bdf74fba824e1c2ec686
Author: Matt Fleming <matt.fleming@intel.com>
Date: Tue Feb 28 13:37:24 2012 +0000
x86, efi: Fix endian issues and unaligned accesses
commit 92f42c50f227ad228f815a8f4eec872524dae3a5 upstream.
We may need to convert the endianness of the data we read from/write
to 'buf', so let's use {get,put}_unaligned_le32() to do that. Failure
to do so can result in accessing invalid memory, leading to a
segfault. Stephen Rothwell noticed this bug while cross-building an
x86_64 allmodconfig kernel on PowerPC.
We need to read from and write to 'buf' a byte at a time otherwise
it's possible we'll perform an unaligned access, which can lead to bus
errors when cross-building an x86 kernel on risc architectures.
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Nick Bowler <nbowler@elliptictech.com>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-6-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa703cc83786fabab0058713a424d5201e29dde2
Author: Matt Fleming <matt.fleming@intel.com>
Date: Tue Feb 28 13:37:23 2012 +0000
x86, boot: Restrict CFLAGS for hostprogs
commit d40f833630a1299fd377408dc8d8fac370d621b0 upstream.
Currently tools/build has access to all the kernel headers in
$(srctree). This is unnecessary and could potentially allow
tools/build to erroneously include kernel headers when it should only
be including userspace-exported headers.
Unfortunately, mkcpustr still needs access to some of the asm kernel
headers, so explicitly special case that hostprog.
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-5-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 24eba790c0dae612b499a77e736fb11cc8e81a9c
Author: Matt Fleming <matt.fleming@intel.com>
Date: Tue Feb 28 13:37:22 2012 +0000
x86, mkpiggy: Don't open code put_unaligned_le32()
commit 12871c568305a0b20f116315479a18cd46882e9b upstream.
Use the new headers in tools/include instead of rolling our own
put_unaligned_le32() implementation.
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-4-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 65907d483ca9f9d92eb22eb40d7b5f0cdbe7d235
Author: Matt Fleming <matt.fleming@intel.com>
Date: Tue Feb 28 13:37:20 2012 +0000
tools/include: Add byteshift headers for endian access
commit a07f7672d7cf0ff0d6e548a9feb6e0bd016d9c6c upstream.
There are various hostprogs in the kernel that are rolling their own
implementations of {get,put}_unaligned_le*(). Copy the byteshift
headers from include/linux/unaligned so that they can all use a single
implementation.
This requires changing some of the data types to the userspace
exported ones (u32 -> __u32, etc).
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1330436245-24875-2-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b4071cc8b463c7e98652d28e8a7535b7602c481
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Mar 5 21:06:14 2012 +0300
x86, efi: Fix pointer math issue in handle_ramdisks()
commit c7b738351ba92f48b943ac59aff6b5b0f17f37c9 upstream.
"filename" is a efi_char16_t string so this check for reaching the end
of the array doesn't work. We need to cast the pointer to (u8 *) before
doing the math.
This patch changes the "filename" to "filename_16" to avoid confusion in
the future.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: http://lkml.kernel.org/r/20120305180614.GA26880@elgon.mountain
Acked-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a474cec8e446c79629a14c189269e43041c38a1
Author: Matthew Garrett <mjg@redhat.com>
Date: Mon Apr 30 16:11:30 2012 -0400
efi: Validate UEFI boot variables
commit fec6c20b570bcf541e581fc97f2e0cbdb9725b98 upstream.
A common flaw in UEFI systems is a refusal to POST triggered by a malformed
boot variable. Once in this state, machines may only be restored by
reflashing their firmware with an external hardware device. While this is
obviously a firmware bug, the serious nature of the outcome suggests that
operating systems should filter their variable writes in order to prevent
a malicious user from rendering the machine unusable.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 02249ec6abfc5af8640070ceaf1677fb0c3c3912
Author: Matthew Garrett <mjg@redhat.com>
Date: Mon Apr 30 16:11:29 2012 -0400
efi: Add new variable attributes
commit 41b3254c93acc56adc3c4477fef7c9512d47659e upstream.
More recent versions of the UEFI spec have added new attributes for
variables. Add them.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 24c073add89846bb3480708978f71d4632e389d2
Author: Dan Williams <dan.j.williams@intel.com>
Date: Tue Mar 20 10:50:27 2012 -0700
SCSI: libsas: fix false positive 'device attached' conditions
commit 7d1d865181185bdf1316d236b1b4bd02c9020729 upstream.
Normalize phy->attached_sas_addr to return a zero-address in the case
when device-type == NO_DEVICE or the linkrate is invalid to handle
expanders that put non-zero sas addresses in the discovery response:
sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device)
sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device)
sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device)
sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device)
Reported-by: Andrzej Jakowski <andrzej.jakowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26d67f6fe3c2155b7964866740adccda245562a0
Author: Thomas Jackson <thomas.p.jackson@intel.com>
Date: Fri Feb 17 18:33:10 2012 -0800
SCSI: libsas: fix sas_find_bcast_phy() in the presence of 'vacant' phys
commit 1699490db339e2c6b3037ea8e7dcd6b2755b688e upstream.
If an expander reports 'PHY VACANT' for a phy index prior to the one
that generated a BCN libsas fails rediscovery. Since a vacant phy is
defined as a valid phy index that will never have an attached device
just continue the search.
Signed-off-by: Thomas Jackson <thomas.p.jackson@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit be443a52b085a10b696e7abc26524e709839e8d1
Author: Gabor Juhos <juhosg@openwrt.org>
Date: Wed Mar 14 10:28:35 2012 +0100
MIPS: ath79: fix AR933X WMAC reset code
commit de14ca6ae2c592d66db88f1e5596b26f7f011384 upstream.
The current code puts the built-in WMAC device of the
AR933X SoCs into reset instead of starting it. This
causes a hard lock on AR933X based boards when the
wireless driver tries to access the device.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/3484/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d2375bc5f69b8a76b3b706c92d90b5d772dc4c97
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Apr 27 12:56:24 2012 +0100
ARM: 7406/1: hotplug: copy the affinity mask when forcefully migrating IRQs
commit 5e7371ded05adfcfcee44a8bc070bfc37979b8f2 upstream.
When a CPU is hotplugged off, we migrate any IRQs currently affine to it
away and onto another online CPU by calling the irq_set_affinity
function of the relevant interrupt controller chip. This function
returns either IRQ_SET_MASK_OK or IRQ_SET_MASK_OK_NOCOPY, to indicate
whether irq_data.affinity was updated.
If we are forcefully migrating an interrupt (because the affinity mask
no longer identifies any online CPUs) then we should update the IRQ
affinity mask to reflect the new CPU set. Failure to do so can
potentially leave /proc/irq/n/smp_affinity identifying only offline
CPUs, which may confuse userspace IRQ balancing daemons.
This patch updates migrate_one_irq to copy the affinity mask when
the interrupt chip returns IRQ_SET_MASK_OK after forcefully changing the
affinity of an interrupt.
Reported-by: Leif Lindholm <leif.lindholm@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6938679dad4f018f1ddd1936de202028b8d9baac
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Apr 27 12:45:07 2012 +0100
ARM: 7403/1: tls: remove covert channel via TPIDRURW
commit 6a1c53124aa161eb624ce7b1e40ade728186d34c upstream.
TPIDRURW is a user read/write register forming part of the group of
thread registers in more recent versions of the ARM architecture (~v6+).
Currently, the kernel does not touch this register, which allows tasks
to communicate covertly by reading and writing to the register without
context-switching affecting its contents.
This patch clears TPIDRURW when TPIDRURO is updated via the set_tls
macro, which is called directly from __switch_to. Since the current
behaviour makes the register useless to userspace as far as thread
pointers are concerned, simply clearing the register (rather than saving
and restoring it) will not cause any problems to userspace.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 21fd41a277b8567781c7f412f76d1d5319e07dc2
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Apr 20 17:20:08 2012 +0100
ARM: 7396/1: errata: only handle ARM erratum #326103 on affected cores
commit f0c4b8d653f5ee091fb8d4d02ed7eaad397491bb upstream.
Erratum #326103 ("FSR write bit incorrect on a SWP to read-only memory")
only affects the ARM 1136 core prior to r1p0. The workaround
disassembles the faulting instruction to determine whether it was a read
or write access on all v6 cores.
An issue has been reported on the ARM 11MPCore whereby loading the
faulting instruction may happen in parallel with that page being
unmapped, resulting in a deadlock due to the lack of TLB broadcasting
in hardware:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/091561.html
This patch limits the workaround so that it is only used on affected
cores, which are known to be UP only. Other v6 cores can rely on the
FSR to indicate the access type correctly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 174c50cdb6104cb3c3bc1f4ff00ad20881ab00b7
Author: Stephen Warren <swarren@nvidia.com>
Date: Mon Apr 30 17:24:10 2012 -0600
USB: ehci-tegra: remove redundant gpio_set_value
commit 04c235c92ce8474e9f2b358bd97f013a500385f2 upstream.
The immediately preceding gpio_direction_output() already set the value,
so there's no need to repeat it. This also prevents gpio_set_value() from
WARNing when the GPIO is sleepable (e.g. is on an I2C expander); the set
direction API is always sleepable, but plain set_value isn't.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8d46d2d5b370506514616dd64d4e1b836ad4469f
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri Apr 20 22:34:49 2012 -0700
Input: synaptics - fix regression with "image sensor" trackpads
commit 899c612d74d4a242158a4db20367388d6299c028 upstream.
commit 7968a5dd492ccc38345013e534ad4c8d6eb60ed1
Input: synaptics - add support for Relative mode
Accidentally broke support for advanced gestures (multitouch)
on some trackpads such as the one in my ThinkPad X220 by
incorretly changing the condition for enabling them. This
restores it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7649422ede963320f6a30a5f362d9ace81c5194e
Author: Horia Geanta <horia.geanta@freescale.com>
Date: Fri Mar 30 17:49:53 2012 +0300
crypto: talitos - properly lock access to global talitos registers
commit 511d63cb19329235bc9298b64010ec494b5e1408 upstream.
Access to global talitos registers must be protected for the case when
affinities are configured such that primary and secondary talitos irqs
run on different cpus.
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8266343597919c6483517a0db22ea2f190388a2a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Apr 29 13:30:08 2012 -0700
autofs: make the autofsv5 packet file descriptor use a packetized pipe
commit 64f371bc3107e69efce563a3d0f0e6880de0d537 upstream.
The autofs packet size has had a very unfortunate size problem on x86:
because the alignment of 'u64' differs in 32-bit and 64-bit modes, and
because the packet data was not 8-byte aligned, the size of the autofsv5
packet structure differed between 32-bit and 64-bit modes despite
looking otherwise identical (300 vs 304 bytes respectively).
We first fixed that up by making the 64-bit compat mode know about this
problem in commit a32744d4abae ("autofs: work around unhappy compat
problem on x86-64"), and that made a 32-bit 'systemd' work happily on a
64-bit kernel because everything then worked the same way as on a 32-bit
kernel.
But it turned out that 'automount' had actually known and worked around
this problem in user space, so fixing the kernel to do the proper 32-bit
compatibility handling actually *broke* 32-bit automount on a 64-bit
kernel, because it knew that the packet sizes were wrong and expected
those incorrect sizes.
As a result, we ended up reverting that compatibility mode fix, and
thus breaking systemd again, in commit fcbf94b9dedd.
With both automount and systemd doing a single read() system call, and
verifying that they get *exactly* the size they expect but using
different sizes, it seemed that fixing one of them inevitably seemed to
break the other. At one point, a patch I seriously considered applying
from Michael Tokarev did a "strcmp()" to see if it was automount that
was doing the operation. Ugly, ugly.
However, a prettier solution exists now thanks to the packetized pipe
mode. By marking the communication pipe as being packetized (by simply
setting the O_DIRECT flag), we can always just write the bigger packet
size, and if user-space does a smaller read, it will just get that
partial end result and the extra alignment padding will simply be thrown
away.
This makes both automount and systemd happy, since they now get the size
they asked for, and the kernel side of autofs simply no longer needs to
care - it could pad out the packet arbitrarily.
Of course, if there is some *other* user of autofs (please, please,
please tell me it ain't so - and we haven't heard of any) that tries to
read the packets with multiple writes, that other user will now be
broken - the whole point of the packetized mode is that one system call
gets exactly one packet, and you cannot read a packet in pieces.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7de43e0010642025df683878f24e318ebb600ede
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Apr 29 13:12:42 2012 -0700
pipes: add a "packetized pipe" mode for writing
commit 9883035ae7edef3ec62ad215611cb8e17d6a1a5d upstream.
The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.
When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own. The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).
End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time. You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.
NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops. Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.
The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes). But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a6e9525b5f484e1fe4d27c39182728e0ab4d9012
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: Tue Apr 24 11:29:42 2012 +0200
usb gadget: uvc: uvc_request_data::length field must be signed
commit 6f6543f53f9ce136e01d7114bf6f0818ca54fb41 upstream.
The field is used to pass the UVC request data length, but can also be
used to signal an error when setting it to a negative value. Switch from
unsigned int to __s32.
Reported-by: Fernandez Gonzalo <gfernandez@copreci.es>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a70de1fef4bef503aa1e676f392dee159ac17865
Author: Felipe Balbi <balbi@ti.com>
Date: Wed Apr 18 13:59:30 2012 +0300
usb: gadget: dummy: do not call pullup() on udc_stop()
commit 15b120d67019d691e4389372967332d74a80522a upstream.
pullup() is already called properly by udc-core.c and
there's no need to call it from udc_stop(), in fact that
will cause issues.
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 66a78b37c83ac923a58b886b32b815944c6491b7
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Wed Apr 11 16:09:10 2012 -0400
USB: gadget: storage gadgets send wrong error code for unknown commands
commit c85dcdac5852295cf6822f5c4331a6ddab72581f upstream.
This patch (as1539) fixes a minor bug in the mass-storage gadget
drivers. When an unknown command is received, the error code sent
back is "Invalid Field in CDB" rather than "Invalid Command". This is
because the bitmask of CDB bytes allowed to be nonzero is incorrect.
When handling an unknown command, we don't care which command bytes
are nonzero. All the bits in the mask should be set, not just eight
of them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ce9245f5aff46201fa81fdd3f796a6c9f3ad1ab
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Tue Apr 24 14:07:22 2012 -0400
USB: EHCI: fix crash during suspend on ASUS computers
commit 151b61284776be2d6f02d48c23c3625678960b97 upstream.
This patch (as1545) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers. Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.
After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state. Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.
The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep. Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.
This fixes Bugzilla #42728.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9e7d6b2c090c5a0227739eae8e81355d76d05b6
Author: Oliver Neukum <oliver@neukum.org>
Date: Thu Apr 26 21:59:10 2012 +0200
USB: cdc-wdm: fix race leading leading to memory corruption
commit 5c22837adca7c30b66121cf18ad3e160134268d4 upstream.
This patch fixes a race whereby a pointer to a buffer
would be overwritten while the buffer was in use leading
to a double free and a memory leak. This causes crashes.
This bug was introduced in 2.6.34
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0d6b4fe6b6847eed1a5780e1a4f69e93e8bb2bf
Author: David Henningsson <david.henningsson@canonical.com>
Date: Fri Apr 20 10:01:46 2012 +0200
ALSA: HDA: Add external mic quirk for Asus Zenbook UX31E
commit 5ac57550f279c3d991ef0b398681bcaca18169f7 upstream.
According to the reporter, external mic starts to work if the
laptop-dmic model is used. According to BIOS pin config, all
pins are consistent with the alc269vb_laptop_dmic fixup, except
for the external mic, which is not present.
BugLink: https://bugs.launchpad.net/bugs/950490
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c5ed4ce988daccdb0f08c28760475d6b13722498
Author: Johannes Berg <johannes.berg@intel.com>
Date: Mon Apr 2 10:51:55 2012 +0200
nl80211: ensure interface is up in various APIs
commit 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 upstream.
[backported by Ben Greear]
The nl80211 handling code should ensure as much as
it can that the interface is in a valid state, it
can certainly ensure the interface is running.
Not doing so can cause calls through mac80211 into
the driver that result in warnings and unspecified
behaviour in the driver.
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4ecb76e392c7fa81230f07356188102ffa106b9
Author: Oleg Nesterov <oleg@redhat.com>
Date: Mon Apr 16 22:48:15 2012 +0200
i387: ptrace breaks the lazy-fpu-restore logic
commit 089f9fba56faf33cc6dd2a6442b7ac92c58b8209 upstream.
Starting from 7e16838d "i387: support lazy restore of FPU state"
we assume that fpu_owner_task doesn't need restore_fpu_checking()
on the context switch, its FPU state should match what we already
have in the FPU on this CPU.
However, debugger can change the tracee's FPU state, in this case
we should reset fpu.last_cpu to ensure fpu_lazy_restore() can't
return true.
Change init_fpu() to do this, it is called by user_regset->set()
methods.
Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20120416204815.GB24884@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9f4660213e58b3b78dc75bf3e3b4126dbe9a0b14
Author: Xi Wang <xi.wang@gmail.com>
Date: Mon Apr 23 04:06:42 2012 -0400
drm/i915: fix integer overflow in i915_gem_do_execbuffer()
commit 44afb3a04391a74309d16180d1e4f8386fdfa745 upstream.
On 32-bit systems, a large args->num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
allocation for execbuffer object list").
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a265435c87b19175c3906ff49ffe5bf4a4cc228
Author: Xi Wang <xi.wang@gmail.com>
Date: Mon Apr 23 04:06:41 2012 -0400
drm/i915: fix integer overflow in i915_gem_execbuffer2()
commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b upstream.
On 32-bit systems, a large args->buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 8408c282 ("drm/i915:
First try a normal large kmalloc for the temporary exec buffers").
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a4ddbfcd27b7190182ef7ce9464af8c93043cb9
Author: Kenneth Graunke <kenneth@whitecape.org>
Date: Fri Apr 27 12:44:41 2012 -0700
drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.
commit 3a69ddd6f872180b6f61fda87152b37202118fbc upstream.
Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in
OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when
using separate stencil buffers. Without it, the GPU tries to use the
LRA eviction policy, which isn't supported. This was supposed to be off
by default, but seems to be on for many machines.
This cannot be done in gen6_init_clock_gating with most of the other
workaround bits; the render ring needs to exist. Otherwise, the
register write gets dropped on the floor (one printk will show it
changed, but a second printk immediately following shows the value
reverts to the old one).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535
Cc: Rob Castle <futuredub@gmail.com>
Cc: Eric Appleman <erappleman@gmail.com>
Cc: aaron667@gmx.net
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f3cf624ecd3eac5e787c61ef518232d04c34b61f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Apr 1 19:16:18 2012 +0200
drm/i915: handle input/output sdvo timings separately in mode_set
commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905 upstream.
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the situation by adding an explicit output_dtd to the sdvo
mode_set function and streamline the code-flow by moving the input and
output mode setting in the sdvo encode together.
Furthermore testing showed that the sdvo input timing needs the
unadjusted dotclock, the sdvo chip will automatically compute the
required pixel multiplier to get a dotclock above 100 MHz.
Fix this up when converting a drm mode to an sdvo dtd.
This regression was introduced in
commit c74696b9c890074c1e1ee3d7496fc71eb3680ced
Author: Pavel Roskin <proski@gnu.org>
Date: Thu Sep 2 14:46:34 2010 -0400
i915: revert some checks added by commit 32aad86f
particularly the following hunk:
# diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
# b/drivers/gpu/drm/i915/intel_sdvo.c
# index 093e914..62d22ae 100644
# --- a/drivers/gpu/drm/i915/intel_sdvo.c
# +++ b/drivers/gpu/drm/i915/intel_sdvo.c
# @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder,
#
# /* We have tried to get input timing in mode_fixup, and filled into
# adjusted_mode */
# - if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
# - intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
# + intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
# + if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
# input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
# - } else
# - intel_sdvo_get_dtd_from_mode(&input_dtd, mode);
#
# /* If it's a TV, we already set the output timing in mode_fixup.
# * Otherwise, the output timing is equal to the input timing.
Due to questions raised in review, below a more elaborate analysis of
the bug at hand:
Sdvo seems to have two timings, one is the output timing which will be
sent over whatever is connected on the other side of the sdvo chip (panel,
hdmi screen, tv), the other is the input timing which will be generated by
the gmch pipe. It looks like sdvo is expected to scale between the two.
To make things slightly more complicated, we have a bunch of special
cases:
- For lvds panel we always use a fixed output timing, namely
intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
- Sdvo has an interface to generate a preferred input timing for a given
output timing. This is the confusing thing that I've tried to clear up
with the follow-on patches.
- A special requirement is that the input pixel clock needs to be between
100MHz and 200MHz (likely to keep it within the electromechanical design
range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
doubled/quadrupled.
The thing this patch tries to fix is that the pipe needs to be
explicitly instructed to double/quadruple the pixels and needs the
correspondingly higher pixel clock, whereas the sdvo adaptor seems to
do that itself and needs the unadjusted pixel clock. For the sdvo
encode side we already set the pixel mutliplier with a different
command (0x21).
This patch tries to fix this mess by:
- Keeping the output mode timing in the unadjusted plain mode, safe
for the lvds case.
- Storing the input timing in the adjusted_mode with the adjusted
pixel clock. This way we don't need to frob around with the core
crtc mode set code.
- Fixing up the pixelclock when constructing the sdvo dtd timing
struct. This is why the first hunk of the patch is an integral part
of the series.
- Dropping the is_tv special case because input_dtd is equivalent to
adjusted_mode after these changes. Follow-up patches clear this up
further (by simply ripping out intel_sdvo->input_dtd because it's
not needed).
v2: Extend commit message with an in-depth bug analysis.
Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 18f9f9c30e8094bcbf67cc25662d4d458997366b
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Apr 27 17:18:59 2012 -0400
drm/radeon/kms: need to set up ss on DP bridges as well
commit 700698e7c303f5095107c62a81872c2c3dad1702 upstream.
Makes Nutmeg DP to VGA bridges work for me.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=42490
Noticed by Jerome Glisse (after weeks of debugging).
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4107e604b634280e74b1f3bac2272cc711ba1056
Author: Martin Nyhus <martin.nyhus@gmx.com>
Date: Thu Mar 15 18:25:48 2012 +0100
dell-laptop: Terminate quirks list properly
commit d62d421b071b08249361044d8e56c8b5c3ed6aa7 upstream.
Add missing DMI_NONE entry to end of the quirks list so
dmi_check_system() won't read past the end of the list.
Signed-off-by: Martin Nyhus <martin.nyhus@gmx.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Tested-by: Jens Gustedt <Jens.Gustedt@loria.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8321741bae1a9a8a962a8afc0aebfc3f2d7e3556
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Date: Wed Apr 25 13:44:20 2012 -0700
hwmon: (fam15h_power) Fix pci_device_id array
commit c3e40a9972428d6e2d8e287ed0233a57a218c30f upstream.
pci_match_id() takes an *array* of IDs which must be properly zero-
terminated.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50b37d76adf86febe3efdc099acf08f6c7bb9bfb
Author: Andre Przywara <andre.przywara@amd.com>
Date: Mon Apr 9 18:16:34 2012 -0400
hwmon: fam15h_power: fix bogus values with current BIOSes
commit 00250ec90963b7ef6678438888f3244985ecde14 upstream.
Newer BKDG[1] versions recommend a different initialization value for
the running average range register in the northbridge. This improves
the power reading by avoiding counter saturations resulting in bogus
values for anything below about 80% of TDP power consumption.
Updated BIOSes will have this new value set up from the beginning,
but meanwhile we correct this value ourselves.
This needs to be done on all northbridges, even on those where the
driver itself does not register at.
This fixes the driver on all current machines to provide proper
values for idle load.
[1]
http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
Chapter 3.8: D18F5xE0 Processor TDP Running Average (p. 452)
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
[guenter.roeck@ericsson.com: Removed unnecessary return statement]
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit acfaccd16f9a9e81b7f4dac87617188387220227
Author: Steven Rostedt <srostedt@redhat.com>
Date: Thu Apr 19 10:31:47 2012 -0400
tracing: Fix stacktrace of latency tracers (irqsoff and friends)
commit db4c75cbebd7e5910cd3bcb6790272fcc3042857 upstream.
While debugging a latency with someone on IRC (mirage335) on #linux-rt (OFTC),
we discovered that the stacktrace output of the latency tracers
(preemptirqsoff) was empty.
This bug was caused by the creation of the dynamic length stack trace
again (like commit 12b5da3 "tracing: Fix ent_size in trace output" was).
This bug is caused by the latency tracers requiring the next event
to determine the time between the current event and the next. But by
grabbing the next event, the iter->ent_size is set to the next event
instead of the current one. As the stacktrace event is the last event,
this makes the ent_size zero and causes nothing to be printed for
the stack trace. The dynamic stacktrace uses the ent_size to determine
how much of the stack can be printed. The ent_size of zero means
no stack.
The simple fix is to save the iter->ent_size before finding the next event.
Note, mirage335 asked to remain anonymous from LKML and git, so I will
not add the Reported-by and Tested-by tags, even though he did report
the issue and tested the fix.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fbd271acf9cccc23a5167ca2b7861c5b9574a6a0
Author: he, bo <bo.he@intel.com>
Date: Wed Apr 25 19:59:21 2012 +0800
sched: Fix OOPS when build_sched_domains() percpu allocation fails
commit fb2cf2c660971bea0ad86a9a5c19ad39eab61344 upstream.
Under extreme memory used up situations, percpu allocation
might fail. We hit it when system goes to suspend-to-ram,
causing a kworker panic:
EIP: [<c124411a>] build_sched_domains+0x23a/0xad0
Kernel panic - not syncing: Fatal exception
Pid: 3026, comm: kworker/u:3
3.0.8-137473-gf42fbef #1
Call Trace:
[<c18cc4f2>] panic+0x66/0x16c
[...]
[<c1244c37>] partition_sched_domains+0x287/0x4b0
[<c12a77be>] cpuset_update_active_cpus+0x1fe/0x210
[<c123712d>] cpuset_cpu_inactive+0x1d/0x30
[...]
With this fix applied build_sched_domains() will return -ENOMEM and
the suspend attempt fails.
Signed-off-by: he, bo <bo.he@intel.com>
Reviewed-by: Zhang, Yanmin <yanmin.zhang@intel.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1335355161.5892.17.camel@hebo
[ So, we fail to deallocate a CPU because we cannot allocate RAM :-/
I don't like that kind of sad behavior but nevertheless it should
not crash under high memory load. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f2a395ea7f39652cbadb4a519c7d5cdaf2f5866e
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Mon Apr 16 14:46:30 2012 +0200
dmaengine: at_hdmac: remove clear-on-read in atc_dostart()
commit ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 upstream.
This loop on EBCISR register was designed to clear IRQ sources before enabling
a DMA channel. This register is clear-on-read so a race condition can appear if
another channel is already active and has just finished its transfer.
Removing this read on EBCISR is fixing the issue as there is no case where an IRQ
could be pending: we already make sure that this register is drained at probe()
time and during resume.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 126b6268f61da4dc12c95022ebc57c5f2d34fcee
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Thu Apr 12 19:47:11 2012 +0100
ASoC: wm8994: Improve sequencing of AIF channel enables
commit 1a38336b8611a04f0a624330c1f815421f4bf5f4 upstream.
This ensures a clean startup of the channels, without this change some
use cases could result in issues in a small proportion of cases.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3e15e1089795117c07c61143920ff27b9043f3a7
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Thu Apr 12 17:29:36 2012 +0100
ASoC: dapm: Ensure power gets managed for line widgets
commit 7e1f7c8a6e517900cd84da1b8ae020f08f286c3b upstream.
Line widgets had not been included in either the power up or power down
sequences so if a widget had an event associated with it that event would
never be run. Fix this minimally by adding them to the sequences, we
should probably be doing away with the specific widget types as they all
have the same priority anyway.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b4df709ec385011cdc4ed6975b2c6fd9bf74d4d
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu Apr 26 13:50:03 2012 -0400
xen/smp: Fix crash when booting with ACPI hotplug CPUs.
commit cf405ae612b0f7e2358db7ff594c0e94846137aa upstream.
When we boot on a machine that can hotplug CPUs and we
are using 'dom0_max_vcpus=X' on the Xen hypervisor line
to clip the amount of CPUs available to the initial domain,
we get this:
(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
.. snip..
DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
.. snip.
SMP: Allowing 64 CPUs, 32 hotplug CPUs
installing Xen timer for CPU 7
cpu 7 spinlock event irq 361
NMI watchdog: disabled (cpu7): hardware events not enabled
Brought up 8 CPUs
.. snip..
[acpi processor finds the CPUs are not initialized and starts calling
arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
CPU 8 got hotplugged
CPU 9 got hotplugged
CPU 10 got hotplugged
.. snip..
initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
calling erst_init+0x0/0x2bb @ 1
[and the scheduler sticks newly started tasks on the new CPUs, but
said CPUs cannot be initialized b/c the hypervisor has limited the
amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
The spinlock tries to kick the other CPU, but the structure for that
is not initialized and we crash.]
BUG: unable to handle kernel paging request at fffffffffffffed8
IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
PGD 180d067 PUD 180e067 PMD 0
Oops: 0002 [#1] SMP
CPU 7
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffff81035289>] [<ffffffff81035289>] xen_spin_lock+0x29/0x60
RSP: e02b:ffff8801fb9b3a70 EFLAGS: 00010282
With this patch, we cap the amount of vCPUS that the initial domain
can run, to exactly what dom0_max_vcpus=X has specified.
In the future, if there is a hypercall that will allow a running
domain to expand past its initial set of vCPUS, this patch should
be re-evaluated.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4dcef77549c4b406001baf0f7e992d0347f57355
Author: David Vrabel <david.vrabel@citrix.com>
Date: Thu Apr 26 19:44:06 2012 +0100
xen: correctly check for pending events when restoring irq flags
commit 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac upstream.
In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
called even if no events were pending. This resulted in (depending on
workload) about a 100 times as many xen_version hypercalls as
necessary.
Fix this by correcting the sense of the conditional jump.
This seems to give a significant performance benefit for some
workloads.
There is some subtle tricksy "..since the check here is trying to
check both pending and masked in a single cmpw, but I think this is
correct. It will call check_events now only when the combined
mask+pending word is 0x0001 (aka unmasked, pending)." (Ian)
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 967174faed55cea3a0b0d86dbe5349a8c200b30b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat Apr 28 08:29:56 2012 -0700
Revert "autofs: work around unhappy compat problem on x86-64"
commit fcbf94b9dedd2ce08e798a99aafc94fec8668161 upstream.
This reverts commit a32744d4abae24572eff7269bc17895c41bd0085.
While that commit was technically the right thing to do, and made the
x86-64 compat mode work identically to native 32-bit mode (and thus
fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
turns out that the automount binaries had workarounds for this compat
problem.
Now, the workarounds are disgusting: doing an "uname()" to find out the
architecture of the kernel, and then comparing it for the 64-bit cases
and fixing up the size of the read() in automount for those. And they
were confused: it's not actually a generic 64-bit issue at all, it's
very much tied to just x86-64, which has different alignment for an
'u64' in 64-bit mode than in 32-bit mode.
But the end result is that fixing the compat layer actually breaks the
case of a 32-bit automount on a x86-64 kernel.
There are various approaches to fix this (including just doing a
"strcmp()" on current->comm and comparing it to "automount"), but I
think that I will do the one that teaches pipes about a special "packet
mode", which will allow user space to not have to care too deeply about
the padding at the end of the autofs packet.
That change will make the compat workaround unnecessary, so let's revert
it first, and get automount working again in compat mode. The
packetized pipes will then fix autofs for systemd.
Reported-and-requested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Ian Kent <raven@themaw.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b636b7667a5a336263eb9bf141c359bb28ebeb87
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date: Mon Apr 2 18:06:48 2012 +0200
x86/platform: Remove incorrect error message in x86_default_fixup_cpu_id()
commit 68894632afb2729a1d8785c877840953894c7283 upstream.
It's only called from amd.c:srat_detect_node(). The introduced
condition for calling the fixup code is true for all AMD
multi-node processors, e.g. Magny-Cours and Interlagos. There we
have 2 NUMA nodes on one socket. Thus there are cores having
different numa-node-id but with equal phys_proc_id.
There is no point to print error messages in such a situation.
The confusing/misleading error message was introduced with
commit 64be4c1c2428e148de6081af235e2418e6a66dda ("x86: Add
x86_init platform override to fix up NUMA core numbering").
Remove the default fixup function (especially the error message)
and replace it by a NULL pointer check, move the
Numascale-specific condition for calling the fixup into the
fixup-function itself and slightly adapt the comment.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: <sp@numascale.com>
Cc: <bp@amd64.org>
Cc: <daniel@numascale-asia.com>
Link: http://lkml.kernel.org/r/20120402160648.GR27684@alberich.amd.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 811db9a091e57ebeffa6fe0f0e0eccaf07faff7d
Author: Bryan O'Donoghue <bryan.odonoghue@linux.intel.com>
Date: Wed Apr 18 17:37:39 2012 +0100
x86, apic: APIC code touches invalid MSR on P5 class machines
commit cbf2829b61c136edcba302a5e1b6b40e97d32c00 upstream.
Current APIC code assumes MSR_IA32_APICBASE is present for all systems.
Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE
was introduced as an architectural MSR by Intel @ P6.
Code paths that can touch this MSR invalidly are when vendor == Intel &&
cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass
lapic on the kernel command line, on a P5.
The below patch stops Linux incorrectly interfering with the
MSR_IA32_APICBASE for P5 class machines. Other code paths exist that
touch the MSR - however those paths are not currently reachable for a
conformant P5.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linux.intel.com>
Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 43b7582ef8c2d7ba30be64d90590b4ab287a1243
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date: Thu Apr 12 16:51:57 2012 +0200
x86, microcode: Ensure that module is only loaded on supported AMD CPUs
commit 283c1f2558ef4a4411fe908364b15b73b6ab44cf upstream.
Exit early when there's no support for a particular CPU family. Also,
fixup the "no support for this CPU vendor" to be issued only when the
driver is attempted to be loaded on an unsupported vendor.
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.com
[Boris: add a commit msg because Andreas is lazy]
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2069bb255cb1268452305e0d1cd5b92e1d18c47b
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date: Thu Apr 12 16:48:01 2012 +0200
x86, microcode: Fix sysfs warning during module unload on unsupported CPUs
commit a956bd6f8583326b18348ab1452b4686778f785d upstream.
Loading the microcode driver on an unsupported CPU and subsequently
unloading the driver causes
WARNING: at fs/sysfs/group.c:138 mc_device_remove+0x5f/0x70 [microcode]()
Hardware name: 01972NG
sysfs group ffffffffa00013d0 not found for kobject 'cpu0'
Modules linked in: snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel btusb snd_hda_codec bluetooth thinkpad_acpi rfkill microcode(-) [last unloaded: cfg80211]
Pid: 4560, comm: modprobe Not tainted 3.4.0-rc2-00002-g258f742 #5
Call Trace:
[<ffffffff8103113b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffff81031235>] ? warn_slowpath_fmt+0x45/0x50
[<ffffffff81120e74>] ? sysfs_remove_group+0x34/0x120
[<ffffffffa00000ef>] ? mc_device_remove+0x5f/0x70 [microcode]
[<ffffffff81331eb9>] ? subsys_interface_unregister+0x69/0xa0
[<ffffffff81563526>] ? mutex_lock+0x16/0x40
[<ffffffffa0000c3e>] ? microcode_exit+0x50/0x92 [microcode]
[<ffffffff8107051d>] ? sys_delete_module+0x16d/0x260
[<ffffffff810a0065>] ? wait_iff_congested+0x45/0x110
[<ffffffff815656af>] ? page_fault+0x1f/0x30
[<ffffffff81565ba2>] ? system_call_fastpath+0x16/0x1b
on recent kernels.
This is due to commit 8a25a2fd126c ("cpu: convert 'cpu' and
'machinecheck' sysdev_class to a regular subsystem") which renders
commit 6c53cbfced04 ("x86, microcode: Correct sysdev_add error path")
useless.
See http://marc.info/?l=linux-kernel&m=133416246406478
Avoid above warning by restoring the old driver behaviour before
6c53cbfced04 ("x86, microcode: Correct sysdev_add error path").
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.com
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 385ba2cdffded7ad0c34866418f7a3183c1bb5b7
Author: Fred Isaman <iisaman@netapp.com>
Date: Fri Apr 20 14:47:35 2012 -0400
NFS: put open context on error in nfs_flush_multi
commit 8ccd271f7a3a846ce6f85ead0760d9d12994a611 upstream.
Signed-off-by: Fred Isaman <iisaman@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3fe0c6c3bf2c2915f80e292ff1cb908ee31acd7e
Author: Fred Isaman <iisaman@netapp.com>
Date: Fri Apr 20 14:47:34 2012 -0400
NFS: put open context on error in nfs_pagein_multi
commit 73fb7bc7c57d971b11f2e00536ac2d3e316e0609 upstream.
Signed-off-by: Fred Isaman <iisaman@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6d3944b30bba96911b06b990ff9538a24006cb4
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Wed Apr 18 12:48:35 2012 -0400
NFSv4: Ensure that we check lock exclusive/shared type against open modes
commit 55725513b5ef9d462aa3e18527658a0362aaae83 upstream.
Since we may be simulating flock() locks using NFS byte range locks,
we can't rely on the VFS having checked the file open mode for us.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f053d8fd4057ff3e4b944e555e26d7cc7fea6972
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Wed Apr 18 12:20:10 2012 -0400
NFSv4: Ensure that the LOCK code sets exception->inode
commit 05ffe24f5290dc095f98fbaf84afe51ef404ccc5 upstream.
All callers of nfs4_handle_exception() that need to handle
NFS4ERR_OPENMODE correctly should set exception->inode
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 429be997e91165e98ede2f64ff50984dddfb68f8
Author: Jan Kara <jack@suse.cz>
Date: Sat Sep 3 01:09:43 2011 +0200
nfs: Enclose hostname in brackets when needed in nfs_do_root_mount
commit 98a2139f4f4d7b5fcc3a54c7fddbe88612abed20 upstream.
When hostname contains colon (e.g. when it is an IPv6 address) it needs
to be enclosed in brackets to make parsing of NFS device string possible.
Fix nfs_do_root_mount() to enclose hostname properly when needed. NFS code
actually does not need this as it does not parse the string passed by
nfs_do_root_mount() but the device string is exposed to userspace in
/proc/mounts.
CC: Josh Boyer <jwboyer@redhat.com>
CC: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>