Bjørn Mork [Mon, 2 Jul 2012 08:33:14 +0000 (10:33 +0200)]
USB: cdc-wdm: fix lockup on error in wdm_read
commit
b086b6b10d9f182cd8d2f0dcfd7fd11edba93fc9 upstream.
Clear the WDM_READ flag on empty reads to avoid running
forever in an infinite tight loop, causing lockups:
Jul 1 21:58:11 nemi kernel: [ 3658.898647] qmi_wwan 2-1:1.2: Unexpected error -71
Jul 1 21:58:36 nemi kernel: [ 3684.072021] BUG: soft lockup - CPU#0 stuck for 23s! [qmi.pl:12235]
Jul 1 21:58:36 nemi kernel: [ 3684.072212] CPU 0
Jul 1 21:58:36 nemi kernel: [ 3684.072355]
Jul 1 21:58:36 nemi kernel: [ 3684.072367] Pid: 12235, comm: qmi.pl Tainted: P O 3.5.0-rc2+ #13 LENOVO 2776LEG/2776LEG
Jul 1 21:58:36 nemi kernel: [ 3684.072383] RIP: 0010:[<
ffffffffa0635008>] [<
ffffffffa0635008>] spin_unlock_irq+0x8/0xc [cdc_wdm]
Jul 1 21:58:36 nemi kernel: [ 3684.072388] RSP: 0018:
ffff88022dca1e70 EFLAGS:
00000282
Jul 1 21:58:36 nemi kernel: [ 3684.072393] RAX:
ffff88022fc3f650 RBX:
ffffffff811c56f7 RCX:
00000001000ce8c1
Jul 1 21:58:36 nemi kernel: [ 3684.072398] RDX:
0000000000000010 RSI:
000000000267d810 RDI:
ffff88022fc3f650
Jul 1 21:58:36 nemi kernel: [ 3684.072403] RBP:
ffff88022dca1eb0 R08:
ffffffffa063578e R09:
0000000000000000
Jul 1 21:58:36 nemi kernel: [ 3684.072407] R10:
0000000000000008 R11:
0000000000000246 R12:
0000000000000002
Jul 1 21:58:36 nemi kernel: [ 3684.072412] R13:
0000000000000246 R14:
ffffffff00000002 R15:
ffff8802281d8c88
Jul 1 21:58:36 nemi kernel: [ 3684.072418] FS:
00007f666a260700(0000) GS:
ffff88023bc00000(0000) knlGS:
0000000000000000
Jul 1 21:58:36 nemi kernel: [ 3684.072423] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
Jul 1 21:58:36 nemi kernel: [ 3684.072428] CR2:
000000000270d9d8 CR3:
000000022e865000 CR4:
00000000000007f0
Jul 1 21:58:36 nemi kernel: [ 3684.072433] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
Jul 1 21:58:36 nemi kernel: [ 3684.072438] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Jul 1 21:58:36 nemi kernel: [ 3684.072444] Process qmi.pl (pid: 12235, threadinfo
ffff88022dca0000, task
ffff88022ff76380)
Jul 1 21:58:36 nemi kernel: [ 3684.072448] Stack:
Jul 1 21:58:36 nemi kernel: [ 3684.072458]
ffffffffa063592e 0000000100020000 ffff88022fc3f650 ffff88022fc3f6a8
Jul 1 21:58:36 nemi kernel: [ 3684.072466]
0000000000000200 0000000100000000 000000000267d810 0000000000000000
Jul 1 21:58:36 nemi kernel: [ 3684.072475]
0000000000000000 ffff880212cfb6d0 0000000000000200 ffff880212cfb6c0
Jul 1 21:58:36 nemi kernel: [ 3684.072479] Call Trace:
Jul 1 21:58:36 nemi kernel: [ 3684.072489] [<
ffffffffa063592e>] ? wdm_read+0x1a0/0x263 [cdc_wdm]
Jul 1 21:58:36 nemi kernel: [ 3684.072500] [<
ffffffff8110adb7>] ? vfs_read+0xa1/0xfb
Jul 1 21:58:36 nemi kernel: [ 3684.072509] [<
ffffffff81040589>] ? alarm_setitimer+0x35/0x64
Jul 1 21:58:36 nemi kernel: [ 3684.072517] [<
ffffffff8110aec7>] ? sys_read+0x45/0x6e
Jul 1 21:58:36 nemi kernel: [ 3684.072525] [<
ffffffff813725f9>] ? system_call_fastpath+0x16/0x1b
Jul 1 21:58:36 nemi kernel: [ 3684.072557] Code: <66> 66 90 c3 83 ff ed 89 f8 74 16 7f 06 83 ff a1 75 0a c3 83 ff f4
The WDM_READ flag is normally cleared by wdm_int_callback
before resubmitting the read urb, and set by wdm_in_callback
when this urb returns with data or an error. But a crashing
device may cause both a read error and cancelling all urbs.
Make sure that the flag is cleared by wdm_read if the buffer
is empty.
We don't clear the flag on errors, as there may be pending
data in the buffer which should be processed. The flag will
instead be cleared on the next wdm_read call.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Tue, 12 Jun 2012 18:17:01 +0000 (11:17 -0700)]
eCryptfs: Properly check for O_RDONLY flag before doing privileged open
commit
9fe79d7600497ed8a95c3981cbe5b73ab98222f0 upstream.
If the first attempt at opening the lower file read/write fails,
eCryptfs will retry using a privileged kthread. However, the privileged
retry should not happen if the lower file's inode is read-only because a
read/write open will still be unsuccessful.
The check for determining if the open should be retried was intended to
be based on the access mode of the lower file's open flags being
O_RDONLY, but the check was incorrectly performed. This would cause the
open to be retried by the privileged kthread, resulting in a second
failed open of the lower file. This patch corrects the check to
determine if the open request should be handled by the privileged
kthread.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Mon, 11 Jun 2012 17:21:34 +0000 (10:21 -0700)]
eCryptfs: Fix lockdep warning in miscdev operations
commit
60d65f1f07a7d81d3eb3b91fc13fca80f2fdbb12 upstream.
Don't grab the daemon mutex while holding the message context mutex.
Addresses this lockdep warning:
ecryptfsd/2141 is trying to acquire lock:
(&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [<
ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
but task is already holding lock:
(&(*daemon)->mux){+.+...}, at: [<
ffffffffa029c2ec>] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(*daemon)->mux){+.+...}:
[<
ffffffff810a3b8d>] lock_acquire+0x9d/0x220
[<
ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
[<
ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
[<
ffffffffa029c5d7>] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs]
[<
ffffffffa029b744>] ecryptfs_send_message+0x134/0x1e0 [ecryptfs]
[<
ffffffffa029a24e>] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs]
[<
ffffffffa02960f8>] ecryptfs_write_metadata+0x108/0x250 [ecryptfs]
[<
ffffffffa0290f80>] ecryptfs_create+0x130/0x250 [ecryptfs]
[<
ffffffff811963a4>] vfs_create+0xb4/0x120
[<
ffffffff81197865>] do_last+0x8c5/0xa10
[<
ffffffff811998f9>] path_openat+0xd9/0x460
[<
ffffffff81199da2>] do_filp_open+0x42/0xa0
[<
ffffffff81187998>] do_sys_open+0xf8/0x1d0
[<
ffffffff81187a91>] sys_open+0x21/0x30
[<
ffffffff81527d69>] system_call_fastpath+0x16/0x1b
-> #0 (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}:
[<
ffffffff810a3418>] __lock_acquire+0x1bf8/0x1c50
[<
ffffffff810a3b8d>] lock_acquire+0x9d/0x220
[<
ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
[<
ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
[<
ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
[<
ffffffff811887d3>] vfs_read+0xb3/0x180
[<
ffffffff811888ed>] sys_read+0x4d/0x90
[<
ffffffff81527d69>] system_call_fastpath+0x16/0x1b
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Mon, 11 Jun 2012 16:24:11 +0000 (09:24 -0700)]
eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files
commit
8dc6780587c99286c0d3de747a2946a76989414a upstream.
File operations on /dev/ecryptfs would BUG() when the operations were
performed by processes other than the process that originally opened the
file. This could happen with open files inherited after fork() or file
descriptors passed through IPC mechanisms. Rather than calling BUG(), an
error code can be safely returned in most situations.
In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
release even if the last file reference is being held by a process that
didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
be successful, so a pointer to the daemon is stored in the file's
private_data. The private_data pointer is initialized when the miscdev
file is opened and only used when the file is released.
https://launchpad.net/bugs/994247
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rustad [Tue, 26 Jun 2012 22:57:30 +0000 (15:57 -0700)]
tcm_fc: Resolve suspicious RCU usage warnings
commit
863555be0c81558b1af277addcf68acb8f778860 upstream.
Use rcu_dereference_protected to tell rcu that the ft_lport_lock
is held during ft_lport_create. This resolved "suspicious RCU usage"
warnings when debugging options are turned on.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sat, 9 Jun 2012 16:08:25 +0000 (19:08 +0300)]
mtd: cafe_nand: fix an & vs | mistake
commit
48f8b641297df49021093763a3271119a84990a2 upstream.
The intent here was clearly to set result to true if the 0x40000000 flag
was set. But instead there was a | vs & typo and we always set result
to true.
Artem: check the spec at
wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
and this fix looks correct.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Sat, 7 Jul 2012 17:17:00 +0000 (10:17 -0700)]
vfs: make O_PATH file descriptors usable for 'fchdir()'
commit
332a2e1244bd08b9e3ecd378028513396a004a24 upstream.
We already use them for openat() and friends, but fchdir() also wants to
be able to use O_PATH file descriptors. This should make it comparable
to the O_SEARCH of Solaris. In particular, O_PATH allows you to access
(not-quite-open) a directory you don't have read persmission to, only
execute permission.
Noticed during development of multithread support for ksh93.
Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stone Piao [Thu, 21 Jun 2012 03:21:10 +0000 (20:21 -0700)]
mwifiex: fix 11n rx packet drop issue
commit
925839243dc9aa4ef25305f5afd10ed18258a4ac upstream.
Currently we check the sequence number of last packet received
against start_win. If a sequence hole is detected, start_win is
updated to next sequence number.
Since the rx sequence number is initialized to 0, a corner case
exists when BA setup happens immediately after association. As
0 is a valid sequence number, start_win gets increased to 1
incorrectly. This causes the first packet with sequence number 0
being dropped.
Initialize rx sequence number as 0xffff and skip adjusting
start_win if the sequence number remains 0xffff. The sequence
number will be updated once the first packet is received.
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Wed, 27 Jun 2012 13:38:56 +0000 (15:38 +0200)]
mac80211: correct behaviour on unrecognised action frames
commit
4b5ebccc40843104d980f0714bc86bfcd5568941 upstream.
When receiving an "individually addressed" action frame, the
receiver is required to return it to the sender. mac80211
gets this wrong as it also returns group addressed (mcast)
frames to the sender. Fix this and update the reference to
the new 802.11 standards version since things were shuffled
around significantly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Fri, 8 Jun 2012 15:16:04 +0000 (16:16 +0100)]
oprofile: perf: use NR_CPUS instead or nr_cpumask_bits for static array
commit
e734568b675c985db2026848fefaac01c22977a5 upstream.
The OProfile perf backend uses a static array to keep track of the
perf events on the system. When compiling with CONFIG_CPUMASK_OFFSTACK=y
&& SMP, nr_cpumask_bits is not a compile-time constant and the build
will fail with:
oprofile_perf.c:28: error: variably modified 'perf_events' at file scope
This patch uses NR_CPUs instead of nr_cpumask_bits for the array
initialisation. If this causes space problems in the future, we can
always move to dynamic allocation for the events array.
Cc: Matt Fleming <matt@console-pimps.org>
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 15 Jun 2012 00:20:44 +0000 (00:20 +0000)]
can: c_can: precedence error in c_can_chip_config()
commit
d9cb9bd63eb27ac19f26a8547128c053f43a5da8 upstream.
(CAN_CTRLMODE_LISTENONLY & CAN_CTRLMODE_LOOPBACK) is (0x02 & 0x01) which
is zero so the condition is never true. The intent here was to test
that both flags were set.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eliad Peller [Tue, 12 Jun 2012 09:53:13 +0000 (12:53 +0300)]
cfg80211: fix potential deadlock in regulatory
commit
fe20b39ec32e975f1054c0b7866c873a954adf05 upstream.
reg_timeout_work() calls restore_regulatory_settings() which
takes cfg80211_mutex.
reg_set_request_processed() already holds cfg80211_mutex
before calling cancel_delayed_work_sync(reg_timeout),
so it might deadlock.
Call the async cancel_delayed_work instead, in order
to avoid the potential deadlock.
This is the relevant lockdep warning:
cfg80211: Calling CRDA for country: XX
======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc5-wl+ #26 Not tainted
-------------------------------------------------------
kworker/0:2/1391 is trying to acquire lock:
(cfg80211_mutex){+.+.+.}, at: [<
bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
but task is already holding lock:
((reg_timeout).work){+.+...}, at: [<
c0059e94>] process_one_work+0x1f0/0x480
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((reg_timeout).work){+.+...}:
[<
c008fd44>] validate_chain+0xb94/0x10f0
[<
c0090b68>] __lock_acquire+0x8c8/0x9b0
[<
c0090d40>] lock_acquire+0xf0/0x114
[<
c005b600>] wait_on_work+0x4c/0x154
[<
c005c000>] __cancel_work_timer+0xd4/0x11c
[<
c005c064>] cancel_delayed_work_sync+0x1c/0x20
[<
bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
[<
bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
[<
bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
[<
c03c7738>] genl_rcv_msg+0x1a8/0x1e8
[<
c03c6a00>] netlink_rcv_skb+0x5c/0xc0
[<
c03c7584>] genl_rcv+0x28/0x34
[<
c03c6720>] netlink_unicast+0x15c/0x228
[<
c03c6c7c>] netlink_sendmsg+0x218/0x298
[<
c03933c8>] sock_sendmsg+0xa4/0xc0
[<
c039406c>] __sys_sendmsg+0x1e4/0x268
[<
c0394228>] sys_sendmsg+0x4c/0x70
[<
c0013840>] ret_fast_syscall+0x0/0x3c
-> #1 (reg_mutex){+.+.+.}:
[<
c008fd44>] validate_chain+0xb94/0x10f0
[<
c0090b68>] __lock_acquire+0x8c8/0x9b0
[<
c0090d40>] lock_acquire+0xf0/0x114
[<
c04734dc>] mutex_lock_nested+0x48/0x320
[<
bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
[<
c0059f44>] process_one_work+0x2a0/0x480
[<
c005a4b4>] worker_thread+0x1bc/0x2bc
[<
c0061148>] kthread+0x98/0xa4
[<
c0014af4>] kernel_thread_exit+0x0/0x8
-> #0 (cfg80211_mutex){+.+.+.}:
[<
c008ed58>] print_circular_bug+0x68/0x2cc
[<
c008fb28>] validate_chain+0x978/0x10f0
[<
c0090b68>] __lock_acquire+0x8c8/0x9b0
[<
c0090d40>] lock_acquire+0xf0/0x114
[<
c04734dc>] mutex_lock_nested+0x48/0x320
[<
bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
[<
bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
[<
c0059f44>] process_one_work+0x2a0/0x480
[<
c005a4b4>] worker_thread+0x1bc/0x2bc
[<
c0061148>] kthread+0x98/0xa4
[<
c0014af4>] kernel_thread_exit+0x0/0x8
other info that might help us debug this:
Chain exists of:
cfg80211_mutex --> reg_mutex --> (reg_timeout).work
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((reg_timeout).work);
lock(reg_mutex);
lock((reg_timeout).work);
lock(cfg80211_mutex);
*** DEADLOCK ***
2 locks held by kworker/0:2/1391:
#0: (events){.+.+.+}, at: [<
c0059e94>] process_one_work+0x1f0/0x480
#1: ((reg_timeout).work){+.+...}, at: [<
c0059e94>] process_one_work+0x1f0/0x480
stack backtrace:
[<
c001b928>] (unwind_backtrace+0x0/0x12c) from [<
c0471d3c>] (dump_stack+0x20/0x24)
[<
c0471d3c>] (dump_stack+0x20/0x24) from [<
c008ef70>] (print_circular_bug+0x280/0x2cc)
[<
c008ef70>] (print_circular_bug+0x280/0x2cc) from [<
c008fb28>] (validate_chain+0x978/0x10f0)
[<
c008fb28>] (validate_chain+0x978/0x10f0) from [<
c0090b68>] (__lock_acquire+0x8c8/0x9b0)
[<
c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<
c0090d40>] (lock_acquire+0xf0/0x114)
[<
c0090d40>] (lock_acquire+0xf0/0x114) from [<
c04734dc>] (mutex_lock_nested+0x48/0x320)
[<
c04734dc>] (mutex_lock_nested+0x48/0x320) from [<
bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
[<
bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<
bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
[<
bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<
c0059f44>] (process_one_work+0x2a0/0x480)
[<
c0059f44>] (process_one_work+0x2a0/0x480) from [<
c005a4b4>] (worker_thread+0x1bc/0x2bc)
[<
c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<
c0061148>] (kthread+0x98/0xa4)
[<
c0061148>] (kthread+0x98/0xa4) from [<
c0014af4>] (kernel_thread_exit+0x0/0x8)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211: (
2402000 KHz -
2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (
2457000 KHz -
2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (
2474000 KHz -
2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (
5170000 KHz -
5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (
5735000 KHz -
5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Craig Shelley [Tue, 26 Jun 2012 22:20:04 +0000 (23:20 +0100)]
USB: CP210x Add 10 Device IDs
commit
3fcc8f96829776cf181918461923d1e3bbb831a2 upstream.
This patch adds 10 device IDs for CP210x based devices from the following manufacturers:
Timewave
Clipsal
Festo
Link Instruments
Signed-off-by: Craig Shelley <craig@microtron.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Forest Bond [Fri, 22 Jun 2012 14:30:38 +0000 (10:30 -0400)]
USB: option: Add USB ID for Novatel Ovation MC551
commit
065b07e7a14676f4138ce4619d229c0be5a74230 upstream.
This device is also known as the Verizon USB551L.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Shmygov [Wed, 20 Jun 2012 11:51:40 +0000 (15:51 +0400)]
USB: option: add id for Cellient MEN-200
commit
1e2c4e59d2b8797973471b4a287a43eac12a0f40 upstream.
Add vendor and product ID to option.c driver
for Cellient MEN-200 EVDO Rev.B 450MHz data module.
http://cellient.com
Signed-off-by: Dmitry Shmygov <shmygov@rambler.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 21 Jun 2012 10:36:50 +0000 (11:36 +0100)]
stable: Allow merging of backports for serious user-visible performance issues
commit
eb3979f64d25120d60b9e761a4c58f70b1a02f86 upstream.
Distribution kernel maintainers routinely backport fixes for users that
were deemed important but not "something critical" as defined by the
rules. To users of these kernels they are very serious and failing to fix
them reduces the value of -stable.
The problem is that the patches fixing these issues are often subtle and
prone to regressions in other ways and need greater care and attention.
To combat this, these "serious" backports should have a higher barrier
to entry.
This patch relaxes the rules to allow a distribution maintainer to merge
to -stable a backported patch or small series that fixes a "serious"
user-visible performance issue. They should include additional information on
the user-visible bug affected and a link to the bugzilla entry if available.
The same rules about the patch being already in mainline still apply.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Vasilyev [Tue, 5 Jun 2012 04:02:05 +0000 (00:02 -0400)]
ACPI sysfs.c strlen fix
commit
9f132652d94c96476b0b0a8caf0c10e96ab10fa8 upstream.
Current code is ignoring the last character of "enable" and "disable"
in comparisons.
https://bugzilla.kernel.org/show_bug.cgi?id=33732
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhang Rui [Mon, 20 Feb 2012 06:20:06 +0000 (14:20 +0800)]
ACPI, x86: fix Dell M6600 ACPI reboot regression via DMI
commit
76eb9a30db4bc8fd172f9155247264b5f2686d7b upstream.
Dell Precision M6600 is known to require PCI reboot, so add it to
the reboot blacklist in pci_reboot_dmi_table[].
https://bugzilla.kernel.org/show_bug.cgi?id=42749
cc: x86@kernel.org
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Feng Tang [Mon, 4 Jun 2012 07:00:06 +0000 (15:00 +0800)]
ACPI: Add a quirk for "AMILO PRO V2030" to ignore the timer overriding
commit
f6b54f083cc66cf9b11d2120d8df3c2ad4e0836d upstream.
This is the 2nd part of fix for kernel bugzilla 40002:
"IRQ 0 assigned to VGA"
https://bugzilla.kernel.org/show_bug.cgi?id=40002
The root cause is the buggy FW, whose ACPI tables assign the GSI 16
to 2 irqs 0 and 16(VGA), and the VGA is the right owner of GSI 16.
So add a quirk to ignore the irq0 overriding GSI 16 for the
FUJITSU SIEMENS AMILO PRO V2030 platform will solve this issue.
Reported-and-tested-by: Szymon Kowalczyk <fazerxlo@o2.pl>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stuart Hayes [Wed, 13 Jun 2012 21:10:45 +0000 (16:10 -0500)]
acpi_pad: fix power_saving thread deadlock
commit
5f1601261050251a5ca293378b492a69d590dacb upstream.
The acpi_pad driver can get stuck in destroy_power_saving_task()
waiting for kthread_stop() to stop a power_saving thread. The problem
is that the isolated_cpus_lock mutex is owned when
destroy_power_saving_task() calls kthread_stop(), which waits for a
power_saving thread to end, and the power_saving thread tries to
acquire the isolated_cpus_lock when it calls round_robin_cpu(). This
patch fixes the issue by making round_robin_cpu() use its own mutex.
https://bugzilla.kernel.org/show_bug.cgi?id=42981
Signed-off-by: Stuart Hayes <Stuart_Hayes@Dell.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 21 Jun 2012 13:30:41 +0000 (15:30 +0200)]
drm/i915: Fix eDP blank screen after S3 resume on HP desktops
commit
6db65cbb941f9d433659bdad02b307f6d94465df upstream.
This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.
It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these
SNB machines.
Tested with 3.5-rc3 kernel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Tue, 26 Jun 2012 02:12:30 +0000 (12:12 +1000)]
drm/nouveau/fbcon: using nv_two_heads is not a good idea
commit
9bd0c15fcfb42f6245447c53347d65ad9e72080b upstream.
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..
This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Tue, 19 Jun 2012 09:33:06 +0000 (11:33 +0200)]
drm/edid: don't return stack garbage from supports_rb
commit
b196a4980ff7bb54db478e2a408dc8b12be15304 upstream.
We need to initialize this to false, because the is_rb callback only
ever sets it to true.
Noticed while reading through the code.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Mason [Mon, 2 Jul 2012 19:29:53 +0000 (15:29 -0400)]
Btrfs: run delayed directory updates during log replay
commit
b6305567e7d31b0bec1b8cb9ec0cadd7f7086f5f upstream.
While we are resolving directory modifications in the
tree log, we are triggering delayed metadata updates to
the filesystem btrees.
This commit forces the delayed updates to run so the
replay code can find any modifications done. It stops
us from crashing because the directory deleltion replay
expects items to be removed immediately from the tree.
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hebbar, Gururaja [Tue, 26 Jun 2012 13:55:11 +0000 (19:25 +0530)]
ASoC: tlv320aic3x: Fix codec pll configure bug
commit
c9fe573a6584034670c1a55ee8162d623519cbbf upstream.
In sound/soc/codecs/tlv320aic3x.c
data = snd_soc_read(codec, AIC3X_PLL_PROGA_REG);
snd_soc_write(codec, AIC3X_PLL_PROGA_REG,
data | (pll_p << PLLP_SHIFT));
In the above code, pll-p value is OR'ed with previous value without
clearing it. Bug is not seen if pll-p value doesn't change across
Sampling frequency.
However on some platforms (like AM335x EVM-SK), pll-p may have different
values across different sampling frequencies. In such case, above code
configures the pll with a wrong value.
Because of this bug, when a audio stream is played with pll value
different from previous stream, audio is heard as differently(like its
stretched).
Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Panayiotis Karabassis [Tue, 26 Jun 2012 20:37:17 +0000 (23:37 +0300)]
ath9k: enable serialize_regmode for non-PCIE AR9287
commit
7508b657967cf664b5aa0f6367d05016e7e3bc2a upstream.
https://bugzilla.kernel.org/show_bug.cgi?id=42903
Based on the work of <fynivx@gmail.com>
Signed-off-by: Panayiotis Karabassis <panayk@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mohammed Shafi Shajakhan [Mon, 18 Jun 2012 07:43:30 +0000 (13:13 +0530)]
ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
commit
f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream.
"ath9k: Fix softlockup in AR9485" with commit id
64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported
issue, yet its better to avoid the possible infinite loop
in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
by ath9k maintainers.
http://www.spinics.net/lists/linux-wireless/msg92126.html.
Based on my testing PLL's locking measurement is done in
~200us (2 iterations).
Cc: Rolf Offermanns <rolf.offermanns@gmx.net>
Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mohammed Shafi Shajakhan [Wed, 13 Jun 2012 15:58:09 +0000 (21:28 +0530)]
ath9k: Fix softlockup in AR9485
commit
bcb7ad7bcbef030e6ba71ede1f9866368aca7c99 upstream.
steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up
Call Trace:
[<
ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
[<
ffffffff812cd1e8>] __const_udelay+0x28/0x30
[<
ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
[<
ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
[<
ffffffff810744fe>] process_one_work+0x11e/0x470
[<
ffffffff8107530f>] worker_thread+0x15f/0x360
[<
ffffffff810751b0>] ? manage_workers+0x230/0x230
[<
ffffffff81079af3>] kthread+0x93/0xa0
[<
ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
[<
ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
[<
ffffffff815fd3a0>] ? gs_change+0x13/0x13
ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.
fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
Reported-by: Rolf Offermanns <rolf.offermanns@gmx.net>
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 27 Jun 2012 19:23:07 +0000 (21:23 +0200)]
udf: Fortify loading of sparing table
commit
1df2ae31c724e57be9d7ac00d78db8a5dabdd050 upstream.
Add sanity checks when loading sparing table from disk to avoid accessing
unallocated memory or writing to it.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 27 Jun 2012 18:20:22 +0000 (20:20 +0200)]
udf: Avoid run away loop when partition table length is corrupted
commit
adee11b2085bee90bd8f4f52123ffb07882d6256 upstream.
Check provided length of partition table so that (possibly maliciously)
corrupted partition table cannot cause accessing data beyond current buffer.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 27 Jun 2012 18:08:44 +0000 (20:08 +0200)]
udf: Use 'ret' instead of abusing 'i' in udf_load_logicalvol()
commit
cb14d340ef1737c24125dd663eff77734a482d47 upstream.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ryusuke Konishi [Wed, 20 Jun 2012 19:52:57 +0000 (12:52 -0700)]
nilfs2: ensure proper cache clearing for gc-inodes
commit
fbb24a3a915f105016f1c828476be11aceac8504 upstream.
A gc-inode is a pseudo inode used to buffer the blocks to be moved by
garbage collection.
Block caches of gc-inodes must be cleared every time a garbage collection
function (nilfs_clean_segments) completes. Otherwise, stale blocks
buffered in the caches may be wrongly reused in successive calls of the GC
function.
For user files, this is not a problem because their gc-inodes are
distinguished by a checkpoint number as well as an inode number. They
never buffer different blocks if either an inode number, a checkpoint
number, or a block offset differs.
However, gc-inodes of sufile, cpfile and DAT file can store different data
for the same block offset. Thus, the nilfs_clean_segments function can
move incorrect block for these meta-data files if an old block is cached.
I found this is really causing meta-data corruption in nilfs.
This fixes the issue by ensuring cache clear of gc-inodes and resolves
reported GC problems including checkpoint file corruption, b-tree
corruption, and the following warning during GC.
nilfs_palloc_freev: entry number 307234 already freed.
...
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Henrik Rydberg [Thu, 7 Jun 2012 08:54:29 +0000 (04:54 -0400)]
hwmon: (applesmc) Limit key length in warning messages
commit
ac852edb47b15900886ba2564eeeb13b3b526e3e upstream.
Key lookups may call read_smc() with a fixed-length key string,
and if the lookup fails, trailing stack content may appear in the
kernel log. Fixed with this patch.
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 12 Jun 2012 19:30:21 +0000 (19:30 +0000)]
netpoll: fix netpoll_send_udp() bugs
[ Upstream commit
954fba0274058d27c7c07b5ea07c41b3b7477894 ]
Bogdan Hamciuc diagnosed and fixed following bug in netpoll_send_udp() :
"skb->len += len;" instead of "skb_put(skb, len);"
Meaning that _if_ a network driver needs to call skb_realloc_headroom(),
only packet headers would be copied, leaving garbage in the payload.
However the skb_realloc_headroom() must be avoided as much as possible
since it requires memory and netpoll tries hard to work even if memory
is exhausted (using a pool of preallocated skbs)
It appears netpoll_send_udp() reserved 16 bytes for the ethernet header,
which happens to work for typicall drivers but not all.
Right thing is to use LL_RESERVED_SPACE(dev)
(And also add dev->needed_tailroom of tailroom)
This patch combines both fixes.
Many thanks to Bogdan for raising this issue.
Reported-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 7 Jun 2012 22:59:59 +0000 (22:59 +0000)]
be2net: fix a race in be_xmit()
[ Upstream commit
cd8f76c0a0c6fce0b2cf23c9bd0123f91453f46d ]
As soon as hardware is notified of a transmit, we no longer can assume
skb can be dereferenced, as TX completion might have freed the packet.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
stephen hemminger [Wed, 6 Jun 2012 10:01:30 +0000 (10:01 +0000)]
sky2: fix checksum bit management on some chips
[ Upstream commit
5ff0feac88ced864f44adb145142269196fa79d9 ]
The newer flavors of Yukon II use a different method for receive
checksum offload. This is indicated in the driver by the SKY2_HW_NEW_LE
flag. On these newer chips, the BMU_ENA_RX_CHKSUM should not be set.
The driver would get incorrectly toggle the bit, enabling the old
checksum logic on these chips and cause a BUG_ON() assertion. If
receive checksum was toggled via ethtool.
Reported-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Graf [Mon, 18 Jun 2012 12:08:33 +0000 (12:08 +0000)]
ipv6: Move ipv6 proc file registration to end of init order
[ Upstream commit
d189634ecab947c10f6f832258b103d0bbfe73cc ]
/proc/net/ipv6_route reflects the contents of fib_table_hash. The proc
handler is installed in ip6_route_net_init() whereas fib_table_hash is
allocated in fib6_net_init() _after_ the proc handler has been installed.
This opens up a short time frame to access fib_table_hash with its pants
down.
Move the registration of the proc files to a later point in the init
order to avoid the race.
Tested :-)
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 12 Jun 2012 06:03:51 +0000 (06:03 +0000)]
bonding: Fix corrupted queue_mapping
[ Upstream commit
5ee31c6898ea5537fcea160999d60dc63bc0c305 ]
In the transmit path of the bonding driver, skb->cb is used to
stash the skb->queue_mapping so that the bonding device can set its
own queue mapping. This value becomes corrupted since the skb->cb is
also used in __dev_xmit_skb.
When transmitting through bonding driver, bond_select_queue is
called from dev_queue_xmit. In bond_select_queue the original
skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
and skb->queue_mapping is overwritten with the bond driver queue.
Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
the packet length into skb->cb, thereby overwriting the stashed
queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit),
the queue mapping for the skb is set to the stashed value which is now
the skb length and hence is an invalid queue for the slave device.
If we want to save skb->queue_mapping into skb->cb[], best place is to
add a field in struct qdisc_skb_cb, to make sure it wont conflict with
other layers (eg : Qdiscc, Infiniband...)
This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8
bytes :
netem qdisc for example assumes it can store an u64 in it, without
misalignment penalty.
Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[].
The largest user is CHOKe and it fills it.
Based on a previous patch from Tom Herbert.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Tom Herbert <therbert@google.com>
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Roland Dreier <roland@kernel.org>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
stephen hemminger [Tue, 26 Jun 2012 05:48:45 +0000 (05:48 +0000)]
bridge: Assign rtnl_link_ops to bridge devices created via ioctl (v2)
[ Upstream commit
149ddd83a92b02c658d6c61f3276eb6500d585e8 ]
This ensures that bridges created with brctl(8) or ioctl(2) directly
also carry IFLA_LINKINFO when dumped over netlink. This also allows
to create a bridge with ioctl(2) and delete it with RTM_DELLINK.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Mirosław [Sun, 22 Jan 2012 00:20:40 +0000 (00:20 +0000)]
ethtool: allow ETHTOOL_GSSET_INFO for users
[ Upstream commit
f80400a26a2e8bff541de12834a1134358bb6642 ]
Allow ETHTOOL_GSSET_INFO ethtool ioctl() for unprivileged users.
ETHTOOL_GSTRINGS is already allowed, but is unusable without this one.
Signed-off-by: Micha©© Miros©©aw <mirq-linux@rere.qmqm.pl>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Sun, 10 Jun 2012 21:11:57 +0000 (21:11 +0000)]
dummy: fix rcu_sched self-detected stalls
[ Upstream commit
16b0dc29c1af9df341428f4c49ada4f626258082 ]
Trying to "modprobe dummy numdummies=30000" triggers :
INFO: rcu_sched self-detected stall on CPU { 8} (t=60000 jiffies)
After this splat, RTNL is locked and reboot is needed.
We must call cond_resched() to avoid this, even holding RTNL.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 7 Jun 2012 00:07:20 +0000 (00:07 +0000)]
net: l2tp_eth: fix kernel panic on rmmod l2tp_eth
[ Upstream commit
a06998b88b1651c5f71c0e35f528bf2057188ead ]
We must prevent module unloading if some devices are still attached to
l2tp_eth driver.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Moore [Fri, 1 Jun 2012 05:54:56 +0000 (05:54 +0000)]
cipso: handle CIPSO options correctly when NetLabel is disabled
[ Upstream commit
20e2a86485967c385d7c7befc1646e4d1d39362e ]
When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system
receives a CIPSO tagged packet it is dropped (cipso_v4_validate()
returns non-zero). In most cases this is the correct and desired
behavior, however, in the case where we are simply forwarding the
traffic, e.g. acting as a network bridge, this becomes a problem.
This patch fixes the forwarding problem by providing the basic CIPSO
validation code directly in ip_options_compile() without the need for
the NetLabel or CIPSO code. The new validation code can not perform
any of the CIPSO option label/value verification that
cipso_v4_validate() does, but it can verify the basic CIPSO option
format.
The behavior when NetLabel is enabled is unchanged.
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Wed, 30 May 2012 21:18:10 +0000 (21:18 +0000)]
net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
[ Upstream commit
cc9b17ad29ecaa20bfe426a8d4dbfb94b13ff1cc ]
We need to validate the number of pages consumed by data_len, otherwise frags
array could be overflowed by userspace. So this patch validate data_len and
return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Thu, 19 Jan 2012 15:20:58 +0000 (15:20 +0000)]
ARM: fix rcu stalls on SMP platforms
commit
7deabca0acfe02b8e18f59a4c95676012f49a304 upstream.
We can stall RCU processing on SMP platforms if a CPU sits in its idle
loop for a long time. This happens because we don't call irq_enter()
and irq_exit() around generic_smp_call_function_interrupt() and
friends. Add the necessary calls, and remove the one from within
ipi_timer(), so that they're all in a common place.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[add irq_enter()/irq_exit() in do_local_timer]
Signed-off-by: UCHINO Satoshi <satoshi.uchino@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Krufky [Fri, 25 May 2012 12:29:12 +0000 (09:29 -0300)]
media: smsusb: add autodetection support for USB ID 2040:f5a0
commit
3e1141e2ce5667301a74ca2ef396d9bd5e995f7f upstream.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Thu, 28 Jun 2012 19:28:57 +0000 (19:28 +0000)]
powerpc/xmon: Use cpumask iterator to avoid warning
commit
bc1d7702910c7c7e88eb60b58429dbfe293683ce upstream.
We have a bug report where the kernel hits a warning in the cpumask
code:
WARNING: at include/linux/cpumask.h:107
Which is:
WARN_ON_ONCE(cpu >= nr_cpumask_bits);
The backtrace is:
cpu_cmd
cmds
xmon_core
xmon
die
xmon is iterating through 0 to NR_CPUS. I'm not sure why we are still
open coding this but iterating above nr_cpu_ids is definitely a bug.
This patch iterates through all possible cpus, in case we issue a
system reset and CPUs in an offline state call in.
Perhaps the old code was trying to handle CPUs that were in the
partition but were never started (eg kexec into a kernel with an
nr_cpus= boot option). They are going to die way before we get into
xmon since we haven't set any kernel state up for them.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Henningsson [Mon, 25 Jun 2012 17:49:28 +0000 (19:49 +0200)]
ALSA: hda - Add Realtek ALC280 codec support
commit
befae82e2906cb7155020876a531b0b8c6c8d8c8 upstream.
This chip looks very similar to ALC269 and ALC27* variants. The bug reporter
has verified that sound was working after this patch had been applied.
BugLink: https://bugs.launchpad.net/bugs/1017017
Tested-by: Richard Crossley <richardcrossley@o2.co.uk>
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>
Greg Kroah-Hartman [Fri, 22 Jun 2012 18:34:31 +0000 (11:34 -0700)]
Linux 3.0.36
Daniel Mack [Tue, 12 Jun 2012 18:23:52 +0000 (20:23 +0200)]
USB: fix gathering of interface associations
commit
b3a3dd074f7053ef824ad077e5331b52220ceba1 upstream.
TEAC's UD-H01 (and probably other devices) have a gap in the interface
number allocation of their descriptors:
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 220
bNumInterfaces 3
[...]
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
[...]
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
[...]
Once a configuration is selected, usb_set_configuration() walks the
known interfaces of a given configuration and calls find_iad() on
each of them to set the interface association pointer the interface
is included in.
The problem here is that the loop variable is taken for the interface
number in the comparison logic that gathers the association. Which is
fine as long as the descriptors are sane.
In the case above, however, the logic gets out of sync and the
interface association fields of all interfaces beyond the interface
number gap are wrong.
Fix this by passing the interface's bInterfaceNumber to find_iad()
instead.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: bEN <ml_all@circa.be>
Reported-by: Ivan Perrone <ivanperrone@hotmail.com>
Tested-by: ivan perrone <ivanperrone@hotmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Wed, 30 May 2012 08:00:14 +0000 (10:00 +0200)]
USB: serial: Enforce USB driver and USB serial driver match
commit
954c3f8a5f1b7716be9eee978b3bc85bae92d7c8 upstream.
We need to make sure that the USB serial driver we find
matches the USB driver whose probe we are currently
executing. Otherwise we will end up with USB serial
devices bound to the correct serial driver but wrong
USB driver.
An example of such cross-probing, where the usbserial_generic
USB driver has found the sierra serial driver:
May 29 18:26:15 nemi kernel: [ 4442.559246] usbserial_generic 4-4:1.0: Sierra USB modem converter detected
May 29 18:26:20 nemi kernel: [ 4447.556747] usbserial_generic 4-4:1.2: Sierra USB modem converter detected
May 29 18:26:25 nemi kernel: [ 4452.557288] usbserial_generic 4-4:1.3: Sierra USB modem converter detected
sysfs view of the same problem:
bjorn@nemi:~$ ls -l /sys/bus/usb/drivers/sierra/
total 0
--w------- 1 root root 4096 May 29 18:23 bind
lrwxrwxrwx 1 root root 0 May 29 18:23 module -> ../../../../module/usbserial
--w------- 1 root root 4096 May 29 18:23 uevent
--w------- 1 root root 4096 May 29 18:23 unbind
bjorn@nemi:~$ ls -l /sys/bus/usb-serial/drivers/sierra/
total 0
--w------- 1 root root 4096 May 29 18:23 bind
lrwxrwxrwx 1 root root 0 May 29 18:23 module -> ../../../../module/sierra
-rw-r--r-- 1 root root 4096 May 29 18:23 new_id
lrwxrwxrwx 1 root root 0 May 29 18:32 ttyUSB0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0/ttyUSB0
lrwxrwxrwx 1 root root 0 May 29 18:32 ttyUSB1 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.2/ttyUSB1
lrwxrwxrwx 1 root root 0 May 29 18:32 ttyUSB2 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.3/ttyUSB2
--w------- 1 root root 4096 May 29 18:23 uevent
--w------- 1 root root 4096 May 29 18:23 unbind
bjorn@nemi:~$ ls -l /sys/bus/usb/drivers/usbserial_generic/
total 0
lrwxrwxrwx 1 root root 0 May 29 18:33 4-4:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0
lrwxrwxrwx 1 root root 0 May 29 18:33 4-4:1.2 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.2
lrwxrwxrwx 1 root root 0 May 29 18:33 4-4:1.3 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.3
--w------- 1 root root 4096 May 29 18:33 bind
lrwxrwxrwx 1 root root 0 May 29 18:33 module -> ../../../../module/usbserial
--w------- 1 root root 4096 May 29 18:22 uevent
--w------- 1 root root 4096 May 29 18:33 unbind
bjorn@nemi:~$ ls -l /sys/bus/usb-serial/drivers/generic/
total 0
--w------- 1 root root 4096 May 29 18:33 bind
lrwxrwxrwx 1 root root 0 May 29 18:33 module -> ../../../../module/usbserial
-rw-r--r-- 1 root root 4096 May 29 18:33 new_id
--w------- 1 root root 4096 May 29 18:22 uevent
--w------- 1 root root 4096 May 29 18:33 unbind
So we end up with a mismatch between the USB driver and the
USB serial driver. The reason for the above is simple: The
USB driver probe will succeed if *any* registered serial
driver matches, and will use that serial driver for all
serial driver functions.
This makes ref counting go wrong. We count the USB driver
as used, but not the USB serial driver. This may result
in Oops'es as demonstrated by Johan Hovold <jhovold@gmail.com>:
[11811.646396] drivers/usb/serial/usb-serial.c: get_free_serial 1
[11811.646443] drivers/usb/serial/usb-serial.c: get_free_serial - minor base = 0
[11811.646460] drivers/usb/serial/usb-serial.c: usb_serial_probe - registering ttyUSB0
[11811.646766] usb 6-1: pl2303 converter now attached to ttyUSB0
[11812.264197] USB Serial deregistering driver FTDI USB Serial Device
[11812.264865] usbcore: deregistering interface driver ftdi_sio
[11812.282180] USB Serial deregistering driver pl2303
[11812.283141] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[11812.283272] usbcore: deregistering interface driver pl2303
[11812.301056] USB Serial deregistering driver generic
[11812.301186] usbcore: deregistering interface driver usbserial_generic
[11812.301259] drivers/usb/serial/usb-serial.c: usb_serial_disconnect
[11812.301823] BUG: unable to handle kernel paging request at
f8e7438c
[11812.301845] IP: [<
f8e38445>] usb_serial_disconnect+0xb5/0x100 [usbserial]
[11812.301871] *pde =
357ef067 *pte =
00000000
[11812.301957] Oops: 0000 [#1] PREEMPT SMP
[11812.301983] Modules linked in: usbserial(-) [last unloaded: pl2303]
[11812.302008]
[11812.302019] Pid: 1323, comm: modprobe Tainted: G W 3.4.0-rc7+ #101 Dell Inc. Vostro 1520/0T816J
[11812.302115] EIP: 0060:[<
f8e38445>] EFLAGS:
00010246 CPU: 1
[11812.302130] EIP is at usb_serial_disconnect+0xb5/0x100 [usbserial]
[11812.302141] EAX:
f508a180 EBX:
f508a180 ECX:
00000000 EDX:
f8e74300
[11812.302151] ESI:
f5050800 EDI:
00000001 EBP:
f5141e78 ESP:
f5141e58
[11812.302160] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[11812.302170] CR0:
8005003b CR2:
f8e7438c CR3:
34848000 CR4:
000007d0
[11812.302180] DR0:
00000000 DR1:
00000000 DR2:
00000000 DR3:
00000000
[11812.302189] DR6:
ffff0ff0 DR7:
00000400
[11812.302199] Process modprobe (pid: 1323, ti=
f5140000 task=
f61e2bc0 task.ti=
f5140000)
[11812.302209] Stack:
[11812.302216]
f8e3be0f f8e3b29c f8e3ae00 00000000 f513641c f5136400 f513641c f507a540
[11812.302325]
f5141e98 c133d2c1 00000000 00000000 f509c400 f513641c f507a590 f5136450
[11812.302372]
f5141ea8 c12f0344 f513641c f507a590 f5141ebc c12f0c67 00000000 f507a590
[11812.302419] Call Trace:
[11812.302439] [<
c133d2c1>] usb_unbind_interface+0x51/0x190
[11812.302456] [<
c12f0344>] __device_release_driver+0x64/0xb0
[11812.302469] [<
c12f0c67>] driver_detach+0x97/0xa0
[11812.302483] [<
c12f001c>] bus_remove_driver+0x6c/0xe0
[11812.302500] [<
c145938d>] ? __mutex_unlock_slowpath+0xcd/0x140
[11812.302514] [<
c12f0ff9>] driver_unregister+0x49/0x80
[11812.302528] [<
c1457df6>] ? printk+0x1d/0x1f
[11812.302540] [<
c133c50d>] usb_deregister+0x5d/0xb0
[11812.302557] [<
f8e37c55>] ? usb_serial_deregister+0x45/0x50 [usbserial]
[11812.302575] [<
f8e37c8d>] usb_serial_deregister_drivers+0x2d/0x40 [usbserial]
[11812.302593] [<
f8e3a6e2>] usb_serial_generic_deregister+0x12/0x20 [usbserial]
[11812.302611] [<
f8e3acf0>] usb_serial_exit+0x8/0x32 [usbserial]
[11812.302716] [<
c1080b48>] sys_delete_module+0x158/0x260
[11812.302730] [<
c110594e>] ? mntput+0x1e/0x30
[11812.302746] [<
c145c3c3>] ? sysenter_exit+0xf/0x18
[11812.302746] [<
c107777c>] ? trace_hardirqs_on_caller+0xec/0x170
[11812.302746] [<
c145c390>] sysenter_do_call+0x12/0x36
[11812.302746] Code: 24 02 00 00 e8 dd f3 20 c8 f6 86 74 02 00 00 02 74 b4 8d 86 4c 02 00 00 47 e8 78 55 4b c8 0f b6 43 0e 39 f8 7f a9 8b 53 04 89 d8 <ff> 92 8c 00 00 00 89 d8 e8 0e ff ff ff 8b 45 f0 c7 44 24 04 2f
[11812.302746] EIP: [<
f8e38445>] usb_serial_disconnect+0xb5/0x100 [usbserial] SS:ESP 0068:
f5141e58
[11812.302746] CR2:
00000000f8e7438c
Fix by only evaluating serial drivers pointing back to the
USB driver we are currently probing. This still allows two
or more drivers to match the same device, running their
serial driver probes to sort out which one to use.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Tested-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Cassidy [Wed, 6 Jun 2012 07:08:48 +0000 (17:08 +1000)]
USB: serial: sierra: Add support for Sierra Wireless AirCard 320U modem
commit
19a3dd1575e954e8c004413bee3e12d3962f2525 upstream.
Add support for Sierra Wireless AirCard 320U modem
Signed-off-by: Tomas Cassidy <tomas.cassidy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Otto Meta [Wed, 6 Jun 2012 16:46:21 +0000 (18:46 +0200)]
usb: cdc-acm: fix devices not unthrottled on open
commit
6c4707f3f8c44ec18282e1c014c80e1c257042f9 upstream.
Currently CDC-ACM devices stay throttled when their TTY is closed while
throttled, stalling further communication attempts after the next open.
Unthrottling during open/activate got lost starting with kernel
3.0.0 and this patch reintroduces it.
Signed-off-by: Otto Meta <otto.patches@sister-shadow.de>
Acked-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Wed, 13 Jun 2012 15:20:19 +0000 (11:20 -0400)]
USB: add NO_D3_DURING_SLEEP flag and revert
151b61284776be2
commit
c2fb8a3fa25513de8fedb38509b1f15a5bbee47b upstream.
This patch (as1558) 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.
A similar patch has already been applied as commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers). The patch supersedes that one and reverts
it. There are two differences:
The old patch added the flag at the USB level; this patch
adds it at the PCI level.
The old patch applied to all chipsets with the same vendor,
subsystem vendor, and product IDs; this patch makes an
exception for a known-good system (based on DMI information).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Evan McNabb [Sat, 26 May 2012 02:46:14 +0000 (22:46 -0400)]
USB: ftdi-sio: Add support for RT Systems USB-RTS01 serial adapter
commit
e00a54d772210d450e5c1a801534c3c8a448549f upstream.
Add support for RT Systems USB-RTS01 USB to Serial adapter:
http://www.rtsystemsinc.com/Photos/USBRTS01.html
Tested by controlling Icom IC-718 amateur radio transceiver via hamlib.
Signed-off-by: Evan McNabb <evan@mcnabbs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikko Tuumanen [Fri, 1 Jun 2012 08:28:55 +0000 (11:28 +0300)]
USB: serial: cp210x: add Optris MS Pro usb id
commit
5bbfa6f427c1d7244a5ee154ab8fa37265a5e049 upstream.
Signed-off-by: Mikko Tuumanen <mikko.tuumanen@qemsoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Cox [Tue, 22 May 2012 19:45:13 +0000 (20:45 +0100)]
USB: mct_u232: Fix incorrect TIOCMSET return
commit
1aa3c63cf0a79153ee13c8f82e4eb6c40b66a161 upstream.
The low level helper returns 1 on success. The ioctl should however return
0. As this is the only user of the helper return, make the helper return 0 or
an error code.
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=43009
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Thu, 24 May 2012 09:19:04 +0000 (11:19 +0200)]
USB: qcserial: Add Sierra Wireless device IDs
commit
c41444ccfa33a1c20efa319e554cb531576e64a2 upstream.
Some additional IDs found in the BSD/GPL licensed out-of-tree
GobiSerial driver from Sierra Wireless.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tony Zelenoff [Tue, 5 Jun 2012 13:58:04 +0000 (17:58 +0400)]
USB: mos7840: Fix compilation of usb serial driver
commit
b9c87663eead64c767e72a373ae6f8a94bead459 upstream.
The __devinitconst section can't be referenced
from usb_serial_device structure. Thus removed it as
it done in other mos* device drivers.
Error itself:
WARNING: drivers/usb/serial/mos7840.o(.data+0x8): Section mismatch in reference
from the variable moschip7840_4port_device to the variable
.devinit.rodata:id_table
The variable moschip7840_4port_device references
the variable __devinitconst id_table
[v2] no attach now
Signed-off-by: Tony Zelenoff <antonz@parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andiry Xu [Wed, 13 Jun 2012 02:51:57 +0000 (10:51 +0800)]
xHCI: Increase the timeout for controller save/restore state operation
commit
622eb783fe6ff4c1baa47db16c3a5db97f9e6e50 upstream.
When system software decides to power down the xHC with the intent of
resuming operation at a later time, it will ask xHC to save the internal
state and restore it when resume to correctly recover from a power event.
Two bits are used to enable this operation: Save State and Restore State.
xHCI spec 4.23.2 says software should "Set the Controller Save/Restore
State flag in the USBCMD register and wait for the Save/Restore State
Status flag in the USBSTS register to transition to '0'". However, it does
not define how long software should wait for the SSS/RSS bit to transition
to 0.
Currently the timeout is set to 1ms. There is bug report
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/
1002697)
indicates that the timeout is too short for ASMedia ASM1042 host controller
to save/restore the state successfully. Increase the timeout to 10ms helps to
resolve the issue.
This patch should be backported to stable kernels as old as 2.6.37, that
contain the commit
5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI:
PCI power management implementation"
Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Janne Kalliomäki [Sun, 17 Jun 2012 21:05:24 +0000 (17:05 -0400)]
hfsplus: fix overflow in sector calculations in hfsplus_submit_bio
commit
a6dc8c04218eb752ff79cdc24a995cf51866caed upstream.
The variable io_size was unsigned int, which caused the wrong sector number
to be calculated after aligning it. This then caused mount to fail with big
volumes, as backup volume header information was searched from a
wrong sector.
Signed-off-by: Janne Kalliomäki <janne@tuxera.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 29 May 2012 15:57:52 +0000 (17:57 +0200)]
USB: option: fix port-data abuse
commit
4273f9878b0a8271df055e3c8f2e7f08c6a4a2f4 upstream.
Commit
8b4c6a3ab596961b78465 ("USB: option: Use generic USB wwan code")
moved option port-data allocation to usb_wwan_startup but still cast the
port data to the old struct...
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 29 May 2012 16:22:48 +0000 (18:22 +0200)]
USB: option: fix memory leak
commit
b9c3aab315b51f81649a0d737c4c73783fbd8de0 upstream.
Fix memory leak introduced by commit
383cedc3bb435de7a2 ("USB: serial:
full autosuspend support for the option driver") which allocates
usb-serial data but never frees it.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
说不得 [Mon, 28 May 2012 13:31:29 +0000 (21:31 +0800)]
USB: option: add more YUGA device ids
commit
0ef0be15fd2564767f114c249fc4af704d8e16f4 upstream.
Signed-off-by: gavin zhu <gavin.zhu@qq.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Bird [Mon, 28 May 2012 11:43:06 +0000 (12:43 +0100)]
USB: option: Updated Huawei K4605 has better id
commit
42ca7da1c2363dbef4ba1b6917c4c02274b6a5e2 upstream.
Later firmwares for this device now have proper subclass and
protocol info so we can identify it nicely without needing to use
the blacklist. I'm not removing the old 0xff matching as there
may be devices in the field that still need that.
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Sat, 19 May 2012 17:20:50 +0000 (19:20 +0200)]
USB: option: Add Vodafone/Huawei K5005 support
commit
4cbbb039a9719fb3bba73d255c6a95bc6dc6428b upstream.
Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Thu, 31 May 2012 19:26:38 +0000 (15:26 -0400)]
NFSv4.1: Fix a request leak on the back channel
commit
b3b02ae5865c2dcd506322e0fc6def59a042e72f upstream.
If the call to svc_process_common() fails, then the request
needs to be freed before we can exit bc_svc_process.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andre Przywara [Tue, 29 May 2012 11:07:31 +0000 (13:07 +0200)]
xen/setup: filter APERFMPERF cpuid feature out
commit
5e626254206a709c6e937f3dda69bf26c7344f6f upstream.
Xen PV kernels allow access to the APERF/MPERF registers to read the
effective frequency. Access to the MSRs is however redirected to the
currently scheduled physical CPU, making consecutive read and
compares unreliable. In addition each rdmsr traps into the hypervisor.
So to avoid bogus readouts and expensive traps, disable the kernel
internal feature flag for APERF/MPERF if running under Xen.
This will
a) remove the aperfmperf flag from /proc/cpuinfo
b) not mislead the power scheduler (arch/x86/kernel/cpu/sched.c) to
use the feature to improve scheduling (by default disabled)
c) not mislead the cpufreq driver to use the MSRs
This does not cover userland programs which access the MSRs via the
device file interface, but this will be addressed separately.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jaccon Bastiaansen [Mon, 30 Apr 2012 09:53:43 +0000 (11:53 +0200)]
ARM i.MX imx21ads: Fix overlapping static i/o mappings
commit
350ab15bb2ffe7103bc6bf6c634f3c5b286eaf2a upstream.
The statically defined I/O memory regions for the i.MX21 on chip
peripherals and the on board I/O peripherals of the i.MX21ADS board
overlap. This results in a kernel crash during startup. This is fixed
by reducing the memory range for the on board I/O peripherals to the
actually required range.
Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 17 Jun 2012 18:23:33 +0000 (11:23 -0700)]
Linux 3.0.35
Dave Hansen [Tue, 29 May 2012 22:06:46 +0000 (15:06 -0700)]
hugetlb: fix resv_map leak in error path
commit
c50ac050811d6485616a193eb0f37bfbd191cc89 and
4523e1458566a0e8ecfaff90f380dd23acc44d27 upstream.
When called for anonymous (non-shared) mappings, hugetlb_reserve_pages()
does a resv_map_alloc(). It depends on code in hugetlbfs's
vm_ops->close() to release that allocation.
However, in the mmap() failure path, we do a plain unmap_region() without
the remove_vma() which actually calls vm_ops->close().
This is a decent fix. This leak could get reintroduced if new code (say,
after hugetlb_reserve_pages() in hugetlbfs_file_mmap()) decides to return
an error. But, I think it would have to unroll the reservation anyway.
Christoph's test case:
http://marc.info/?l=linux-mm&m=
133728900729735
This patch applies to 3.4 and later. A version for earlier kernels is at
https://lkml.org/lkml/2012/5/22/418.
Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reported-by: Christoph Lameter <cl@linux.com>
Tested-by: Christoph Lameter <cl@linux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KyongHo [Tue, 29 May 2012 22:06:49 +0000 (15:06 -0700)]
mm: fix faulty initialization in vmalloc_init()
commit
dbda591d920b4c7692725b13e3f68ecb251e9080 upstream.
The transfer of ->flags causes some of the static mapping virtual
addresses to be prematurely freed (before the mapping is removed) because
VM_LAZY_FREE gets "set" if tmp->flags has VM_IOREMAP set. This might
cause subsequent vmalloc/ioremap calls to fail because it might allocate
one of the freed virtual address ranges that aren't unmapped.
va->flags has different types of flags from tmp->flags. If a region with
VM_IOREMAP set is registered with vm_area_add_early(), it will be removed
by __purge_vmap_area_lazy().
Fix vmalloc_init() to correctly initialize vmap_area for the given
vm_struct.
Also initialise va->vm. If it is not set, find_vm_area() for the early
vm regions will always fail.
Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
Cc: "Olav Haugan" <ohaugan@codeaurora.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Minchan Kim [Tue, 10 Jan 2012 23:08:39 +0000 (15:08 -0800)]
mm/vmalloc.c: change void* into explict vm_struct*
commit
db1aecafef58b5dda39c4228debe2c845e4a27ab upstream.
vmap_area->private is void* but we don't use the field for various purpose
but use only for vm_struct. So change it to a vm_struct* with naming to
improve for readability and type checking.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dean Nelson [Thu, 25 Aug 2011 14:39:24 +0000 (14:39 +0000)]
e1000: save skb counts in TX to avoid cache misses
commit
31c15a2f24ebdab14333d9bf5df49757842ae2ec upstream.
Virtual Machines with emulated e1000 network adapter running on Parallels'
server were seeing kernel panics due to the e1000 driver dereferencing an
unexpected NULL pointer retrieved from buffer_info->skb.
The problem has been addressed for the e1000e driver, but not for the e1000.
Since the two drivers share similar code in the affected area, a port of the
following e1000e driver commit solves the issue for the e1000 driver:
commit
9ed318d546a29d7a591dbe648fd1a2efe3be1180
Author: Tom Herbert <therbert@google.com>
Date: Wed May 5 14:02:27 2010 +0000
e1000e: save skb counts in TX to avoid cache misses
In e1000_tx_map, precompute number of segements and bytecounts which
are derived from fields in skb; these are stored in buffer_info. When
cleaning tx in e1000_clean_tx_irq use the values in the associated
buffer_info for statistics counting, this eliminates cache misses
on skb fields.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Roman Kagan <rkagan@parallels.com>
Pavel Shilovsky [Thu, 10 May 2012 15:49:38 +0000 (19:49 +0400)]
fuse: fix stat call on 32 bit platforms
commit
45c72cd73c788dd18c8113d4a404d6b4a01decf1 upstream.
Now we store attr->ino at inode->i_ino, return attr->ino at the
first time and then return inode->i_ino if the attribute timeout
isn't expired. That's wrong on 32 bit platforms because attr->ino
is 64 bit and inode->i_ino is 32 bit in this case.
Fix this by saving 64 bit ino in fuse_inode structure and returning
it every time we call getattr. Also squash attr->ino into inode->i_ino
explicitly.
Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Mon, 16 Apr 2012 16:01:53 +0000 (18:01 +0200)]
x86, MCE, AMD: Make APIC LVT thresholding interrupt optional
commit
f227d4306cf30e1d5b6f231e8ef9006c34f3d186 upstream.
Currently, the APIC LVT interrupt for error thresholding is implicitly
enabled. However, there are models in the F15h range which do not enable
it. Make the code machinery which sets up the APIC interrupt support
an optional setting and add an ->interrupt_capable member to the bank
representation mirroring that capability and enable the interrupt offset
programming only if it is true.
Simplify code and fixup comment style while at it.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Emmanuel Grumbach [Wed, 6 Jun 2012 07:13:36 +0000 (09:13 +0200)]
iwlwifi: don't mess up the SCD when removing a key
commit
d6ee27eb13beab94056e0de52d81220058ca2297 upstream.
When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.
This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.
The message is the log that was printed is:
Queue 2 stuck for 10000ms
This doesn't seem to fix the higher queues that get stuck
from time to time.
Reviewed-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dimitri Sivanich [Tue, 5 Jun 2012 18:44:36 +0000 (13:44 -0500)]
sched: Fix the relax_domain_level boot parameter
commit
a841f8cef4bb124f0f5563314d0beaf2e1249d72 upstream.
It does not get processed because sched_domain_level_max is 0 at the
time that setup_relax_domain_level() is run.
Simply accept the value as it is, as we don't know the value of
sched_domain_level_max until sched domain construction is completed.
Fix sched_relax_domain_level in cpuset. The build_sched_domain() routine calls
the set_domain_attribute() routine prior to setting the sd->level, however,
the set_domain_attribute() routine relies on the sd->level to decide whether
idle load balancing will be off/on.
Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120605184436.GA15668@sgi.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Cox [Wed, 25 Apr 2012 13:33:33 +0000 (14:33 +0100)]
acpi_video: fix leaking PCI references
commit
cfb46f433a4da97c31780e08a259fac2cb6bd61f upstream.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andre Przywara [Fri, 23 Mar 2012 09:02:17 +0000 (10:02 +0100)]
hwmon: (fam15h_power) Increase output resolution
commit
941a956b0e387b21f385f486c34ef67576775cfc upstream.
On high CPU load the accumulating values in the running_avg_cap
register are very low (below 10), so averaging them too early leads
to unnecessary poor output resolution. Since we pretend to output
micro-Watt we better keep all the bits we have as long as possible.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AnilKumar Ch [Wed, 23 May 2012 12:15:11 +0000 (17:45 +0530)]
can: c_can: fix race condition in c_can_open()
commit
f461f27a4436dbe691908fe08b867ef888848cc3 upstream.
Fix the issue of C_CAN interrupts getting disabled forever when canconfig
utility is used multiple times. According to NAPI usage we disable all
the hardware interrupts in ISR and re-enable them in poll(). Current
implementation calls napi_enable() after hardware interrupts are enabled.
If we get any interrupts between these two steps then we do not process
those interrupts because napi is not enabled. Mostly these interrupts
come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable()
happens before HW interrupts enabled then c_can_poll() function will be
called eventual re-enabling.
This patch moves the napi_enable() call before interrupts enabled.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AnilKumar Ch [Wed, 23 May 2012 12:15:10 +0000 (17:45 +0530)]
can: c_can: fix an interrupt thrash issue with c_can driver
commit
148c87c89e1a8863d3d965179f3ab1a06490569e upstream.
This patch fixes an interrupt thrash issue with c_can driver.
In c_can_isr() function interrupts are disabled and enabled only in
c_can_poll() function. c_can_isr() & c_can_poll() both read the
irqstatus flag. However, irqstatus is always read as 0 in c_can_poll()
because all C_CAN interrupts are disabled in c_can_isr(). This causes
all interrupts to be re-enabled in c_can_poll() which in turn causes
another interrupt since the event is not really handled. This keeps
happening causing a flood of interrupts.
To fix this, read the irqstatus register in isr and use the same cached
value in the poll function.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AnilKumar Ch [Wed, 23 May 2012 12:15:09 +0000 (17:45 +0530)]
can: c_can: fix "BUG! echo_skb is occupied!" during transmit
commit
617caccebe451716df21c069b079d5936ed7b0f3 upstream.
This patch fixes an issue with transmit routine, which causes
"can_put_echo_skb: BUG! echo_skb is occupied!" message when
using "cansequence -p" on D_CAN controller.
In c_can driver, while transmitting packets tx_echo flag holds
the no of can frames put for transmission into the hardware.
As the comment above c_can_do_tx() indicates, if we find any packet
which is not transmitted then we should stop looking for more.
In the current implementation this is not taken care of causing the
said message.
Also, fix the condition used to find if the packet is transmitted
or not. Current code skips the first tx message object and ends up
checking one extra invalid object.
While at it, fix the comment on top of c_can_do_tx() to use the
terminology "packet" instead of "package" since it is more
standard.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Tue, 5 Jun 2012 21:18:10 +0000 (21:18 +0000)]
net: sierra_net: device IDs for Aircard 320U++
commit
dd03cff23d694cfb0fdae80cb618e7ced05ea696 upstream.
Adding device IDs for Aircard 320U and two other devices
found in the out-of-tree version of this driver.
Cc: linux@sierrawireless.com
Cc: Autif Khan <autif.mlist@gmail.com>
Cc: Tom Cassidy <tomas.cassidy@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Tue, 5 Jun 2012 10:16:50 +0000 (12:16 +0200)]
cfg80211: fix interface combinations check
commit
463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream.
If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.
Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Thu, 31 May 2012 13:09:27 +0000 (15:09 +0200)]
mac80211: clean up remain-on-channel on interface stop
commit
71ecfa1893034eeb1c93e02e22ee2ad26d080858 upstream.
When any interface goes down, it could be the one that we
were doing a remain-on-channel with. We therefore need to
cancel the remain-on-channel and flush the related work
structs so they don't run after the interface has been
removed or even destroyed.
It's also possible in this case that an off-channel SKB
was never transmitted, so free it if this is the case.
Note that this can also happen if the driver finishes
the off-channel period without ever starting it.
Reported-by: Nirav Shah <nirav.j2.shah@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Tue, 29 May 2012 23:43:08 +0000 (01:43 +0200)]
crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
commit
7c8d51848a88aafdb68f42b6b650c83485ea2f84 upstream.
The 32 bit variant of cbc(aes) decrypt is using instructions requiring
128 bit aligned memory locations but fails to ensure this constraint in
the code. Fix this by loading the data into intermediate registers with
load unaligned instructions.
This fixes reported general protection faults related to aesni.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43223
Reported-by: Daniel <garkein@mailueberfall.de>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Rumler [Wed, 6 Jun 2012 14:37:17 +0000 (16:37 +0200)]
powerpc: Fix kernel panic during kernel module load
commit
3c75296562f43e6fbc6cddd3de948a7b3e4e9bcf upstream.
This fixes a problem which can causes kernel oopses while loading
a kernel module.
According to the PowerPC EABI specification, GPR r11 is assigned
the dedicated function to point to the previous stack frame.
In the powerpc-specific kernel module loader, do_plt_call()
(in arch/powerpc/kernel/module_32.c), GPR r11 is also used
to generate trampoline code.
This combination crashes the kernel, in the case where the compiler
chooses to use a helper function for saving GPRs on entry, and the
module loader has placed the .init.text section far away from the
.text section, meaning that it has to generate a trampoline for
functions in the .init.text section to call the GPR save helper.
Because the trampoline trashes r11, references to the stack frame
using r11 can cause an oops.
The fix just uses GPR r12 instead of GPR r11 for generating the
trampoline code. According to the statements from Freescale, this is
safe from an EABI perspective.
I've tested the fix for kernel 2.6.33 on MPC8541.
Signed-off-by: Steffen Rumler <steffen.rumler.ext@nsn.com>
[paulus@samba.org: reworded the description]
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roland Dreier [Thu, 7 Jun 2012 21:21:13 +0000 (14:21 -0700)]
btree: fix tree corruption in btree_get_prev()
commit
cbf8ae32f66a9ceb8907ad9e16663c2a29e48990 upstream.
The memory the parameter __key points to is used as an iterator in
btree_get_prev(), so if we save off a bkey() pointer in retry_key and
then assign that to __key, we'll end up corrupting the btree internals
when we do eg
longcpy(__key, bkey(geo, node, i), geo->keylen);
to return the key value. What we should do instead is use longcpy() to
copy the key value that retry_key points to __key.
This can cause a btree to get corrupted by seemingly read-only
operations such as btree_for_each_safe.
[akpm@linux-foundation.org: avoid the double longcpy()]
Signed-off-by: Roland Dreier <roland@purestorage.com>
Acked-by: Joern Engel <joern@logfs.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eugeni Dodonov [Wed, 6 Jun 2012 14:59:06 +0000 (11:59 -0300)]
char/agp: add another Ironlake host bridge
commit
67384fe3fd450536342330f684ea1f7dcaef8130 upstream.
This seems to come on Gigabyte H55M-S2V and was discovered through the
https://bugs.freedesktop.org/show_bug.cgi?id=50381 debugging.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50381
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sat, 9 Jun 2012 15:33:45 +0000 (00:33 +0900)]
Linux 3.0.34
Tao Ma [Thu, 7 Jun 2012 23:04:19 +0000 (19:04 -0400)]
ext4: don't set i_flags in EXT4_IOC_SETFLAGS
commit
b22b1f178f6799278d3178d894f37facb2085765 upstream.
Commit
7990696 uses the ext4_{set,clear}_inode_flags() functions to
change the i_flags automatically but fails to remove the error setting
of i_flags. So we still have the problem of trashing state flags.
Fix this by removing the assignment.
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grazvydas Ignotas [Fri, 18 May 2012 00:04:08 +0000 (03:04 +0300)]
wl1251: fix oops on early interrupt
commit
f380f2c4a12e913356bd49f8790ec1063c4fe9f8 upstream.
This driver disables interrupt just after requesting it and enables it
later, after interface is up. However currently there is a time window
between request_irq() and disable_irq() where if interrupt arrives, the
driver oopses because it's not yet ready to process it. This can be
reproduced by inserting the module, associating and removing the module
multiple times.
Eliminate this race by setting IRQF_NOAUTOEN flag before request_irq().
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>
Andy Whitcroft [Thu, 3 May 2012 13:48:26 +0000 (14:48 +0100)]
ACPI battery: only refresh the sysfs files when pertinent information changes
commit
c5971456964290da7e98222892797b71ef793e62 upstream.
We only need to regenerate the sysfs files when the capacity units
change, avoid the update otherwise.
The origin of this issue is dates way back to 2.6.38:
da8aeb92d4853f37e281f11fddf61f9c7d84c3cd
(ACPI / Battery: Update information on info notification and resume)
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Tested-by: Ralf Jung <post@ralfj.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 5 Jun 2012 13:50:30 +0000 (09:50 -0400)]
drm/radeon/kms: add new BTC PCI ids
commit
a2bef8ce826dd1e787fd8ad9b6e0566ba59dab43 upstream.
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>
Salman Qazi [Fri, 1 Jun 2012 03:52:14 +0000 (23:52 -0400)]
ext4: remove mb_groups before tearing down the buddy_cache
commit
95599968d19db175829fb580baa6b68939b320fb upstream.
We can't have references held on pages in the s_buddy_cache while we are
trying to truncate its pages and put the inode. All the pages must be
gone before we reach clear_inode. This can only be gauranteed if we
can prevent new users from grabbing references to s_buddy_cache's pages.
The original bug can be reproduced and the bug fix can be verified by:
while true; do mount -t ext4 /dev/ram0 /export/hda3/ram0; \
umount /export/hda3/ram0; done &
while true; do cat /proc/fs/ext4/ram0/mb_groups; done
Signed-off-by: Salman Qazi <sqazi@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Salman Qazi [Fri, 1 Jun 2012 03:51:27 +0000 (23:51 -0400)]
ext4: add ext4_mb_unload_buddy in the error path
commit
02b7831019ea4e7994968c84b5826fa8b248ffc8 upstream.
ext4_free_blocks fails to pair an ext4_mb_load_buddy with a matching
ext4_mb_unload_buddy when it fails a memory allocation.
Signed-off-by: Salman Qazi <sqazi@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Fri, 1 Jun 2012 03:46:01 +0000 (23:46 -0400)]
ext4: don't trash state flags in EXT4_IOC_SETFLAGS
commit
79906964a187c405db72a3abc60eb9b50d804fbc upstream.
In commit
353eb83c we removed i_state_flags with 64-bit longs, But
when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
directly, which trashes the state flags which are stored in the high
32-bits of i_flags on 64-bit platforms. So use the the
ext4_{set,clear}_inode_flags() functions which use atomic bit
manipulation functions instead.
Reported-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Thu, 31 May 2012 03:00:16 +0000 (23:00 -0400)]
ext4: add missing save_error_info() to ext4_error()
commit
f3fc0210c0fc91900766c995f089c39170e68305 upstream.
The ext4_error() function is missing a call to save_error_info().
Since this is the function which marks the file system as containing
an error, this oversight (which was introduced in 2.6.36) is quite
significant, and should be backported to older stable kernels with
high urgency.
Reported-by: Ken Sumrall <ksumrall@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: ksumrall@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Sandeen [Mon, 28 May 2012 18:17:25 +0000 (14:17 -0400)]
ext4: force ro mount if ext4_setup_super() fails
commit
7e84b6216467b84cd332c8e567bf5aa113fd2f38 upstream.
If ext4_setup_super() fails i.e. due to a too-high revision,
the error is logged in dmesg but the fs is not mounted RO as
indicated.
Tested by:
# mkfs.ext4 -r 4 /dev/sdb6
# mount /dev/sdb6 /mnt/test
# dmesg | grep "too high"
[164919.759248] EXT4-fs (sdb6): revision level too high, forcing read-only mode
# grep sdb6 /proc/mounts
/dev/sdb6 /mnt/test2 ext4 rw,seclabel,relatime,data=ordered 0 0
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>