10 years agoxen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback
Stefano Stabellini [Mon, 30 Jan 2012 14:31:46 +0000 (14:31 +0000)]
xen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback

commit 207d543f472c1ac9552df79838dc807cbcaa9740 upstream.

Signed-off-by: Stefano Stabellini <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agommc: dw_mmc: Fix PIO mode with support of highmem
Seungwon Jeon [Thu, 9 Feb 2012 05:32:43 +0000 (14:32 +0900)]
mmc: dw_mmc: Fix PIO mode with support of highmem

commit f9c2a0dc42a6938ff2a80e55ca2bbd1d5581c72e upstream.

Current PIO mode makes a kernel crash with CONFIG_HIGHMEM.
Highmem pages have a NULL from sg_virt(sg).
This patch fixes the following problem.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 817 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01423-gdbf465f #589)
PC is at dw_mci_pull_data32+0x4c/0x9c
LR is at dw_mci_read_data_pio+0x54/0x1f0
pc : [<c0358824>]    lr : [<c035988c>]    psr: 20000193
sp : c0619d48  ip : c0619d70  fp : c0619d6c
r10: 00000000  r9 : 00000002  r8 : 00001000
r7 : 00000200  r6 : 00000000  r5 : e1dd3100  r4 : 00000000
r3 : 65622023  r2 : 0000007f  r1 : eeb96000  r0 : e1dd3100
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment
Control: 10c5387d  Table: 61e2004a  DAC: 00000015
Process swapper (pid: 0, stack limit = 0xc06182f0)
Stack: (0xc0619d48 to 0xc061a000)
9d40:                   e1dd3100 e1a4f000 00000000 e1dd3100 e1a4f000 00000200
9d60: c0619da4 c0619d70 c035988c c03587e4 c0619d9c e18158f4 e1dd3100 e1dd3100
9d80: 00000020 00000000 00000000 00000020 c06e8a84 00000000 c0619e04 c0619da8
9da0: c0359b24 c0359844 e18158f4 e1dd3164 e1dd3168 e1dd3150 3d02fc79 e1dd3154
9dc0: e1dd3178 00000000 00000020 00000000 e1dd3150 00000000 c10dd7e8 e1a84900
9de0: c061e7cc 00000000 00000000 0000008d c06e8a84 c061e780 c0619e4c c0619e08
9e00: c00c4738 c0359a34 3d02fc79 00000000 c0619e4c c05a1698 c05a1670 c05a165c
9e20: c04de8b0 c061e780 c061e7cc e1a84900 ffffed68 0000008d c0618000 00000000
9e40: c0619e6c c0619e50 c00c48b4 c00c46c8 c061e780 c00423ac c061e7cc ffffed68
9e60: c0619e8c c0619e70 c00c7358 c00c487c 0000008d ffffee38 c0618000 ffffed68
9e80: c0619ea4 c0619e90 c00c4258 c00c72b0 c00423ac ffffee38 c0619ecc c0619ea8
9ea0: c004241c c00c4234 ffffffff f8810000 0000006d 00000002 00000001 7fffffff
9ec0: c0619f44 c0619ed0 c0048bc0 c00423c4 220ae7a9 00000000 386f0d30 0005d3a4
9ee0: c00423ac c10dd0b8 c06f2cd8 c0618000 c0594778 c003a674 7fffffff c0619f44
9f00: 386f0d30 c0619f18 c00a6f94 c005be3c 80000013 ffffffff 386f0d30 0005d3a4
9f20: 386f0d30 0005d2d1 c10dd0a8 c10dd0b8 c06f2cd8 c0618000 c0619f74 c0619f48
9f40: c0345858 c005be00 c00a2440 c0618000 c0618000 c00410d8 c06c1944 c00410fc
9f60: c0594778 c003a674 c0619f9c c0619f78 c004a7e8 c03457b4 c0618000 c06c18f8
9f80: 00000000 c0039c70 c06c18d4 c003a674 c0619fb4 c0619fa0 c04ceafc c004a714
9fa0: c06287b4 c06c18f8 c0619ff4 c0619fb8 c0008b68 c04cea68 c0008578 00000000
9fc0: 00000000 c003a674 00000000 10c5387d c0628658 c003aa78 c062f1c4 4000406a
9fe0: 413fc090 00000000 00000000 c0619ff8 40008044 c0008858 00000000 00000000
[<c03587d8>] (dw_mci_pull_data32+0x0/0x9c) from [<c035988c>] (dw_mci_read_data_pio+0x54/0x1f0)
 r6:00000200 r5:e1a4f000 r4:e1dd3100
 [<c0359838>] (dw_mci_read_data_pio+0x0/0x1f0) from [<c0359b24>] (dw_mci_interrupt+0xfc/0x4a4)
[<c0359a28>] (dw_mci_interrupt+0x0/0x4a4) from [<c00c4738>] (handle_irq_event_percpu+0x7c/0x1b4)
[<c00c46bc>] (handle_irq_event_percpu+0x0/0x1b4) from [<c00c48b4>] (handle_irq_event+0x44/0x64)
[<c00c4870>] (handle_irq_event+0x0/0x64) from [<c00c7358>] (handle_fasteoi_irq+0xb4/0x124)
 r7:ffffed68 r6:c061e7cc r5:c00423ac r4:c061e780
 [<c00c72a4>] (handle_fasteoi_irq+0x0/0x124) from [<c00c4258>] (generic_handle_irq+0x30/0x38)
 r7:ffffed68 r6:c0618000 r5:ffffee38 r4:0000008d
 [<c00c4228>] (generic_handle_irq+0x0/0x38) from [<c004241c>] (asm_do_IRQ+0x64/0xe0)
 r5:ffffee38 r4:c00423ac
 [<c00423b8>] (asm_do_IRQ+0x0/0xe0) from [<c0048bc0>] (__irq_svc+0x80/0x14c)
Exception stack(0xc0619ed0 to 0xc0619f18)

Signed-off-by: Seungwon Jeon <>
Acked-by: Will Newton <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agommc: atmel-mci: save and restore sdioirq when soft reset is performed
Ludovic Desroches [Thu, 9 Feb 2012 10:55:29 +0000 (11:55 +0100)]
mmc: atmel-mci: save and restore sdioirq when soft reset is performed

commit 18ee684b8ab666329e0a0a72d8b70f16fb0e2243 upstream.

Sometimes a software reset is needed. Then some registers are saved and
restored but the interrupt mask register is missing. It causes issues
with sdio devices whose interrupts are masked after reset.

Signed-off-by: Ludovic Desroches <>
Signed-off-by: Nicolas Ferre <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: hda - Fix silent speaker output on Acer Aspire 6935
Takashi Iwai [Mon, 13 Feb 2012 14:25:07 +0000 (15:25 +0100)]
ALSA: hda - Fix silent speaker output on Acer Aspire 6935

commit 02a237b24d57e2e2d5402c92549e9e792aa24359 upstream.

Since 3.2 kernel, the driver starts trying to assign the multi-io DACs
before the speaker, thus it assigns DAC2/3 for multi-io and DAC4 for
the speaker for a standard laptop setup like a HP, a speaker, a mic-in
and a line-in.  However, on Acer Aspire 6935, it seems that the
speaker pin 0x14 must be connected with either DAC1 or 2; otherwise it
results in silence by some reason, although the codec itself allows
the routing to DAC3/4.

As a workaround, the connection list of each pin is reduced to be
mapped to either only DAC1/2 or DAC3/4, so that the compatible
assignment as in kernel 3.1 is achieved.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: hda - Fix initialization of secondary capture source on VT1705
Takashi Iwai [Mon, 13 Feb 2012 14:04:06 +0000 (15:04 +0100)]
ALSA: hda - Fix initialization of secondary capture source on VT1705

commit fc1156c0b0f7ad45ec03d919866349eeca2bf18c upstream.

VT1705 codec has two ADCs where the secondary ADC has no MUX but only
a fixed connection to the mic pin.  This confused the driver and it
tries always overriding the input-source selection by assumption of
the existing MUX for the secondary ADC, resulted in resetting the
input-source at each time PM (including power-saving) occurs.

The fix is simply to check the existence of MUX for secondary ADCs in
the initialization code.

Tested-by: Anisse Astier <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: intel8x0: Fix default inaudible sound on Gateway M520
Daniel T Chen [Tue, 14 Feb 2012 04:44:22 +0000 (23:44 -0500)]
ALSA: intel8x0: Fix default inaudible sound on Gateway M520

commit 27c3afe6e1cf129faac90405121203962da08ff4 upstream.

The reporter states that audio is inaudible by default without muting
'External Amplifier'. Add a quirk to handle his SSID so that changing
the control is not necessary.

Reported-and-tested-by: Benjamin Carlson <>
Signed-off-by: Daniel T Chen <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agobacking-dev: fix wakeup timer races with bdi_unregister()
Rabin Vincent [Sun, 29 Jan 2012 18:17:33 +0000 (12:17 -0600)]
backing-dev: fix wakeup timer races with bdi_unregister()

commit 2673b4cf5d59c3ee5e0c12f6d734d38770324dc4 upstream.

While 7a401a972df8e18 ("backing-dev: ensure wakeup_timer is deleted")
addressed the problem of the bdi being freed with a queued wakeup
timer, there are other races that could happen if the wakeup timer
expires after/during bdi_unregister(), before bdi_destroy() is called.

wakeup_timer_fn() could attempt to wakeup a task which has already has
been freed, or could access a NULL bdi->dev via the wake_forker_thread

Cc: Jens Axboe <>
Reported-by: Chanho Min <>
Reviewed-by: Namjae Jeon <>
Signed-off-by: Rabin Vincent <>
Signed-off-by: Wu Fengguang <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocrypto: sha512 - Avoid stack bloat on i386
Herbert Xu [Sun, 5 Feb 2012 04:09:28 +0000 (15:09 +1100)]
crypto: sha512 - Avoid stack bloat on i386

commit 3a92d687c8015860a19213e3c102cad6b722f83c upstream.

Unfortunately in reducing W from 80 to 16 we ended up unrolling
the loop twice.  As gcc has issues dealing with 64-bit ops on
i386 this means that we end up using even more stack space (>1K).

This patch solves the W reduction by moving LOAD_OP/BLEND_OP
into the loop itself, thus avoiding the need to duplicate it.

While the stack space still isn't great (>0.5K) it is at least
in the same ball park as the amount of stack used for our C sha1

Note that this patch basically reverts to the original code so
the diff looks bigger than it really is.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocrypto: sha512 - Use binary and instead of modulus
Herbert Xu [Thu, 26 Jan 2012 04:03:16 +0000 (15:03 +1100)]
crypto: sha512 - Use binary and instead of modulus

commit 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd upstream.

The previous patch used the modulus operator over a power of 2
unnecessarily which may produce suboptimal binary code.  This
patch changes changes them to binary ands instead.

Signed-off-by: Herbert Xu <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocifs: don't return error from standard_receive3 after marking response malformed
Jeff Layton [Tue, 7 Feb 2012 11:31:05 +0000 (06:31 -0500)]
cifs: don't return error from standard_receive3 after marking response malformed

commit ff4fa4a25a33f92b5653bb43add0c63bea98d464 upstream.

standard_receive3 will check the validity of the response from the
server (via checkSMB). It'll pass the result of that check to handle_mid
which will dequeue it and mark it with a status of
MID_RESPONSE_MALFORMED if checkSMB returned an error. At that point,
standard_receive3 will also return an error, which will make the
demultiplex thread skip doing the callback for the mid.

This is wrong -- if we were able to identify the request and the
response is marked malformed, then we want the demultiplex thread to do
the callback. Fix this by making standard_receive3 return 0 in this

Reported-and-Tested-by: Mark Moseley <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocifs: request oplock when doing open on lookup
Jeff Layton [Tue, 7 Feb 2012 11:30:52 +0000 (06:30 -0500)]
cifs: request oplock when doing open on lookup

commit 8b0192a5f478da1c1ae906bf3ffff53f26204f56 upstream.

Currently, it's always set to 0 (no oplock requested).

Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agohwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375
Nikolaus Schulz [Wed, 8 Feb 2012 17:56:08 +0000 (18:56 +0100)]
hwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375

commit 09e87e5c4f9af656af2a8a3afc03487c5d9287c3 upstream.

In order to enable temperature mode aka automatic mode for the F75373 and
F75375 chips, the two FANx_MODE bits in the fan configuration register
need be set to 01, not 10.

Signed-off-by: Nikolaus Schulz <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agowriteback: fix dereferencing NULL bdi->dev on trace_writeback_queue
Wu Fengguang [Sun, 5 Feb 2012 02:54:03 +0000 (20:54 -0600)]
writeback: fix dereferencing NULL bdi->dev on trace_writeback_queue

commit 977b7e3a52a7421ad33a393a38ece59f3d41c2fa upstream.

When a SD card is hot removed without umount, del_gendisk() will call
bdi_unregister() without destroying/freeing it. This leaves the bdi in
the bdi->dev = NULL, bdi->wb.task = NULL, bdi->bdi_list removed state.

When sync(2) gets the bdi before bdi_unregister() and calls
bdi_queue_work() after the unregister, trace_writeback_queue will be
dereferencing the NULL bdi->dev. Fix it with a simple test for NULL.

Reported-by: Rabin Vincent <>
Tested-by: Namjae Jeon <>
Signed-off-by: Wu Fengguang <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agowriteback: fix NULL bdi->dev in trace writeback_single_inode
Wu Fengguang [Tue, 17 Jan 2012 17:18:56 +0000 (11:18 -0600)]
writeback: fix NULL bdi->dev in trace writeback_single_inode

commit 15eb77a07c714ac80201abd0a9568888bcee6276 upstream.

bdi_prune_sb() resets sb->s_bdi to default_backing_dev_info when the
tearing down the original bdi. Fix trace_writeback_single_inode to
use sb->s_bdi=default_backing_dev_info rather than bdi->dev=NULL for a
teared down bdi.

Reported-by: Rabin Vincent <>
Tested-by: Rabin Vincent <>
Signed-off-by: Wu Fengguang <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomac80211: timeout a single frame in the rx reorder buffer
Eliad Peller [Wed, 1 Feb 2012 16:48:09 +0000 (18:48 +0200)]
mac80211: timeout a single frame in the rx reorder buffer

commit 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream.

The current code checks for stored_mpdu_num > 1, causing
the reorder_timer to be triggered indefinitely, but the
frame is never timed-out (until the next packet is received)

Signed-off-by: Eliad Peller <>
Acked-by: Johannes Berg <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agorelay: prevent integer overflow in relay_open()
Dan Carpenter [Fri, 10 Feb 2012 08:03:58 +0000 (09:03 +0100)]
relay: prevent integer overflow in relay_open()

commit f6302f1bcd75a042df69866d98b8d775a668f8f1 upstream.

"subbuf_size" and "n_subbufs" come from the user and they need to be
capped to prevent an integer overflow.

Signed-off-by: Dan Carpenter <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agolib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel
Wu Fengguang [Mon, 9 Jan 2012 17:53:50 +0000 (11:53 -0600)]
lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.

PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs
in the below lines of bdi_dirty_limit():

bdi_dirty *= numerator;
do_div(bdi_dirty, denominator);

1) divide error: do_div() only uses the lower 32 bit of the denominator,
   which may trimmed to be 0 when PROP_MAX_SHIFT > 32.

2) overflow: (bdi_dirty * numerator) could easily overflow if numerator
   used up to 48 bits, leaving only 16 bits to bdi_dirty

Cc: Peter Zijlstra <>
Reported-by: Ilya Tumaykin <>
Tested-by: Ilya Tumaykin <>
Signed-off-by: Wu Fengguang <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agonet: enable TC35815 for MIPS again
Atsushi Nemoto [Mon, 6 Feb 2012 14:51:03 +0000 (14:51 +0000)]
net: enable TC35815 for MIPS again

commit a1728800bed3b93b231d99e97c756f622b9991c2 upstream.

From: Ralf Roesch <>
Date: Wed, 16 Nov 2011 09:33:50 +0100
Subject: net: enable TC35815 for MIPS again

TX493[8,9] MIPS SoCs support 2 Ethernet channels of type TC35815
which are connected to the internal PCI controller.
And JMR3927 MIPS board has a TC35815 chip on board.
These dependencies were lost on movement to drivers/net/ethernet/toshiba.

Signed-off-by: Ralf Roesch <>
Signed-off-by: Atsushi Nemoto <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agohwmon: (f75375s) Fix bit shifting in f75375_write16
Nikolaus Schulz [Wed, 8 Feb 2012 17:56:10 +0000 (18:56 +0100)]
hwmon: (f75375s) Fix bit shifting in f75375_write16

commit eb2f255b2d360df3f500042a2258dcf2fcbe89a2 upstream.

In order to extract the high byte of the 16-bit word, shift the word to
the right, not to the left.

Signed-off-by: Nikolaus Schulz <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoath9k_hw: fix a RTS/CTS timeout regression
Felix Fietkau [Sun, 5 Feb 2012 20:15:18 +0000 (21:15 +0100)]
ath9k_hw: fix a RTS/CTS timeout regression

commit 55a2bb4a6d5e8c7b324d003e130fd9aaf33be4e6 upstream.

commit adb5066 "ath9k_hw: do not apply the 2.4 ghz ack timeout
workaround to cts" reduced the hardware CTS timeout to the normal
values specified by the standard, but it turns out while it doesn't
need the same extra time that it needs for the ACK timeout, it
does need more than the value specified in the standard, but only
for 2.4 GHz.

This patch brings the CTS timeout value in sync with the initialization
values, while still allowing adjustment for bigger distances.

Signed-off-by: Felix Fietkau <>
Reported-by: Seth Forshee <>
Reported-by: Marek Lindner <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoath9k: fix a WEP crypto related regression
Felix Fietkau [Sun, 5 Feb 2012 20:15:17 +0000 (21:15 +0100)]
ath9k: fix a WEP crypto related regression

commit f88373fa47f3ce6590fdfaa742d0ddacc2ae017f upstream.

commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag"
fixed the interpretation of the KeyMiss flag for keycache based lookups,
however WEP encryption uses a static index, so KeyMiss is always asserted
for it, even though frames are decrypted properly.
Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based
lookup was performed.

Signed-off-by: Felix Fietkau <>
Reported-by: Laurent Bonnans <>
Reported-by: Jurica Vukadin <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoath9k: Fix kernel panic during driver initilization
Mohammed Shafi Shajakhan [Thu, 2 Feb 2012 10:59:05 +0000 (16:29 +0530)]
ath9k: Fix kernel panic during driver initilization

commit 07445f688218a48bde72316aed9de4fdcc173131 upstream.

all works need to be initialized before ieee80211_register_hw
to prevent mac80211 call backs such as drv_start, drv_config
getting started. otherwise we would queue/cancel works before
initializing them and it leads to kernel panic.
this issue can be recreated with the following script
in Chrome laptops with AR928X cards, with background scan
running (or) Network manager is running

while true
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3

 EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
 ---[ end trace 4f86d6139a9900ef ]---
 Registered led device: ath9k-phy0
 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
 Kernel panic - not syncing: Fatal exception
 Pid: 456, comm: wpa_supplicant Tainted: G      D
 3.0.13 #1
Call Trace:
 [<81379e21>] panic+0x53/0x14a
 [<81004a30>] oops_end+0x73/0x81
 [<81004b53>] die+0x4c/0x55
 [<81002710>] do_trap+0x7c/0x83
 [<81002855>] ? do_bounds+0x58/0x58
 [<810028cc>] do_invalid_op+0x77/0x81
 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
 [<810489ec>] ? sched_clock_cpu+0x81/0x11f
 [<8103f809>] ? wait_on_work+0xe2/0xf7
 [<8137f807>] error_code+0x67/0x6c
 [<810300d8>] ? wait_consider_task+0x4ba/0x84c
 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67
 [<81040a91>] cancel_work_sync+0xf/0x11
 [<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k]
 [<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
 [<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k]
 [<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211]
 [<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
 [<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
 [<812dbed8>] __dev_open+0x82/0xab

Cc: Gary Morain <>
Cc: Paul Stewart <>
Cc: Vasanthakumar Thiagarajan <>
Tested-by: Mohammed Shafi Shajakhan <>
Signed-off-by: Rajkumar Manoharan <>
Signed-off-by: Mohammed Shafi Shajakhan <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: no lvds quirk for AOpen MP45
Daniel Vetter [Wed, 8 Feb 2012 15:42:52 +0000 (16:42 +0100)]
drm/i915: no lvds quirk for AOpen MP45

commit e57b6886f555ab57f40a01713304e2053efe51ec upstream.

According to a bug report, it doesn't have one.

Acked-by: Chris Wilson <>
Signed-Off-by: Daniel Vetter <>
Signed-off-by: Keith Packard <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: Force explicit bpp selection for intel_dp_link_required
Keith Packard [Wed, 25 Jan 2012 16:16:25 +0000 (08:16 -0800)]
drm/i915: Force explicit bpp selection for intel_dp_link_required

commit c898261c0dad617f0f1080bedc02d507a2fcfb92 upstream.

It is never correct to use intel_crtc->bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be addressed separately from this bugfix.

intel_dp_link_required is called from intel_dp_mode_valid and

* intel_dp_mode_valid is called to list supported modes; in this case,
  the current crtc values cannot be relevant as the modes in question
  may never be selected. Thus, using intel_crtc->bpp is never right.

* intel_dp_mode_fixup is called during mode setting, but it is run
  well before ironlake_crtc_mode_set is called to set intel_crtc->bpp,
  so using intel_crtc-bpp in this path can only ever get a stale

Cc: Lubos Kolouch <>
Cc: Adam Jackson <>
Reviewed-by: Daniel Vetter <>
Tested-by: Dave Airlie <>
Tested-by: (Dell Latitude 6510)
Tested-by: Roland Dreier <>
Signed-off-by: Keith Packard <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoperf tools: Fix perf stack to non executable on x86_64
Jiri Olsa [Mon, 6 Feb 2012 20:54:06 +0000 (18:54 -0200)]
perf tools: Fix perf stack to non executable on x86_64

commit 7a0153ee15575a4d07b5da8c96b79e0b0fd41a12 upstream.

By adding following objects:
the x86_64 perf binary ended up with executable stack.

The reason was that above object are assembler sourced and is missing the
GNU-stack note section. In such case the linker assumes that the final binary
should not be restricted at all and mark the stack as RWX.

Adding section ".note.GNU-stack" definition to mentioned object, with all
flags disabled, thus omiting this object from linker stack flags decision.

Problem introduced in:

  $ git describe ea7872b

Reported-by: Clark Williams <>
Acked-by: Eric Dumazet <>
Cc: Corey Ashford <>
Cc: Ingo Molnar <>
Cc: Paul Mackerras <>
Cc: Peter Zijlstra <>
Signed-off-by: Jiri Olsa <>
[ committer note: Backported fix to perf/urgent (3.3-rc2+) ]
Signed-off-by: Arnaldo Carvalho de Melo <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoperf evsel: Fix an issue where perf report fails to show the proper percentage
Naveen N. Rao [Fri, 3 Feb 2012 17:01:13 +0000 (22:31 +0530)]
perf evsel: Fix an issue where perf report fails to show the proper percentage

commit a4a03fc7ef89020baca4f19174e6a43767c6d78a upstream.

This patch fixes an issue where perf report shows nan% for certain files. The below is from a report for a do_fork probe:

   -nan%           sshd  [kernel.kallsyms]  [k] do_fork
   -nan%    packagekitd  [kernel.kallsyms]  [k] do_fork
   -nan%    dbus-daemon  [kernel.kallsyms]  [k] do_fork
   -nan%           bash  [kernel.kallsyms]  [k] do_fork

A git bisect shows commit f3bda2c as the cause. However, looking back
through the git history, I saw commit 640c03c which seems to have
removed the required initialization for perf_sample->period. The problem
only started showing after commit f3bda2c. The below patch re-introduces
the initialization and it fixes the problem for me.

With the below patch, for the same

  73.08%             bash  [kernel.kallsyms]  [k] do_fork
   8.97%      11-dhclient  [kernel.kallsyms]  [k] do_fork
   6.41%             sshd  [kernel.kallsyms]  [k] do_fork
   3.85%        20-chrony  [kernel.kallsyms]  [k] do_fork
   2.56%         sendmail  [kernel.kallsyms]  [k] do_fork

This patch applies over current linux-tip commit 9949284.

Problem introduced in:

$ git describe 640c03c

Cc: Ananth N Mavinakayanahalli <>
Cc: Ingo Molnar <>
Cc: Robert Richter <>
Cc: Srikar Dronamraju <>
Signed-off-by: Naveen N. Rao <>
Signed-off-by: Arnaldo Carvalho de Melo <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoigb: fix vf lookup
Greg Rose [Thu, 2 Feb 2012 23:51:43 +0000 (23:51 +0000)]
igb: fix vf lookup

commit 0629292117572a60465f38cdedde2f8164c3df0b upstream.

Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs.  Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.

This is applicable to 3.2+ kernels.

Reported-by: David Ahern <>
Signed-off-by: Greg Rose <>
Tested-by: Robert E Garrett <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoixgbe: fix vf lookup
Greg Rose [Fri, 3 Feb 2012 00:54:13 +0000 (00:54 +0000)]
ixgbe: fix vf lookup

commit a4b08329c74985e5cc3a44b6d2b2c59444ed8079 upstream.

Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs.  Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.

This bug exists in 3.2 stable as well as 3.3 release candidates.

Reported-by: David Ahern <>
Signed-off-by: Greg Rose <>
Tested-by: Robert E Garrett <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoLinux 3.2.6 v3.2.6
Greg Kroah-Hartman [Mon, 13 Feb 2012 19:17:29 +0000 (11:17 -0800)]
Linux 3.2.6

10 years agopowernow-k8: Fix indexing issue
Andreas Herrmann [Fri, 6 Jan 2012 14:57:55 +0000 (15:57 +0100)]
powernow-k8: Fix indexing issue

commit a8eb28480e9b637cc78b9aa5e08612ba97e1317a upstream.

The driver uses the pstate number from the status register as index in
its table of ACPI pstates (powernow_table). This is wrong as this is
not a 1-to-1 mapping.

For example we can have _PSS information to just utilize Pstate 0 and
Pstate 4, ie.

  powernow-k8: Core Performance Boosting: on.
  powernow-k8:    0 : pstate 0 (2200 MHz)
  powernow-k8:    1 : pstate 4 (1400 MHz)

In this example the driver's powernow_table has just 2 entries. Using
the pstate number (4) as index into this table is just plain wrong.

Signed-off-by: Andreas Herrmann <>
Signed-off-by: Dave Jones <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agopowernow-k8: Avoid Pstate MSR accesses on systems supporting CPB
Andreas Herrmann [Fri, 6 Jan 2012 14:56:31 +0000 (15:56 +0100)]
powernow-k8: Avoid Pstate MSR accesses on systems supporting CPB

commit 201bf0f129e1715a33568d1563d9a75b840ab4d3 upstream.

Due to CPB we can't directly map SW Pstates to Pstate MSRs. Get rid of
the paranoia check. (assuming that the ACPI Pstate information is

Signed-off-by: Andreas Herrmann <>
Signed-off-by: Dave Jones <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agommc: cb710 core: Add missing spin_lock_init for irq_lock of struct cb710_chip
Axel Lin [Wed, 1 Feb 2012 04:31:47 +0000 (12:31 +0800)]
mmc: cb710 core: Add missing spin_lock_init for irq_lock of struct cb710_chip

commit b5266ea675c5a041e2852c7ccec4cf2d4f5e0cf4 upstream.

Signed-off-by: Axel Lin <>
Acked-by: Michał Mirosław <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agozcache: fix deadlock condition
Dan Magenheimer [Wed, 25 Jan 2012 22:32:51 +0000 (14:32 -0800)]
zcache: fix deadlock condition

commit 9256a4789be3dae37d00924c03546ba7958ea5a3 upstream.

I discovered this deadlock condition awhile ago working on RAMster
but it affects zcache as well.  The list spinlock must be
locked prior to the page spinlock and released after.  As
a result, the page copy must also be done while the locks are held.

Applies to 3.2.  Konrad, please push (via GregKH?)...
this is definitely a bug fix so need not be pushed during
a -rc0 window.

Signed-off-by: Dan Magenheimer <>
Acked-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agozcache: Set SWIZ_BITS to 8 to reduce tmem bucket lock contention.
Dan Magenheimer [Mon, 23 Jan 2012 21:52:20 +0000 (16:52 -0500)]
zcache: Set SWIZ_BITS to 8 to reduce tmem bucket lock contention.

commit e8b4553457e78bcff90f70a31212a40a8fd4f0db upstream.

SWIZ_BITS > 8 results in a much larger number of "tmem_obj"
allocations, likely one per page-placed-in-frontswap.  The
tmem_obj is not huge (roughly 100 bytes), but it is large
enough to add a not-insignificant memory overhead to zcache.

The SWIZ_BITS=8  will get roughly the same lock contention
without the space wastage.

The effect of SWIZ_BITS can be thought of as "2^SWIZ_BITS is
the number of unique oids that be generated" (This concept is
limited to frontswap's use of tmem).

Acked-by: Seth Jennings <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoUSB: add new zte 3g-dongle's pid to option.c
Rui li [Tue, 31 Jan 2012 07:27:33 +0000 (15:27 +0800)]
USB: add new zte 3g-dongle's pid to option.c

commit 1608ea5f4b5d6262cd6e808839491cfb2a67405a upstream.

As ZTE have and will use more pid for new products this year,
so we need to add some new zte 3g-dongle's pid on option.c ,
and delete one pid 0x0154 because it use for mass-storage port.

Signed-off-by: Rui li <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoUSB: usbserial: add new PID number (0xa951) to the ftdi driver
Milan Kocian [Fri, 3 Feb 2012 13:28:00 +0000 (14:28 +0100)]
USB: usbserial: add new PID number (0xa951) to the ftdi driver

commit 90451e6973a5da155c6f315a409ca0a8d3ce6b76 upstream.

Signed-off-by: Milan Kocian <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agousb: Skip PCI USB quirk handling for Netlogic XLP
Jayachandran C [Fri, 27 Jan 2012 14:57:32 +0000 (20:27 +0530)]
usb: Skip PCI USB quirk handling for Netlogic XLP

commit e4436a7c17ac2b5e138f93f83a541cba9b311685 upstream.

The Netlogic XLP SoC's on-chip USB controller appears as a PCI
USB device, but does not need the EHCI/OHCI handoff done in

The pci-quirks.c is enabled for all vendors and devices, and is
enabled if USB and PCI are configured.

If we do not skip the qurik handling on XLP, the readb() call in
ehci_bios_handoff() will cause a crash since byte access is not
supported for EHCI registers in XLP.

Signed-off-by: Jayachandran C <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agousb: gadget: zero: fix bug in loopback autoresume handling
Timo Juhani Lindfors [Sun, 29 Jan 2012 14:12:13 +0000 (16:12 +0200)]
usb: gadget: zero: fix bug in loopback autoresume handling

commit 683da59d7b8ae04891636d4b59893cd4e9b0b7e5 upstream.

ab943a2e125b (USB: gadget: gadget zero uses new suspend/resume hooks)
introduced a copy-paste error where f_loopback.c writes to a variable
declared in f_sourcesink.c. This prevents one from creating gadgets
that only have a loopback function.

Signed-off-by: Timo Juhani Lindfors <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agousb: ch9.h: usb_endpoint_maxp() uses __le16_to_cpu()
Kuninori Morimoto [Wed, 1 Feb 2012 00:43:50 +0000 (16:43 -0800)]
usb: ch9.h: usb_endpoint_maxp() uses __le16_to_cpu()

commit 9c0a835a9d9aed41bcf9c287f5069133a6e2a87b upstream.

The usb/ch9.h will be installed to /usr/include/linux,
and be used from user space.
But le16_to_cpu() is only defined for kernel code.
Without this patch, user space compile will be broken.
Special thanks to Stefan Becker

Reported-by: Stefan Becker <>
Signed-off-by: Kuninori Morimoto <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agostaging: r8712u: Use asynchronous firmware loading
Larry Finger [Mon, 6 Feb 2012 03:12:26 +0000 (21:12 -0600)]
staging: r8712u: Use asynchronous firmware loading

commit 8c213fa59199f9673d66970d6940fa093186642f upstream.

In, failure of driver r8712u is
reported, with a timeout during module loading due to synchronous loading
of the firmware. The code now uses request_firmware_nowait().

Signed-off-by: Larry Finger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agostaging: r8712u: Add new Sitecom UsB ID
Larry Finger [Sat, 7 Jan 2012 16:07:03 +0000 (10:07 -0600)]
staging: r8712u: Add new Sitecom UsB ID

commit 1793bf1deddc8ce25dc41925d5dbe64536c841b6 upstream.

Add USB ID for SITECOM WLA-1000 V1 001 WLAN

Reported-and-tested-by: Roland Gruber <>
Reported-and-tested-by: Dario Lucia <>
Signed-off-by: Larry Finger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoStaging: asus_oled: fix NULL-ptr crash on unloading
Pekka Paalanen [Sun, 22 Jan 2012 14:33:47 +0000 (16:33 +0200)]
Staging: asus_oled: fix NULL-ptr crash on unloading

commit 3589e74595a4332ebf77b5ed006f3c6686071ecd upstream.

Asus_oled triggers the following bug on module unloading:

 usbcore: deregistering interface driver asus-oled
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
 IP: [<ffffffff8111292b>] sysfs_delete_link+0x30/0x66

 Call Trace:
  [<ffffffff81225373>] device_remove_class_symlinks+0x6b/0x70
  [<ffffffff812256a8>] device_del+0x9f/0x1ab
  [<ffffffff812257c5>] device_unregister+0x11/0x1e
  [<ffffffffa000cb82>] asus_oled_disconnect+0x4f/0x9e [asus_oled]
  [<ffffffff81277430>] usb_unbind_interface+0x54/0x103
  [<ffffffff812276c4>] __device_release_driver+0xa2/0xeb
  [<ffffffff81227794>] driver_detach+0x87/0xad
  [<ffffffff812269e9>] bus_remove_driver+0x91/0xc1
  [<ffffffff81227fb4>] driver_unregister+0x66/0x6e
  [<ffffffff812771ed>] usb_deregister+0xbb/0xc4
  [<ffffffffa000ce87>] asus_oled_exit+0x2f/0x31 [asus_oled]
  [<ffffffff81068365>] sys_delete_module+0x1b8/0x21b
  [<ffffffff810ae3de>] ? do_munmap+0x2ef/0x313
  [<ffffffff813699bb>] system_call_fastpath+0x16/0x1b

This is due to an incorrect destruction sequence in asus_oled_exit().

Fix the order, fixes the bug. Tested on an Asus G50V laptop only.

Cc: Jakub Schmidtke <>
Signed-off-by: Pekka Paalanen <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoStaging: asus_oled: fix image processing
Pekka Paalanen [Sun, 22 Jan 2012 14:33:46 +0000 (16:33 +0200)]
Staging: asus_oled: fix image processing

commit 635032cb397b396241372fa0ff36ae758e658b23 upstream.

Programming an image was broken, because odev->buf_offs was not advanced
for val == 0 in append_values(). This regression was introduced in:

 commit 1ff12a4aa354bed093a0240d5e6347b1e27601bc
 Author: Kevin A. Granade <>
 Date:   Sat Sep 5 01:03:39 2009 -0500

     Staging: asus_oled: Cleaned up checkpatch issues.

Fix the image processing by special-casing val == 0.

I have tested this change on an Asus G50V laptop only.

Cc: Jakub Schmidtke <>
Cc: Kevin A. Granade <>
Signed-off-by: Pekka Paalanen <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Fail INQUIRY commands with EVPD==0 but PAGE CODE!=0
Roland Dreier [Wed, 18 Jan 2012 02:00:57 +0000 (18:00 -0800)]
target: Fail INQUIRY commands with EVPD==0 but PAGE CODE!=0

commit bf0053550aebe56f3bb5dd793e9de69238b5b945 upstream.

My draft of SPC-4 says:

    If the PAGE CODE field is not set to zero when the EVPD bit is set
    to zero, the command shall be terminated with CHECK CONDITION
    status, with the sense key set to ILLEGAL REQUEST, and the
    additional sense code set to INVALID FIELD IN CDB.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Return correct ASC for unimplemented VPD pages
Roland Dreier [Wed, 18 Jan 2012 02:00:56 +0000 (18:00 -0800)]
target: Return correct ASC for unimplemented VPD pages

commit bb1acb2ee038a6c13ee99e0b9fb44dacb4a9de84 upstream.

My draft of SPC-4 says:

    If the device server does not implement the requested vital product
    data page, then the command shall be terminated with CHECK CONDITION
    status, with the sense key set to ILLEGAL REQUEST, and the
    additional sense code set to INVALID FIELD IN CDB.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Add workaround for zero-length control CDB handling
Nicholas Bellinger [Fri, 13 Jan 2012 20:01:34 +0000 (12:01 -0800)]
target: Add workaround for zero-length control CDB handling

commit 91ec1d3535b2acf12c599045cc19ad9be3c6a47b upstream.

This patch adds a work-around for handling zero allocation length
control CDBs (type SCF_SCSI_CONTROL_SG_IO_CDB) that was causing an
OOPs with the following raw calls:

   # sg_raw -v /dev/sdd 3 0 0 0 0 0
   # sg_raw -v /dev/sdd 0x1a 0 1 0 0 0

This patch will follow existing zero-length handling for data I/O
and silently return with GOOD status.  This addresses the zero length
issue, but the proper long-term resolution for handling arbitary
allocation lengths will be to refactor out data-phase handling in
individual CDB emulation logic within target_core_cdb.c

Reported-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Correct sense key for INVALID FIELD IN {PARAMETER LIST,CDB}
Roland Dreier [Tue, 10 Jan 2012 01:54:00 +0000 (17:54 -0800)]
target: Correct sense key for INVALID FIELD IN {PARAMETER LIST,CDB}

commit 9fbc8909876a2160044e71d376848973b9bfdc3f upstream.

According to SPC-4, the sense key for commands that are failed with
ILLEGAL REQUEST (5h) rather than ABORTED COMMAND (Bh).  Without this
patch, a tcm_loop LUN incorrectly gives:

    # sg_raw -r 1 -v /dev/sda 3 1 0 0 ff 0
    Sense Information:
     Fixed format, current;  Sense key: Aborted Command
     Additional sense: Invalid field in cdb
     Raw sense data (in hex):
            70 00 0b 00 00 00 00 0a  00 00 00 00 24 00 00 00
            00 00

While a real SCSI disk gives:

    Sense Information:
     Fixed format, current;  Sense key: Illegal Request
     Additional sense: Invalid field in cdb
     Raw sense data (in hex):
            70 00 05 00 00 00 00 18  00 00 00 00 24 00 00 00
            00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

with the main point being that the real disk gives a sense key of

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Allow PERSISTENT RESERVE IN for non-reservation holder
Marco Sanvido [Wed, 4 Jan 2012 01:12:58 +0000 (17:12 -0800)]
target: Allow PERSISTENT RESERVE IN for non-reservation holder

commit 6816966a8418b980481b4dced7eddd1796b145e8 upstream.

Initiators that aren't the active reservation holder should be able to
do a PERSISTENT RESERVE IN command in all cases, so add it to the list
of allowed CDBs in core_scsi3_pr_seq_non_holder().

Signed-off-by: Marco Sanvido <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Use correct preempted registration sense code
Marco Sanvido [Wed, 4 Jan 2012 01:12:57 +0000 (17:12 -0800)]
target: Use correct preempted registration sense code

commit 9e08e34e3735ae057eb3834da3570995811b7eb9 upstream.

The comments quote the right parts of the spec:

   * d) Establish a unit attention condition for the
   *    initiator port associated with every I_T nexus
   *    that lost its registration other than the I_T
   *    nexus on which the PERSISTENT RESERVE OUT command
   *    was received, with the additional sense code set


   * e) Establish a unit attention condition for the initiator
   *    port associated with every I_T nexus that lost its
   *    persistent reservation and/or registration, with the
   *    additional sense code set to REGISTRATIONS PREEMPTED;

but the actual code accidentally uses ASCQ_2AH_RESERVATIONS_PREEMPTED

Signed-off-by: Marco Sanvido <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomm: fix UP THP spin_is_locked BUGs
Hugh Dickins [Thu, 9 Feb 2012 01:13:40 +0000 (17:13 -0800)]
mm: fix UP THP spin_is_locked BUGs

commit b9980cdcf2524c5fe15d8cbae9c97b3ed6385563 upstream.

CONFIG_DEBUG_SPINLOCK=n kernel: spin_is_locked() is then always false,
and so triggers some BUGs in Transparent HugePage codepaths.

asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP(x);
but being too lazy to add VM_BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE,
VM_WARN_ON_SMP_ONCE, just test NR_CPUS != 1 in the existing VM_BUG_ONs.

Signed-off-by: Hugh Dickins <>
Cc: Andrea Arcangeli <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomm: compaction: check for overlapping nodes during isolation for migration
Mel Gorman [Thu, 9 Feb 2012 01:13:38 +0000 (17:13 -0800)]
mm: compaction: check for overlapping nodes during isolation for migration

commit dc9086004b3d5db75997a645b3fe08d9138b7ad0 upstream.

When isolating pages for migration, migration starts at the start of a
zone while the free scanner starts at the end of the zone.  Migration
avoids entering a new zone by never going beyond the free scanned.

Unfortunately, in very rare cases nodes can overlap.  When this happens,
migration isolates pages without the LRU lock held, corrupting lists
which will trigger errors in reclaim or during page free such as in the
following oops

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffff810f795c>] free_pcppages_bulk+0xcc/0x450
  PGD 1dda554067 PUD 1e1cb58067 PMD 0
  Oops: 0000 [#1] SMP
  CPU 37
  Pid: 17088, comm: memcg_process_s Tainted: G            X
  RIP: free_pcppages_bulk+0xcc/0x450
  Process memcg_process_s (pid: 17088, threadinfo ffff881c2926e000, task ffff881c2926c0c0)
  Call Trace:

The "X" in the taint flag means that external modules were loaded but but
is unrelated to the bug triggering.  The real problem was because the PFN
layout looks like this

  Zone PFN ranges:
    DMA      0x00000010 -> 0x00001000
    DMA32    0x00001000 -> 0x00100000
    Normal   0x00100000 -> 0x01e80000
  Movable zone start PFN for each node
  early_node_map[14] active PFN ranges
      0: 0x00000010 -> 0x0000009b
      0: 0x00000100 -> 0x0007a1ec
      0: 0x0007a354 -> 0x0007a379
      0: 0x0007f7ff -> 0x0007f800
      0: 0x00100000 -> 0x00680000
      1: 0x00680000 -> 0x00e80000
      0: 0x00e80000 -> 0x01080000
      1: 0x01080000 -> 0x01280000
      0: 0x01280000 -> 0x01480000
      1: 0x01480000 -> 0x01680000
      0: 0x01680000 -> 0x01880000
      1: 0x01880000 -> 0x01a80000
      0: 0x01a80000 -> 0x01c80000
      1: 0x01c80000 -> 0x01e80000

The fix is straight-forward.  isolate_migratepages() has to make a
similar check to isolate_freepage to ensure that it never isolates pages
from a zone it does not hold the LRU lock for.

This was discovered in a 3.0-based kernel but it affects 3.1.x, 3.2.x
and current mainline.

Signed-off-by: Mel Gorman <>
Acked-by: Michal Nazarewicz <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiommu/msm: Fix error handling in msm_iommu_unmap()
Joerg Roedel [Thu, 26 Jan 2012 17:25:37 +0000 (18:25 +0100)]
iommu/msm: Fix error handling in msm_iommu_unmap()

commit 05df1f3c2afaef5672627f2b7095f0d4c4dbc3a0 upstream.

Error handling in msm_iommu_unmap() is broken. On some error
conditions retval is set to a non-zero value which causes
the function to return 'len' at the end. This hides the
error from the user. Zero should be returned in those error

Cc: David Brown <>
Cc: Stepan Moskovchenko <>
Signed-off-by: Joerg Roedel <>
Acked-by: David Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiommu/amd: Work around broken IVRS tables
Joerg Roedel [Wed, 18 Jan 2012 13:03:11 +0000 (14:03 +0100)]
iommu/amd: Work around broken IVRS tables

commit af1be04901e27ce669b4ecde1c953d5c939498f5 upstream.

On some systems the IVRS table does not contain all PCI
devices present in the system. In case a device not present
in the IVRS table is translated by the IOMMU no DMA is
possible from that device by default.
This patch fixes this by removing the DTE entry for every
PCI device present in the system and not covered by IVRS.

Signed-off-by: Joerg Roedel <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: oxygen, virtuoso: fix exchanged L/R volumes of aux and CD inputs
Clemens Ladisch [Sat, 4 Feb 2012 19:56:47 +0000 (20:56 +0100)]
ALSA: oxygen, virtuoso: fix exchanged L/R volumes of aux and CD inputs

commit 2492250e4412c6411324c14ab289629360640b0a upstream.

The driver accidentally exchanged the left/right fields for stereo AC'97
mixer registers.  This affected only the aux and CD inputs because the
line input bypasses the AC'97 codec and the mic input is mono; cards
without AC'97 (Xonar DS/DG/HDAV Slim, HG2PCI, HiFier) were not affected.

Reported-and-tested-by: Abby Cedar <>
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agopcmcia: fix socket refcount decrementing on each resume
Russell King [Thu, 9 Feb 2012 01:13:41 +0000 (17:13 -0800)]
pcmcia: fix socket refcount decrementing on each resume

commit 025e4ab3db07fcbf62c01e4f30d1012234beb980 upstream.

This fixes a memory-corrupting bug: not only does it cause the warning,
but as a result of dropping the refcount to zero, it causes the
pcmcia_socket0 device structure to be freed while it still has
references, causing slab caches corruption.  A fatal oops quickly
follows this warning - often even just a 'dmesg' following the warning
causes the kernel to oops.

While testing suspend/resume on an ARM device with PCMCIA support, and a
CF card inserted, I found that after five suspend and resumes, the
kernel would complain, and shortly die after with slab corruption.

  WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()

As the message doesn't give a clue about which kobject, and the built-in
debugging in drivers/base/power/main.c happens too late, this was added
right before each get_device():

  printk("%s: %p [%s] %u\n", __func__, dev, kobject_name(&dev->kobj), atomic_read(&dev->kobj.kref.refcount));

and on the 3rd s2ram cycle, the following behaviour observed:

On the 3rd suspend/resume cycle:

  dpm_prepare: c1a0d998 [pcmcia_socket0] 3
  dpm_suspend: c1a0d998 [pcmcia_socket0] 3
  dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 3
  dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 3
  dpm_resume: c1a0d998 [pcmcia_socket0] 3
  dpm_complete: c1a0d998 [pcmcia_socket0] 2


  dpm_prepare: c1a0d998 [pcmcia_socket0] 2
  dpm_suspend: c1a0d998 [pcmcia_socket0] 2
  dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 2
  dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 2
  dpm_resume: c1a0d998 [pcmcia_socket0] 2
  dpm_complete: c1a0d998 [pcmcia_socket0] 1


  dpm_prepare: c1a0d998 [pcmcia_socket0] 1
  dpm_suspend: c1a0d998 [pcmcia_socket0] 1
  dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 1
  dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 1
  dpm_resume: c1a0d998 [pcmcia_socket0] 1
  dpm_complete: c1a0d998 [pcmcia_socket0] 0
  ------------[ cut here ]------------
  WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()
  Modules linked in: ucb1x00_core
  [<c0212090>] (dump_backtrace+0x0/0x110) from [<c04799dc>] (dump_stack+0x18/0x1c)
  [<c04799c4>] (dump_stack+0x0/0x1c) from [<c021cba0>] (warn_slowpath_common+0x50/0x68)
  [<c021cb50>] (warn_slowpath_common+0x0/0x68) from [<c021cbdc>] (warn_slowpath_null+0x24/0x28)
  [<c021cbb8>] (warn_slowpath_null+0x0/0x28) from [<c0335374>] (kobject_get+0x28/0x50)
  [<c033534c>] (kobject_get+0x0/0x50) from [<c03804f4>] (get_device+0x1c/0x24)
  [<c0388c90>] (dpm_complete+0x0/0x1a0) from [<c0389cc0>] (dpm_resume_end+0x1c/0x20)

Looking at commit 7b24e7988263 ("pcmcia: split up central event handler"),
the following change was made to cs.c:

                return 0;
-       send_event(skt, CS_EVENT_PM_RESUME, CS_EVENT_PRI_LOW);
+       if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
+               skt->callback->early_resume(skt);
        return 0;

And the corresponding change in ds.c is from:

-static int ds_event(struct pcmcia_socket *skt, event_t event, int priority)
-       struct pcmcia_socket *s = pcmcia_get_socket(skt);
-       switch (event) {
-       case CS_EVENT_PM_RESUME:
-               if (verify_cis_cache(skt) != 0) {
-                       dev_dbg(&skt->dev, "cis mismatch - different card\n");
-                       /* first, remove the card */
-                       ds_event(skt, CS_EVENT_CARD_REMOVAL, CS_EVENT_PRI_HIGH);
-                       mutex_lock(&s->ops_mutex);
-                       destroy_cis_cache(skt);
-                       kfree(skt->fake_cis);
-                       skt->fake_cis = NULL;
-                       s->functions = 0;
-                       mutex_unlock(&s->ops_mutex);
-                       /* now, add the new card */
-                       ds_event(skt, CS_EVENT_CARD_INSERTION,
-                                CS_EVENT_PRI_LOW);
-               }
-               break;
-    }

-    pcmcia_put_socket(s);

-    return 0;
-} /* ds_event */


+static int pcmcia_bus_early_resume(struct pcmcia_socket *skt)
+       if (!verify_cis_cache(skt)) {
+               pcmcia_put_socket(skt);
+               return 0;
+       }

+       dev_dbg(&skt->dev, "cis mismatch - different card\n");

+       /* first, remove the card */
+       pcmcia_bus_remove(skt);
+       mutex_lock(&skt->ops_mutex);
+       destroy_cis_cache(skt);
+       kfree(skt->fake_cis);
+       skt->fake_cis = NULL;
+       skt->functions = 0;
+       mutex_unlock(&skt->ops_mutex);

+       /* now, add the new card */
+       pcmcia_bus_add(skt);
+       return 0;

As can be seen, the original function called pcmcia_get_socket() and
pcmcia_put_socket() around the guts, whereas the replacement code
calls pcmcia_put_socket() only in one path.  This creates an imbalance
in the refcounting.

Testing with pcmcia_put_socket() put removed shows that the bug is gone:

  dpm_suspend: c1a10998 [pcmcia_socket0] 5
  dpm_suspend_noirq: c1a10998 [pcmcia_socket0] 5
  dpm_resume_noirq: c1a10998 [pcmcia_socket0] 5
  dpm_resume: c1a10998 [pcmcia_socket0] 5
  dpm_complete: c1a10998 [pcmcia_socket0] 5

Tested-by: Russell King <>
Signed-off-by: Russell King <>
Cc: Dominik Brodowski <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: wm8994: Fix typo in VMID ramp setting
Mark Brown [Tue, 7 Feb 2012 17:24:19 +0000 (17:24 +0000)]
ASoC: wm8994: Fix typo in VMID ramp setting

commit f647e1526fd6c7c8ab720781c40d11e11f930e93 upstream.

The VMID ramp rate is supposed to be 0x3, not 11b. Fix that.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: wm8994: Enabling VMID should take a runtime PM reference
Mark Brown [Mon, 6 Feb 2012 12:07:08 +0000 (12:07 +0000)]
ASoC: wm8994: Enabling VMID should take a runtime PM reference

commit db966f8abb9ba74f7d5a7230f51572f52c31c4e5 upstream.

We can enable VMID independently of the bias in some use cases so we need
to ensure that the core device is powered up.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: wm8962: Fix word length configuration
Susan Gao [Mon, 30 Jan 2012 21:57:04 +0000 (13:57 -0800)]
ASoC: wm8962: Fix word length configuration

commit 2b6712b19531e22455e7fa18371c5ba9eec76699 upstream.

Signed-off-by: Susan Gao <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: wm_hubs: Correct line input to line output 2 paths
Mark Brown [Wed, 1 Feb 2012 23:46:58 +0000 (23:46 +0000)]
ASoC: wm_hubs: Correct line input to line output 2 paths

commit 43b6cec27e1e50a1de3eff47e66e502f3fe7e66e upstream.

The second line output mixer has the controls for the line input bypasses
in the opposite order.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: wm_hubs: Fix routing of input PGAs to line output mixer
Mark Brown [Tue, 31 Jan 2012 11:55:32 +0000 (11:55 +0000)]
ASoC: wm_hubs: Fix routing of input PGAs to line output mixer

commit ee76744c51ec342df9822b4a85dbbfc3887b6d60 upstream.

IN1L/R is routed to both line output mixers, we don't route IN1 to LINEOUT1
and IN2 to LINEOUT2.

Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiscsi-target: Fix discovery with INADDR_ANY and IN6ADDR_ANY_INIT
Nicholas Bellinger [Tue, 17 Jan 2012 07:33:48 +0000 (23:33 -0800)]
iscsi-target: Fix discovery with INADDR_ANY and IN6ADDR_ANY_INIT

commit 2f9bc894c67dbacae5a6a9875818d2a18a918d18 upstream.

This patch addresses a bug with sendtargets discovery where INADDR_ANY (
+ IN6ADDR_ANY_INIT ([0:0:0:0:0:0:0:0]) network portals where incorrectly being
reported back to initiators instead of the address of the connecting interface.
To address this, save local socket ->getname() output during iscsi login setup,
and makes iscsit_build_sendtargets_response() return these TargetAddress keys
when INADDR_ANY or IN6ADDR_ANY_INIT portals are in use.

Reported-by: Dax Kelson <>
Reported-by: Andy Grover <>
Cc: David S. Miller <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiscsi-target: Fix double list_add with iscsit_alloc_buffs reject
Nicholas Bellinger [Tue, 17 Jan 2012 01:11:54 +0000 (17:11 -0800)]
iscsi-target: Fix double list_add with iscsit_alloc_buffs reject

commit cd931ee62fd0258fc85c76a7c5499fe85e0f3436 upstream.

This patch fixes a bug where the iscsit_add_reject_from_cmd() call
from a failure to iscsit_alloc_buffs() was incorrectly passing
add_to_conn=1 and causing a double list_add after iscsi_cmd->i_list
had already been added in iscsit_handle_scsi_cmd().

Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiscsi-target: Fix reject release handling in iscsit_free_cmd()
Nicholas Bellinger [Tue, 17 Jan 2012 00:04:15 +0000 (16:04 -0800)]
iscsi-target: Fix reject release handling in iscsit_free_cmd()

commit c1ce4bd56f2846de55043374598fd929ad3b711b upstream.

This patch addresses a bug where iscsit_free_cmd() was incorrectly calling
iscsit_release_cmd() for ISCSI_OP_REJECT because iscsi_add_reject*() will
overwrite the original iscsi_cmd->iscsi_opcode assignment.  This bug was
introduced with the following commit:

commit 0be67f2ed8f577d2c72d917928394c5885fa9134
Author: Nicholas Bellinger <>
Date:   Sun Oct 9 01:48:14 2011 -0700

    iscsi-target: Remove SCF_SE_LUN_CMD flag abuses

and was manifesting itself as list corruption with the following:

[  131.191092] ------------[ cut here ]------------
[  131.191092] WARNING: at lib/list_debug.c:53 __list_del_entry+0x8d/0x98()
[  131.191092] Hardware name: VMware Virtual Platform
[  131.191092] list_del corruption. prev->next should be ffff880022d3c100, but was 6b6b6b6b6b6b6b6b
[  131.191092] Modules linked in: tcm_vhost ib_srpt ib_cm ib_sa ib_mad ib_core tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc crc32c iscsi_target_mod target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi sr_mod cdrom sd_mod e1000 ata_piix libata mptspi mptscsih mptbase [last unloaded: scsi_wait_scan]
[  131.191092] Pid: 2250, comm: iscsi_ttx Tainted: G        W    3.2.0-rc4+ #42
[  131.191092] Call Trace:
[  131.191092]  [<ffffffff8103b553>] warn_slowpath_common+0x80/0x98
[  131.191092]  [<ffffffff8103b5ff>] warn_slowpath_fmt+0x41/0x43
[  131.191092]  [<ffffffff811d0279>] __list_del_entry+0x8d/0x98
[  131.191092]  [<ffffffffa01395c9>] transport_lun_remove_cmd+0x9b/0xb7 [target_core_mod]
[  131.191092]  [<ffffffffa013a55c>] transport_generic_free_cmd+0x5d/0x71 [target_core_mod]
[  131.191092]  [<ffffffffa01a012b>] iscsit_free_cmd+0x1e/0x27 [iscsi_target_mod]
[  131.191092]  [<ffffffffa01a13be>] iscsit_close_connection+0x14d/0x5b2 [iscsi_target_mod]
[  131.191092]  [<ffffffffa0196a0c>] iscsit_take_action_for_connection_exit+0xdb/0xe0 [iscsi_target_mod]
[  131.191092]  [<ffffffffa01a55d4>] iscsi_target_tx_thread+0x15cb/0x1608 [iscsi_target_mod]
[  131.191092]  [<ffffffff8103609a>] ? check_preempt_wakeup+0x121/0x185
[  131.191092]  [<ffffffff81030801>] ? __dequeue_entity+0x2e/0x33
[  131.191092]  [<ffffffffa01a4009>] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod]
[  131.191092]  [<ffffffffa01a4009>] ? iscsit_send_text_rsp+0x25f/0x25f [iscsi_target_mod]
[  131.191092]  [<ffffffff8138f706>] ? schedule+0x55/0x57
[  131.191092]  [<ffffffff81056c7d>] kthread+0x7d/0x85
[  131.191092]  [<ffffffff81399534>] kernel_thread_helper+0x4/0x10
[  131.191092]  [<ffffffff81056c00>] ? kthread_worker_fn+0x16d/0x16d
[  131.191092]  [<ffffffff81399530>] ? gs_change+0x13/0x13

Reported-by: <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agolockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging
Ben Hutchings [Wed, 7 Dec 2011 14:30:58 +0000 (14:30 +0000)]
lockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging

commit 9ec84acee1e221d99dc33237bff5e82839d10cc0 upstream.

We do want to allow lock debugging for GPL-compatible modules
that are not (yet) built in-tree.  This was disabled as a
side-effect of commit 2449b8ba0745327c5fa49a8d9acffe03b2eded69
('module,bug: Add TAINT_OOT_MODULE flag for modules not built
in-tree').  Lock debug warnings now include taint flags, so
kernel developers should still be able to deflect warnings
caused by out-of-tree modules.

The TAINT_PROPRIETARY_MODULE flag for non-GPL-compatible modules
will still disable lock debugging.

Signed-off-by: Ben Hutchings <>
Cc: Nick Bowler <>
Cc: Dave Jones <>
Cc: Rusty Russell <>
Cc: Randy Dunlap <>
Cc: Debian kernel maintainers <>
Cc: Peter Zijlstra <>
Cc: Alan Cox <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agolockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep
Peter Zijlstra [Mon, 14 Nov 2011 12:13:49 +0000 (13:13 +0100)]
lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep

commit df754e6af2f237a6c020c0daff55a1a609338e31 upstream.

It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false
lockdep messages, so do not disable lockdep in that case.
We still want to keep lockdep disabled in the

  - bin-only modules can cause various instabilities in
    their and in unrelated kernel code

  - they are impossible to debug for kernel developers

  - they also typically do not have the copyright license
    permission to link to the GPL-ed lockdep code.

Suggested-by: Ben Hutchings <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoatmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
Hubert Feurstein [Mon, 9 Jan 2012 16:23:57 +0000 (17:23 +0100)]
atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume

commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream.

An error was existing in the saving of CONTRAST_CTR register
across suspend/resume.

Signed-off-by: Hubert Feurstein <>
Signed-off-by: Nicolas Ferre <>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <>
Signed-off-by: Florian Tobias Schandinat <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocifs: Fix oops in session setup code for null user mounts
Shirish Pargaonkar [Thu, 2 Feb 2012 21:28:28 +0000 (15:28 -0600)]
cifs: Fix oops in session setup code for null user mounts

commit de47a4176c532ef5961b8a46a2d541a3517412d3 upstream.

For null user mounts, do not invoke string length function
during session setup.

Reported-and-Tested-by: Chris Clayton <>
Acked-by: Jeff Layton <>
Signed-off-by: Shirish Pargaonkar <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agohwmon: (w83627ehf) Fix number of fans for NCT6776F
Guenter Roeck [Fri, 27 Jan 2012 13:43:59 +0000 (05:43 -0800)]
hwmon: (w83627ehf) Fix number of fans for NCT6776F

commit 585c0fd8216e0c9f98e2434092af7ec0f999522d upstream.

NCT6776F can select fan input pins for fans 3 to 5 with a secondary set of
chip register bits. Check that second set of bits in addition to the first set
to detect if fans 3..5 are monitored.

Signed-off-by: Guenter Roeck <>
Acked-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoeCryptfs: Infinite loop due to overflow in ecryptfs_write()
Li Wang [Thu, 19 Jan 2012 01:44:36 +0000 (09:44 +0800)]
eCryptfs: Infinite loop due to overflow in ecryptfs_write()

commit 684a3ff7e69acc7c678d1a1394fe9e757993fd34 upstream.

ecryptfs_write() can enter an infinite loop when truncating a file to a
size larger than 4G. This only happens on architectures where size_t is
represented by 32 bits.

This was caused by a size_t overflow due to it incorrectly being used to
store the result of a calculation which uses potentially large values of
type loff_t.

[ rewrite subject and commit message]
Signed-off-by: Li Wang <>
Signed-off-by: Yunchuan Wen <>
Reviewed-by: Cong Wang <>
Signed-off-by: Tyler Hicks <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: protect force_wake_(get|put) with the gt_lock
Daniel Vetter [Wed, 14 Dec 2011 12:57:03 +0000 (13:57 +0100)]
drm/i915: protect force_wake_(get|put) with the gt_lock

commit 9f1f46a45a681d357d1ceedecec3671a5ae957f4 upstream.

The problem this patch solves is that the forcewake accounting
necessary for register reads is protected by dev->struct_mutex. But the
hangcheck and error_capture code need to access registers without
grabbing this mutex because we hold it while waiting for the gpu.
So a new lock is required. Because currently the error_state capture
is called from the error irq handler and the hangcheck code runs from
a timer, it needs to be an irqsafe spinlock (note that the registers
used by the irq handler (neglecting the error handling part) only uses
registers that don't need the forcewake dance).

We could tune this down to a normal spinlock when we rework the
error_state capture and hangcheck code to run from a workqueue.  But
we don't have any read in a fastpath that needs forcewake, so I've
decided to not care much about overhead.

This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
snb on recent kernels - something must have slightly changed the
timings. On previous kernels it only trigger a WARN about the broken

v2: Drop the previous patch for the register writes.

v3: Improve the commit message per Chris Wilson's suggestions.

Signed-Off-by: Daniel Vetter <>
Reviewed-by: Chris Wilson <>
Reviewed-by: Eugeni Dodonov <>
Signed-off-by: Keith Packard <>
Signed-off-by: Eugeni Dodonov <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: convert force_wake_get to func pointer in the gpu reset code
Daniel Vetter [Sat, 14 Jan 2012 00:20:06 +0000 (16:20 -0800)]
drm/i915: convert force_wake_get to func pointer in the gpu reset code

commit 8109021313c7a3d8947677391ce6ab9cd0bb1d28 upstream.

This was forgotten in the original multi-threaded forcewake

commit 8d715f0024f64ad1b1be85d8c081cf577944c847
Author: Keith Packard <keithp at>
Date:   Fri Nov 18 20:39:01 2011 -0800

    drm/i915: add multi-threaded forcewake support

Signed-off-by: Daniel Vetter <>
Reviewed-by: Eugeni Dodonov <>
Signed-off-by: Keith Packard <>
Signed-off-by: Eugeni Dodonov <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: handle 3rd pipe
Eugeni Dodonov [Sun, 8 Jan 2012 01:40:35 +0000 (23:40 -0200)]
drm/i915: handle 3rd pipe

commit 07c1e8c1462fa7324de4c36ae9e55da2abd79cee upstream.

We don't need to check 3rd pipe specifically, as it shares PLL with some
other one.

Signed-off-by: Eugeni Dodonov <>
Reviewed-by: Jesse Barnes <>
Signed-off-by: Keith Packard <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: Fix TV Out refresh rate.
Rodrigo Vivi [Wed, 14 Dec 2011 23:10:06 +0000 (21:10 -0200)]
drm/i915: Fix TV Out refresh rate.

commit 23bd15ec662344dc10e9918fdd0dbc58bc71526d upstream.

TV Out refresh rate was half of the specification for almost all modes.
Due to this reason pixel clock was so low for some modes causing flickering screen.

Signed-off-by: Rodrigo Vivi <>
Reviewed-by: Jesse Barnes <>
Signed-off-by: Keith Packard <>
Signed-off-by: Eugeni Dodonov <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: check ACTHD of all rings
Daniel Vetter [Sun, 27 Nov 2011 17:58:17 +0000 (18:58 +0100)]
drm/i915: check ACTHD of all rings

commit 097354eb14fa94d31a09c64d640643f58e4a5a9a upstream.

Otherwise hangcheck spuriously fires when running blitter/bsd-only

Contrary to a similar patch by Ben Widawsky this does not check
INSTDONE of the other rings. Chris Wilson implied that in a failure to
detect a hang, most likely because INSTDONE was fluctuating. Thus only
check ACTHD, which as far as I know is rather reliable. Also, blitter
and bsd rings can't launch complex tasks from a single instruction
(like 3D_PRIM on the render with complex or even infinite shaders).

This fixes spurious gpu hang detection when running
tests/gem_hangcheck_forcewake on snb/ivb.

Signed-Off-by: Daniel Vetter <>
Reviewed-by: Chris Wilson <>
Signed-off-by: Keith Packard <>
Signed-off-by: Eugeni Dodonov <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: DisplayPort hot remove notification to audio driver
Wu Fengguang [Fri, 9 Dec 2011 12:42:21 +0000 (20:42 +0800)]
drm/i915: DisplayPort hot remove notification to audio driver

commit 832afda6a7d7235ef0e09f4ec46736861540da6d upstream.

On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly,
so that the audio driver will receive hot plug events and take action
to refresh its device state and ELD contents.

Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled
only when the link training is complete and set to "Normal".

Tested OK for both hot plug/remove and DPMS on/off.

Signed-off-by: Wu Fengguang <>
Signed-off-by: Keith Packard <>
Signed-off-by: Eugeni Dodonov <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: HDMI hot remove notification to audio driver
Wu Fengguang [Fri, 9 Dec 2011 12:42:20 +0000 (20:42 +0800)]
drm/i915: HDMI hot remove notification to audio driver

commit 2deed761188d7480eb5f7efbfe7aa77f09322ed8 upstream.

On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that
the audio driver will receive hot plug events and take action to refresh
its device state and ELD contents.

The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing
HDMI audio after DPMS on.

CC: Wang Zhenyu <>
Signed-off-by: Wu Fengguang <>
Signed-off-by: Keith Packard <>
Signed-off-by: Eugeni Dodonov <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoudf: Mark LVID buffer as uptodate before marking it dirty
Jan Kara [Fri, 23 Dec 2011 10:53:07 +0000 (11:53 +0100)]
udf: Mark LVID buffer as uptodate before marking it dirty

commit 853a0c25baf96b028de1654bea1e0c8857eadf3d upstream.

When we hit EIO while writing LVID, the buffer uptodate bit is cleared.
This then results in an anoying warning from mark_buffer_dirty() when we
write the buffer again. So just set uptodate flag unconditionally.

Reviewed-by: Namjae Jeon <>
Signed-off-by: Jan Kara <>
Cc: Dave Jones <>
Signed-off-by: Greg Kroah-Hartman <>
10 years ago8139cp: fix missing napi_gro_flush.
Francois Romieu [Sun, 8 Jan 2012 13:41:33 +0000 (13:41 +0000)]
8139cp: fix missing napi_gro_flush.

commit b189e810619a676e6b931a942a3e8387f3d39c21 upstream.

The driver uses __napi_complete and napi_gro_receive. Without it, the
driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete.

Signed-off-by: Francois Romieu <>
Tested-by: Marin Glibic <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoPM / Hibernate: Thaw kernel threads in SNAPSHOT_CREATE_IMAGE ioctl path
Srivatsa S. Bhat [Wed, 1 Feb 2012 21:16:36 +0000 (22:16 +0100)]
PM / Hibernate: Thaw kernel threads in SNAPSHOT_CREATE_IMAGE ioctl path

commit fe9161db2e6053da21e4649d77bbefaf3030b11d upstream.

In the SNAPSHOT_CREATE_IMAGE ioctl, if the call to hibernation_snapshot()
fails, the frozen tasks are not thawed.

And in the case of success, if we happen to exit due to a successful freezer
test, all tasks (including those of userspace) are thawed, whereas actually
we should have thawed only the kernel threads at that point. Fix both these

Signed-off-by: Srivatsa S. Bhat <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoPM / Hibernate: Thaw processes in SNAPSHOT_CREATE_IMAGE ioctl test path
Srivatsa S. Bhat [Thu, 1 Dec 2011 21:33:10 +0000 (22:33 +0100)]
PM / Hibernate: Thaw processes in SNAPSHOT_CREATE_IMAGE ioctl test path

commit 97819a26224f019e73d88bb2fd4eb5a614860461 upstream.

Commit 2aede851ddf08666f68ffc17be446420e9d2a056 (PM / Hibernate: Freeze
kernel threads after preallocating memory) moved the freezing of kernel
threads to hibernation_snapshot() function.

So now, if the call to hibernation_snapshot() returns early due to a
successful hibernation test, the caller has to thaw processes to ensure
that the system gets back to its original state.

But in SNAPSHOT_CREATE_IMAGE hibernation ioctl, the caller does not thaw
processes in case hibernation_snapshot() returned due to a successful
freezer test. Fix this issue. But note we still send the value of 'in_suspend'
(which is now 0) to userspace, because we are not in an error path per-se,
and moreover, the value of in_suspend correctly depicts the situation here.

Signed-off-by: Srivatsa S. Bhat <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agosched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW
Chanho Min [Thu, 5 Jan 2012 11:00:19 +0000 (20:00 +0900)]
sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW

commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d upstream.

This issue happens under the following conditions:

 1. preemption is off
 3. RT scheduling class
 4. SMP system

Sequence is as follows:

 1.suppose current task is A. start schedule()
 2.task A is enqueued pushable task at the entry of schedule()
    prev = rq->curr;
 4.pick the task B as next task.
   next = pick_next_task(rq);
 3.rq->curr set to task B and context_switch is started.
   rq->curr = next;
 4.At the entry of context_swtich, release this cpu's rq->lock.
 5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context
 6.try_to_wake_up() which called by ISR acquires rq->lock
      rq = __task_rq_lock(p)
      ttwu_do_wakeup(rq, p, wake_flags);
 7.push_rt_task picks the task A which is enqueued before.
     next_task = pick_next_pushable_task(rq)
 8.At find_lock_lowest_rq(), If double_lock_balance() returns 0,
   lowest_rq can be the remote rq.
  (But,If preemption is on, double_lock_balance always return 1 and it
   does't happen.)
     if (double_lock_balance(rq, lowest_rq))..
 9.find_lock_lowest_rq return the available rq. task A is migrated to
   the remote cpu/rq.
    deactivate_task(rq, next_task, 0);
    set_task_cpu(next_task, lowest_rq->cpu);
    activate_task(lowest_rq, next_task, 0);
 10. But, task A is on irq context at this cpu.
     So, task A is scheduled by two cpus at the same time until restore from IRQ.
     Task A's stack is corrupted.

To fix it, don't migrate an RT task if it's still running.

Signed-off-by: Chanho Min <>
Signed-off-by: Peter Zijlstra <>
Acked-by: Steven Rostedt <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon/kms: fix TRAVIS panel setup
Alex Deucher [Thu, 2 Feb 2012 15:18:00 +0000 (10:18 -0500)]
drm/radeon/kms: fix TRAVIS panel setup

commit 304a48400d9718f74ec35ae46f30868a5f4c4516 upstream.

Different versions of the DP to LVDS bridge chip
need different panel mode settings depending on
the chip version used.


Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon/kms: disable output polling when suspended
Seth Forshee [Wed, 1 Feb 2012 01:06:25 +0000 (19:06 -0600)]
drm/radeon/kms: disable output polling when suspended

commit 86698c20f71d488b32c49ed4687fb3cf8a88a5ca upstream.

Polling the outputs when the device is suspended can result in erroneous
status updates. Disable output polling during suspend to prevent this
from happening.

Signed-off-by: Seth Forshee <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/nouveau/gem: fix fence_sync race / oops
Ben Skeggs [Tue, 10 Jan 2012 00:18:28 +0000 (10:18 +1000)]
drm/nouveau/gem: fix fence_sync race / oops

commit 525895ba388c949aa906f26e3ec5cb1ab041f56b upstream.

Due to a race it was possible for a fence to be destroyed while another
thread was trying to synchronise with it.  If this happened in the fallback
non-semaphore path, it lead to the following oops due to fence->channel
being NULL.

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau]
*pde = a649c067
Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]

Pid: 2255, comm: gnome-shell Tainted: G           O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1
EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
 7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
 00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
 00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
Call Trace:
 [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
 [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau]
 [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
 [<fa964046>] validate_list+0x176/0x300 [nouveau]
 [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm]
 [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
 [<c0406481>] ? die+0x31/0x80
 [<f7c93d98>] drm_ioctl+0x388/0x490 [drm]
 [<c0406481>] ? die+0x31/0x80
 [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
 [<c0635c7b>] ? file_has_perm+0xcb/0xe0
 [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm]
 [<c0564f56>] do_vfs_ioctl+0x86/0x5b0
 [<c0406481>] ? die+0x31/0x80
 [<c0635f22>] ? selinux_file_ioctl+0x62/0x130
 [<c0554f30>] ? fget_light+0x30/0x340
 [<c05654ef>] sys_ioctl+0x6f/0x80
 [<c099e3a4>] syscall_call+0x7/0xb
 [<c0406481>] ? die+0x31/0x80
 [<c0406481>] ? die+0x31/0x80

Signed-off-by: Ben Skeggs <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon: Set DESKTOP_HEIGHT register to the framebuffer (not mode) height.
Michel Dänzer [Wed, 1 Feb 2012 11:09:55 +0000 (12:09 +0100)]
drm/radeon: Set DESKTOP_HEIGHT register to the framebuffer (not mode) height.

commit 1b61925061660009f5b8047f93c5297e04541273 upstream.

The value of this register is transferred to the V_COUNTER register at the
beginning of vertical blank. V_COUNTER is the reference for VLINE waits and
so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the
beginning of vertical blank, and VLINE waits excluding the whole scanout area
could never finish (possibly only if VIEWPORT_Y_START is larger than the length
of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer
height should prevent this for any kind of VLINE wait.

Fixes .

Signed-off-by: Michel Dänzer <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoPM / QoS: CPU C-state breakage with PM Qos change
Venkatesh Pallipadi [Fri, 3 Feb 2012 21:22:25 +0000 (22:22 +0100)]
PM / QoS: CPU C-state breakage with PM Qos change

commit d020283dc694c9ec31b410f522252f7a8397e67d upstream.

Looks like change "PM QoS: Move and rename the implementation files"
merged during the 3.2 development cycle made PM QoS depend on
CONFIG_PM which depends on (PM_SLEEP || PM_RUNTIME).

That breaks CPU C-states with kernels not having these CONFIGs, causing CPUs
to spend time in Polling loop idle instead of going into deep C-states,
consuming way way more power. This is with either acpi idle or intel idle

Either CONFIG_PM should be enabled with any pm_qos users or
the !CONFIG_PM pm_qos_request() should return sane defaults not to break
the existing users. Here's is the patch for the latter option.

[rjw: Modified the changelog slightly.]

Signed-off-by: Venkatesh Pallipadi <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoPM / Hibernate: Fix s2disk regression related to freezing workqueues
Rafael J. Wysocki [Sun, 29 Jan 2012 19:35:52 +0000 (20:35 +0100)]
PM / Hibernate: Fix s2disk regression related to freezing workqueues

commit 181e9bdef37bfcaa41f3ab6c948a2a0d60a268b5 upstream.

Commit 2aede851ddf08666f68ffc17be446420e9d2a056

  PM / Hibernate: Freeze kernel threads after preallocating memory

introduced a mechanism by which kernel threads were frozen after
the preallocation of hibernate image memory to avoid problems with
frozen kernel threads not responding to memory freeing requests.
However, it overlooked the s2disk code path in which the
SNAPSHOT_CREATE_IMAGE ioctl was run directly after SNAPSHOT_FREE,
which caused freeze_workqueues_begin() to BUG(), because it saw
that worqueues had been already frozen.

Although in principle this issue might be addressed by removing
the relevant BUG_ON() from freeze_workqueues_begin(), that would
reintroduce the very problem that commit 2aede851ddf08666f68ffc17be4
attempted to avoid into that particular code path.  For this reason,
to fix the issue at hand, introduce thaw_kernel_threads() and make
the SNAPSHOT_FREE ioctl execute it.

Special thanks to Srivatsa S. Bhat for detailed analysis of the

Reported-and-tested-by: Jiri Slaby <>
Signed-off-by: Rafael J. Wysocki <>
Acked-by: Srivatsa S. Bhat <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomm: compaction: check pfn_valid when entering a new MAX_ORDER_NR_PAGES block during...
Mel Gorman [Fri, 3 Feb 2012 23:37:18 +0000 (15:37 -0800)]
mm: compaction: check pfn_valid when entering a new MAX_ORDER_NR_PAGES block during isolation for migration

commit 0bf380bc70ecba68cb4d74dc656cc2fa8c4d801a upstream.

When isolating for migration, migration starts at the start of a zone
which is not necessarily pageblock aligned.  Further, it stops isolating
when COMPACT_CLUSTER_MAX pages are isolated so migrate_pfn is generally
not aligned.  This allows isolate_migratepages() to call pfn_to_page() on
an invalid PFN which can result in a crash.  This was originally reported
against a 3.0-based kernel with the following trace in a crash dump.

PID: 9902   TASK: d47aecd0  CPU: 0   COMMAND: "memcg_process_s"
 #0 [d72d3ad0] crash_kexec at c028cfdb
 #1 [d72d3b24] oops_end at c05c5322
 #2 [d72d3b38] __bad_area_nosemaphore at c0227e60
 #3 [d72d3bec] bad_area at c0227fb6
 #4 [d72d3c00] do_page_fault at c05c72ec
 #5 [d72d3c80] error_code (via page_fault) at c05c47a4
    EAX: 00000000  EBX: 000c0000  ECX: 00000001  EDX: 00000807  EBP: 000c0000
    DS:  007b      ESI: 00000001  ES:  007b      EDI: f3000a80  GS:  6f50
    CS:  0060      EIP: c030b15a  ERR: ffffffff  EFLAGS: 00010002
 #6 [d72d3cb4] isolate_migratepages at c030b15a
 #7 [d72d3d14] zone_watermark_ok at c02d26cb
 #8 [d72d3d2c] compact_zone at c030b8de
 #9 [d72d3d68] compact_zone_order at c030bba1
#10 [d72d3db4] try_to_compact_pages at c030bc84
#11 [d72d3ddc] __alloc_pages_direct_compact at c02d61e7
#12 [d72d3e08] __alloc_pages_slowpath at c02d66c7
#13 [d72d3e78] __alloc_pages_nodemask at c02d6a97
#14 [d72d3eb8] alloc_pages_vma at c030a845
#15 [d72d3ed4] do_huge_pmd_anonymous_page at c03178eb
#16 [d72d3f00] handle_mm_fault at c02f36c6
#17 [d72d3f30] do_page_fault at c05c70ed
#18 [d72d3fb0] error_code (via page_fault) at c05c47a4
    EAX: b71ff000  EBX: 00000001  ECX: 00001600  EDX: 00000431
    DS:  007b      ESI: 08048950  ES:  007b      EDI: bfaa3788
    SS:  007b      ESP: bfaa36e0  EBP: bfaa3828  GS:  6f50
    CS:  0073      EIP: 080487c8  ERR: ffffffff  EFLAGS: 00010202

It was also reported by Herbert van den Bergh against 3.1-based kernel
with the following snippet from the console log.

BUG: unable to handle kernel paging request at 01c00008
IP: [<c0522399>] isolate_migratepages+0x119/0x390
*pdpt = 000000002f7ce001 *pde = 0000000000000000

It is expected that it also affects 3.2.x and current mainline.

The problem is that pfn_valid is only called on the first PFN being
checked and that PFN is not necessarily aligned.  Lets say we have a case
like this

| = pageblock boundary
m = cc->migrate_pfn
f = cc->free_pfn
o = memory hole


The migrate_pfn is just below a memory hole and the free scanner is beyond
the hole.  When isolate_migratepages started, it scans from migrate_pfn to
migrate_pfn+pageblock_nr_pages which is now in a memory hole.  It checks
pfn_valid() on the first PFN but then scans into the hole where there are
not necessarily valid struct pages.

This patch ensures that isolate_migratepages calls pfn_valid when

Reported-by: Herbert van den Bergh <>
Tested-by: Herbert van den Bergh <>
Signed-off-by: Mel Gorman <>
Acked-by: Michal Nazarewicz <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomm/filemap_xip.c: fix race condition in xip_file_fault()
Carsten Otte [Fri, 3 Feb 2012 23:37:14 +0000 (15:37 -0800)]
mm/filemap_xip.c: fix race condition in xip_file_fault()

commit 99f02ef1f18631eb0a4e0ea0a3d56878dbcb4b90 upstream.

Fix a race condition that shows in conjunction with xip_file_fault() when
two threads of the same user process fault on the same memory page.

In this case, the race winner will install the page table entry and the
unlucky loser will cause an oops: xip_file_fault calls vm_insert_pfn (via
vm_insert_mixed) which drops out at this check:

retval = -EBUSY;
if (!pte_none(*pte))
goto out_unlock;

The resulting -EBUSY return value will trigger a BUG_ON() in

This fix simply considers the fault as fixed in this case, because the
race winner has successfully installed the pte.

[ use conventional (and consistent) comment layout]
Reported-by: David Sadler <>
Signed-off-by: Carsten Otte <>
Reported-by: Louis Alex Eisner <>
Cc: Hugh Dickins <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoat_hdmac: bugfix for enabling channel irq
Nikolaus Voss [Tue, 17 Jan 2012 09:28:33 +0000 (10:28 +0100)]
at_hdmac: bugfix for enabling channel irq

commit bda3a47c886664e86ee14eb79e9072b9e341f575 upstream.

commit 463894705e4089d0ff69e7d877312d496ac70e5b deleted redundant
chan_id and chancnt initialization in dma drivers as this is done
in dma_async_device_register().

However, atc_enable_irq() relied on chan_id set before registering
the device, what left only channel 0 functional for this driver.

This patch introduces atc_enable/disable_chan_irq() as a variant
of atc_enable/disable_irq() with the channel as explicit argument.

Signed-off-by: Nikolaus Voss <>
Signed-off-by: Nicolas Ferre <>
Signed-off-by: Vinod Koul <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoRevert "mtd: atmel_nand: optimize read/write buffer functions"
Artem Bityutskiy [Thu, 2 Feb 2012 11:54:25 +0000 (13:54 +0200)]
Revert "mtd: atmel_nand: optimize read/write buffer functions"

commit 500823195d0c9eec2a4637484f30cc93ec633d4a upstream.

This reverts commit fb5427508abbd635e877fabdf55795488119c2d6.

The reason is that it breaks 16 bits NAND flash as it was reported by
Nikolaus Voss and confirmed by Eric Bénard.

Nicolas Ferre <> alco confirmed:
"After double checking with designers, I must admit that I misunderstood
the way of optimizing accesses to SMC. 16 bit nand is not so common
those days..."

Reported-by: Nikolaus Voss <>
Acked-by: Nicolas Ferre <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomtd: gpmi-nand bugfix: reset the BCH module when it is not MX23
Huang Shijie [Wed, 4 Jan 2012 03:18:46 +0000 (11:18 +0800)]
mtd: gpmi-nand bugfix: reset the BCH module when it is not MX23

commit 9398d1ce09b9009996f7d2468e1d3c785fa6feda upstream.

In MX28, if we do not reset the BCH module. The BCH module may
becomes unstable when the board reboots for several thousands times.
This bug has been catched in customer's production.

The patch adds some comments (some from Wolfram Sang), and fixes it now.

Also change gpmi_reset_block() to static.

Signed-off-by: Huang Shijie <>
Acked-by: Marek Vasut <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agokprobes: fix a memory leak in function pre_handler_kretprobe()
Jiang Liu [Fri, 3 Feb 2012 23:37:16 +0000 (15:37 -0800)]
kprobes: fix a memory leak in function pre_handler_kretprobe()

commit 55ca6140e9bb307efc97a9301a4f501de02a6fd6 upstream.

In function pre_handler_kretprobe(), the allocated kretprobe_instance
object will get leaked if the entry_handler callback returns non-zero.
This may cause all the preallocated kretprobe_instance objects exhausted.

This issue can be reproduced by changing
samples/kprobes/kretprobe_example.c to probe "mutex_unlock".  And the fix
is straightforward: just put the allocated kretprobe_instance object back
onto the free_instances list.

[ use raw_spin_lock/unlock]
Signed-off-by: Jiang Liu <>
Acked-by: Jim Keniston <>
Acked-by: Ananth N Mavinakayanahalli <>
Cc: Masami Hiramatsu <>
Cc: Anil S Keshavamurthy <>
Cc: "David S. Miller" <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoRDMA/core: Fix kernel panic by always initializing qp->usecnt
Bernd Schubert [Fri, 20 Jan 2012 18:43:54 +0000 (18:43 +0000)]
RDMA/core: Fix kernel panic by always initializing qp->usecnt

commit e47e321a35c741ee41b67976f8c6a3a7a42bc5c0 upstream.

We have just been investigating kernel panics related to
cq->ibcq.event_handler() completion calls.  The problem is that
ib_destroy_qp() fails with -EBUSY.

Further investigation revealed qp->usecnt is not initialized.  This
counter was introduced in linux-3.2 by commit 0e0ec7e0638e
("RDMA/core: Export ib_open_qp() to share XRC TGT QPs") but it only
gets initialized for IB_QPT_XRC_TGT, but it is checked in
ib_destroy_qp() for any QP type.

Fix this by initializing qp->usecnt for every QP we create.

Signed-off-by: Bernd Schubert <>
Signed-off-by: Sven Breuner <>
[ Initialize qp->usecnt in uverbs too.  - Sean ]

Signed-off-by: Sean Hefty <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoIB/mlx4: pass SMP vendor-specific attribute MADs to firmware
Jack Morgenstein [Thu, 26 Jan 2012 14:41:33 +0000 (16:41 +0200)]
IB/mlx4: pass SMP vendor-specific attribute MADs to firmware

commit a6f7feae6d19e84253918d88b04153af09d3a243 upstream.

In the current code, vendor-specific MADs (e.g with the FDR-10
attribute) are silently dropped by the driver, resulting in timeouts
at the sending side and inability to query/configure the relevant
feature.  However, the ConnectX firmware is able to handle such MADs.
For unsupported attributes, the firmware returns a GET_RESPONSE MAD
containing an error status.

For example, for a FDR-10 node with LID 11:

    # ibstat mlx4_0 1

    CA: 'mlx4_0'
    Port 1:
    State: Active
    Physical state: LinkUp
    Rate: 40 (FDR10)
    Base lid: 11
    LMC: 0
    SM lid: 24
    Capability mask: 0x02514868
    Port GUID: 0x0002c903002e65d1
    Link layer: InfiniBand

Extended Port Query (EPI) vendor mad timeouts before the patch:

    # smpquery MEPI 11 -d

    ibwarn: [4196] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
    ibwarn: [4196] _do_madrpc: retry 1 (timeout 1000 ms)
    ibwarn: [4196] _do_madrpc: retry 2 (timeout 1000 ms)
    ibwarn: [4196] _do_madrpc: timeout after 3 retries, 3000 ms
    ibwarn: [4196] mad_rpc: _do_madrpc failed; dport (Lid 11)
    smpquery: iberror: [pid 4196] main: failed: operation EPI: ext port info query failed

EPI query works OK with the patch:

    # smpquery MEPI 11 -d

    ibwarn: [6548] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
    ibwarn: [6548] mad_rpc: data offs 64 sz 64
    mad data
    0000 0000 0000 0001 0000 0001 0000 0001
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    # Ext Port info: Lid 11 port 0

Signed-off-by: Jack Morgenstein <>
Signed-off-by: Or Gerlitz <>
Acked-by: Ira Weiny <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agofirewire: ohci: disable MSI on Ricoh controllers
Stefan Richter [Sun, 29 Jan 2012 11:41:15 +0000 (12:41 +0100)]
firewire: ohci: disable MSI on Ricoh controllers

commit 320cfa6ce0b3dc794fedfa4bae54c0f65077234d upstream.

The PCIe device

    FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller
    [1180:e832] (prog-if 10 [OHCI])

is unable to access attached FireWire devices when MSI is enabled but
works if MSI is disabled.

Hence add the "disable MSI" quirks flag for this device, or in fact for
safety and simplicity for all current (R5U230, R5U231, R5U240) and
future Ricoh PCIe 1394 controllers.

Reported-by: Stefan Thomas <>
Signed-off-by: Stefan Richter <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agofirewire: ohci: add reset packet quirk for SB Audigy
Clemens Ladisch [Thu, 26 Jan 2012 21:05:58 +0000 (22:05 +0100)]
firewire: ohci: add reset packet quirk for SB Audigy

commit d1bb399ad03c11e792f6dea198d3b1e23061f094 upstream.

The Audigy's SB1394 controller is actually from Texas Instruments
and has the same bus reset packet generation bug, so it needs the
same quirk entry.

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Stefan Richter <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoproc: make sure mem_open() doesn't pin the target's memory
Oleg Nesterov [Tue, 31 Jan 2012 16:15:11 +0000 (17:15 +0100)]
proc: make sure mem_open() doesn't pin the target's memory

commit 6d08f2c7139790c268820a2e590795cb8333181a upstream.

Once /proc/pid/mem is opened, the memory can't be released until
mem_release() even if its owner exits.

Change mem_open() to do atomic_inc(mm_count) + mmput(), this only
pins mm_struct. Change mem_rw() to do atomic_inc_not_zero(mm_count)
before access_remote_vm(), this verifies that this mm is still alive.

I am not sure what should mem_rw() return if atomic_inc_not_zero()
fails. With this patch it returns zero to match the "mm == NULL" case,
may be it should return -EINVAL like it did before e268337d.

Perhaps it makes sense to add the additional fatal_signal_pending()
check into the main loop, to ensure we do not hold this memory if
the target task was oom-killed.

Signed-off-by: Oleg Nesterov <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoproc: unify mem_read() and mem_write()
Oleg Nesterov [Tue, 31 Jan 2012 16:14:54 +0000 (17:14 +0100)]
proc: unify mem_read() and mem_write()

commit 572d34b946bae070debd42db1143034d9687e13f upstream.

No functional changes, cleanup and preparation.

mem_read() and mem_write() are very similar. Move this code into the
new common helper, mem_rw(), which takes the additional "int write"

Signed-off-by: Oleg Nesterov <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoproc: mem_release() should check mm != NULL
Oleg Nesterov [Tue, 31 Jan 2012 16:14:38 +0000 (17:14 +0100)]
proc: mem_release() should check mm != NULL

commit 71879d3cb3dd8f2dfdefb252775c1b3ea04a3dd4 upstream.

mem_release() can hit mm == NULL, add the necessary check.

Signed-off-by: Oleg Nesterov <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>