7 years agotrace_events_filter: Use rcu_assign_pointer() when setting ftrace_event_call->filter
Tejun Heo [Wed, 23 Nov 2011 16:49:49 +0000]
trace_events_filter: Use rcu_assign_pointer() when setting ftrace_event_call->filter

commit d3d9acf646679c1981032b0985b386d12fccc60c upstream.

ftrace_event_call->filter is sched RCU protected but didn't use
rcu_assign_pointer().  Use it.

TODO: Add proper __rcu annotation to call->filter and all its users.

-v2: Use RCU_INIT_POINTER() for %NULL clearing as suggested by Eric.

Link: http://lkml.kernel.org/r/20111123164949.GA29639@google.com

Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoftrace: Remove force undef config value left for testing
Steven Rostedt [Fri, 4 Nov 2011 14:45:23 +0000]
ftrace: Remove force undef config value left for testing

commit c7c6ec8becaf742b223c7b491f4893014be23a07 upstream.

A forced undef of a config value was used for testing and was
accidently left in during the final commit. This causes x86 to
run slower than needed while running function tracing as well
as causes the function graph selftest to fail when DYNMAIC_FTRACE
is not set. This is because the code in MCOUNT expects the ftrace
code to be processed with the config value set that happened to
be forced not set.

The forced config option was left in by:
    commit 6331c28c962561aee59e5a493b7556a4bb585957
    ftrace: Fix dynamic selftest failure on some archs

Link: http://lkml.kernel.org/r/20111102150255.GA6973@debian

Reported-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoiwlagn: fix HW crypto for TX-only keys
Johannes Berg [Fri, 2 Dec 2011 16:19:17 +0000]
iwlagn: fix HW crypto for TX-only keys

commit 274b89ca3b006926cb9b45d78ab5906f4c0fc0aa upstream.

Group keys in IBSS or AP mode are not programmed
into the device since we give the key to it with
every TX packet. However, we do need mac80211 to
create the MMIC & PN in all cases. Move the code
around to set the key flags all the time. We set
them even when the key is removed again but that
is obviously harmless.

Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoiwlwifi: do not re-configure HT40 after associated
Wey-Yi Guy [Fri, 2 Dec 2011 16:19:18 +0000]
iwlwifi: do not re-configure HT40 after associated

commit 34a5b4b6af104cf18eb50748509528b9bdbc4036 upstream.

The ht40 setting should not change after association unless channel switch

This fix a problem we are seeing which cause uCode assert because driver
sending invalid information and make uCode confuse

Here is the firmware assert message:
kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
kernel: iwlagn 0000:03:00.0: CSR values:
kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
kernel: iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00480303
kernel: iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X0000ff40
kernel: iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
kernel: iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
kernel: iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000030
kernel: iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
kernel: iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
kernel: iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X000000b0
kernel: iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X07d60ffd
kernel: iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
kernel: iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00030001
kernel: iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080044
kernel: iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000093bb
kernel: iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
kernel: iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000078
kernel: iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X88214dd2
kernel: iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
kernel: iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
kernel: iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0010
kernel: iwlagn 0000:03:00.0: FH register values:
kernel: iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
kernel: iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
kernel: iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X00000060
kernel: iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
kernel: iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
kernel: iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
kernel: iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
kernel: iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
kernel: iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
kernel: ------------[ cut here ]------------
WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
kernel: Hardware name: 4290W4H
kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
kernel: Call Trace:
kernel:  [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
kernel:  [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
kernel:  [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
kernel:  [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
kernel:  [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
kernel:  [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
kernel:  [<ffffffff8104ba97>] ? kthread+0x7a/0x82
kernel:  [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
kernel:  [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
kernel:  [<ffffffff813d21b0>] ? gs_change+0xb/0xb

Reported-by: Udo Steinberg <udo@hypervisor.org>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoslab, lockdep: Fix silly bug
Peter Zijlstra [Mon, 28 Nov 2011 20:12:40 +0000]
slab, lockdep: Fix silly bug

commit 52cef189165d74a5d6030184a8e05595194c69ca upstream.

Commit 30765b92 ("slab, lockdep: Annotate the locks before using
them") moves the init_lock_keys() call from after g_cpucache_up =
FULL, to before it. And overlooks the fact that init_node_lock_keys()
tests for it and ignores everything !FULL.

Introduce a LATE stage and change the lockdep test to be <LATE.

Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agogenirq: Fix race condition when stopping the irq thread
Ido Yariv [Thu, 1 Dec 2011 11:55:08 +0000]
genirq: Fix race condition when stopping the irq thread

commit 550acb19269d65f32e9ac4ddb26c2b2070e37f1c upstream.

In irq_wait_for_interrupt(), the should_stop member is verified before
setting the task's state to TASK_INTERRUPTIBLE and calling schedule().
In case kthread_stop sets should_stop and wakes up the process after
should_stop is checked by the irq thread but before the task's state
is changed, the irq thread might never exit:

kthread_stop                    irq_wait_for_interrupt
------------                    ----------------------

                                 ...
...                              while (!kthread_should_stop()) {
kthread->should_stop = 1;
wake_up_process(k);
wait_for_completion(&kthread->exited);
...
                                     set_current_state(TASK_INTERRUPTIBLE);

                                     ...

                                     schedule();
                                 }

Fix this by checking if the thread should stop after modifying the
task's state.

[ tglx: Simplified it a bit ]

Signed-off-by: Ido Yariv <ido@wizery.com>
Link: http://lkml.kernel.org/r/1322740508-22640-1-git-send-email-ido@wizery.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agocfg80211: amend regulatory NULL dereference fix
Luis R. Rodriguez [Mon, 28 Nov 2011 21:47:16 +0000]
cfg80211: amend regulatory NULL dereference fix

commit 0bac71af6e66dc798bf07d0c0dd14ee5503362f9 upstream.

Johannes' patch for "cfg80211: fix regulatory NULL dereference"
broke user regulaotry hints and it did not address the fact that
last_request was left populated even if the previous regulatory
hint was stale due to the wiphy disappearing.

Fix user reguluatory hints by only bailing out if for those
regulatory hints where a request_wiphy is expected. The stale last_request
considerations are addressed through the previous fixes on last_request
where we reset the last_request to a static world regdom request upon
reset_regdomains(). In this case though we further enhance the effect
by simply restoring reguluatory settings completely.

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agocfg80211: fix race on init and driver registration
Luis R. Rodriguez [Mon, 28 Nov 2011 21:47:15 +0000]
cfg80211: fix race on init and driver registration

commit a042994dd377d86bff9446ee76151ceb6267c9ba upstream.

There is a theoretical race that if hit will trigger
a crash. The race is between when we issue the first
regulatory hint, regulatory_hint_core(), gets processed
by the workqueue and between when the first device
gets registered to the wireless core. This is not easy
to reproduce but it was easy to do so through the
regulatory simulator I have been working on. This
is a port of the fix I implemented there [1].

[1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agomac80211: fix race condition caused by late addBA response
Nikolay Martynov [Tue, 6 Dec 2011 14:39:32 +0000]
mac80211: fix race condition caused by late addBA response

Upstream commit d305a6557b2c4dca0110f05ffe745b1ef94adb80.

If addBA responses comes in just after addba_resp_timer has
expired mac80211 will still accept it and try to open the
aggregation session. This causes drivers to be confused and
in some cases even crash.

This patch fixes the race condition and makes sure that if
addba_resp_timer has expired addBA response is not longer
accepted and we do not try to open half-closed session.

Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
[some adjustments]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

7 years agomac80211: fill rate filter for internal scan requests
Simon Wunderlich [Wed, 30 Nov 2011 15:56:30 +0000]
mac80211: fill rate filter for internal scan requests

commit c72e8d335e2c6a309b6281f2abcf491f37b8b92b upstream.

The rates bitmap for internal scan requests shoud be filled,
otherwise there will be probe requests with zero rates supported.

Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoadd missing .set function for NT_S390_LAST_BREAK regset
Martin Schwidefsky [Thu, 1 Dec 2011 12:32:17 +0000]
add missing .set function for NT_S390_LAST_BREAK regset

commit b934069c991355d27a053a932591c77960f4e414 upstream.

The last breaking event address is a read-only value, the regset misses the
.set function. If a PTRACE_SETREGSET is done for NT_S390_LAST_BREAK we
get an oops due to a branch to zero:

Kernel BUG at 0000000000000002 verbose debug info unavailable
illegal operation: 0001 #1 SMP
...
Call Trace:
(<0000000000158294> ptrace_regset+0x184/0x188)
 <00000000001595b6> ptrace_request+0x37a/0x4fc
 <0000000000109a78> arch_ptrace+0x108/0x1fc
 <00000000001590d6> SyS_ptrace+0xaa/0x12c
 <00000000005c7a42> sysc_noemu+0x16/0x1c
 <000003fffd5ec10c> 0x3fffd5ec10c
Last Breaking-Event-Address:
 <0000000000158242> ptrace_regset+0x132/0x188

Add a nop .set function to prevent the branch to zero.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agooprofile, x86: Fix crash when unloading module (nmi timer mode)
Robert Richter [Mon, 10 Oct 2011 14:21:10 +0000]
oprofile, x86: Fix crash when unloading module (nmi timer mode)

commit 97f7f8189fe54e3cfe324ef9ad35064f3d2d3bff upstream.

If oprofile uses the nmi timer interrupt there is a crash while
unloading the module. The bug can be triggered with oprofile build as
module and kernel parameter nolapic set. This patch fixes this.

oprofile: using NMI timer interrupt.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58
PGD 42dbca067 PUD 41da6a067 PMD 0
Oops: 0002 [#1] PREEMPT SMP
CPU 5
Modules linked in: oprofile(-) [last unloaded: oprofile]

Pid: 2518, comm: modprobe Not tainted 3.1.0-rc7-00019-gb2fb49d #19 Advanced Micro Device Anaheim/Anaheim
RIP: 0010:[<ffffffff8123c226>]  [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58
RSP: 0018:ffff88041ef71e98  EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffffffa0017100 RCX: dead000000200200
RDX: 0000000000000000 RSI: dead000000100100 RDI: ffffffff8178c620
RBP: ffff88041ef71ea8 R08: 0000000000000001 R09: 0000000000000082
R10: 0000000000000000 R11: ffff88041ef71de8 R12: 0000000000000080
R13: fffffffffffffff5 R14: 0000000000000001 R15: 0000000000610210
FS:  00007fc902f20700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 000000041cdb6000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 2518, threadinfo ffff88041ef70000, task ffff88041d348040)
Stack:
 ffff88041ef71eb8 ffffffffa0017790 ffff88041ef71eb8 ffffffffa0013532
 ffff88041ef71ec8 ffffffffa00132d6 ffff88041ef71ed8 ffffffffa00159b2
 ffff88041ef71f78 ffffffff81073115 656c69666f72706f 0000000000610200
Call Trace:
 [<ffffffffa0013532>] op_nmi_exit+0x15/0x17 [oprofile]
 [<ffffffffa00132d6>] oprofile_arch_exit+0xe/0x10 [oprofile]
 [<ffffffffa00159b2>] oprofile_exit+0x1e/0x20 [oprofile]
 [<ffffffff81073115>] sys_delete_module+0x1c3/0x22f
 [<ffffffff811bf09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff8148070b>] system_call_fastpath+0x16/0x1b
Code: 20 c6 78 81 e8 c5 cc 23 00 48 8b 13 48 8b 43 08 48 be 00 01 10 00 00 00 ad de 48 b9 00 02 20 00 00 00 ad de 48 c7 c7 20 c6 78 81
 89 42 08 48 89 10 48 89 33 48 89 4b 08 e8 a6 c0 23 00 5a 5b
RIP  [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58
 RSP <ffff88041ef71e98>
CR2: 0000000000000008
---[ end trace 43a541a52956b7b0 ]---

Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoperf/x86: Fix PEBS instruction unwind
Peter Zijlstra [Fri, 7 Oct 2011 11:36:40 +0000]
perf/x86: Fix PEBS instruction unwind

commit 57d1c0c03c6b48b2b96870d831b9ce6b917f53ac upstream.

Masami spotted that we always try to decode the instruction stream as
64bit instructions when running a 64bit kernel, this doesn't work for
ia32-compat proglets.

Use TIF_IA32 to detect if we need to use the 32bit instruction
decoder.

Reported-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agox86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of...
Konrad Rzeszutek Wilk [Tue, 15 Nov 2011 22:49:09 +0000]
x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode

commit 2cd1c8d4dc7ecca9e9431e2dabe41ae9c7d89e51 upstream.

Fix an outstanding issue that has been reported since 2.6.37.
Under a heavy loaded machine processing "fork()" calls could
crash with:

BUG: unable to handle kernel paging request at f573fc8c
IP: [<c01abc54>] swap_count_continued+0x104/0x180
*pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 Oops: 0000 [#1] SMP
Modules linked in:
Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1
EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3
EIP is at swap_count_continued+0x104/0x180
.. snip..
Call Trace:
 [<c01ac222>] ? __swap_duplicate+0xc2/0x160
 [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0
 [<c01ac2e4>] ? swap_duplicate+0x14/0x40
 [<c01a0a6b>] ? copy_pte_range+0x45b/0x500
 [<c01a0ca5>] ? copy_page_range+0x195/0x200
 [<c01328c6>] ? dup_mmap+0x1c6/0x2c0
 [<c0132cf8>] ? dup_mm+0xa8/0x130
 [<c013376a>] ? copy_process+0x98a/0xb30
 [<c013395f>] ? do_fork+0x4f/0x280
 [<c01573b3>] ? getnstimeofday+0x43/0x100
 [<c010f770>] ? sys_clone+0x30/0x40
 [<c06c048d>] ? ptregs_clone+0x15/0x48
 [<c06bfb71>] ? syscall_call+0x7/0xb

The problem is that in copy_page_range() we turn lazy mode on,
and then in swap_entry_free() we call swap_count_continued()
which ends up in:

         map = kmap_atomic(page, KM_USER0) + offset;

and then later we touch *map.

Since we are running in batched mode (lazy) we don't actually
set up the PTE mappings and the kmap_atomic is not done
synchronously and ends up trying to dereference a page that has
not been set.

Looking at kmap_atomic_prot_pfn(), it uses
'arch_flush_lazy_mmu_mode' and doing the same in
kmap_atomic_prot() and __kunmap_atomic() makes the problem go
away.

Interestingly, commit b8bcfe997e4615 ("x86/paravirt: remove lazy
mode in interrupts") removed part of this to fix an interrupt
issue - but it went to far and did not consider this scenario.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agox86: Fix "Acer Aspire 1" reboot hang
Peter Chubb [Mon, 5 Dec 2011 13:53:53 +0000]
x86: Fix "Acer Aspire 1" reboot hang

commit 1ef03890969932e9359b9a4c658f7f87771910ac upstream.

Looks like on some Acer Aspire 1s with older bioses, reboot via bios
fails.  It works on my machine, (with BIOS version 0.3310) but
not on some others (BIOS version 0.3309).

There's a log of problems at:

  https://bbs.archlinux.org/viewtopic.php?id=124136

This patch adds a different callback to the reboot quirk table,
to allow rebooting via keybaord controller.

Reported-by: Uroš Vampl <mobile.leecher@gmail.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1323093233-9481-1-git-send-email-anarsoul@gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agox86/mpparse: Account for bus types other than ISA and PCI
Bjorn Helgaas [Sun, 25 Sep 2011 21:29:00 +0000]
x86/mpparse: Account for bus types other than ISA and PCI

commit 9e6866686bdf2dcf3aeb0838076237ede532dcc8 upstream.

In commit f8924e770e04 ("x86: unify mp_bus_info"), the 32-bit
and 64-bit versions of MP_bus_info were rearranged to match each
other better.  Unfortunately it introduced a regression: prior
to that change we used to always set the mp_bus_not_pci bit,
then clear it if we found a PCI bus.  After it, we set
mp_bus_not_pci for ISA buses, clear it for PCI buses, and leave
it alone otherwise.

In the cases of ISA and PCI, there's not much difference.  But
ISA is not the only non-PCI bus, so it's better to always set
mp_bus_not_pci and clear it only for PCI.

Without this change, Dan's Dell PowerEdge 4200 panics on boot
with a log indicating interrupt routing trouble unless the
"noapic" option is supplied.  With this change, the machine
boots reliably without "noapic".

Fixes http://bugs.debian.org/586494

Reported-bisected-and-tested-by: Dan McGrath <troubledaemon@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dan McGrath <troubledaemon@gmail.com>
Cc: Alexey Starikovskiy <aystarik@gmail.com>
[jrnieder@gmail.com: clarified commit message]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Link: http://lkml.kernel.org/r/20111122215000.GA9151@elie.hsd1.il.comcast.net
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agosched, x86: Avoid unnecessary overflow in sched_clock
Salman Qazi [Tue, 15 Nov 2011 22:12:06 +0000]
sched, x86: Avoid unnecessary overflow in sched_clock

commit 4cecf6d401a01d054afc1e5f605bcbfe553cb9b9 upstream.

(Added the missing signed-off-by line)

In hundreds of days, the __cycles_2_ns calculation in sched_clock
has an overflow.  cyc * per_cpu(cyc2ns, cpu) exceeds 64 bits, causing
the final value to become zero.  We can solve this without losing
any precision.

We can decompose TSC into quotient and remainder of division by the
scale factor, and then use this to convert TSC into nanoseconds.

Signed-off-by: Salman Qazi <sqazi@google.com>
Acked-by: John Stultz <johnstul@us.ibm.com>
Reviewed-by: Paul Turner <pjt@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20111115221121.7262.88871.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoxHCI: fix bug in xhci_clear_command_ring()
Andiry Xu [Wed, 30 Nov 2011 08:37:41 +0000]
xHCI: fix bug in xhci_clear_command_ring()

commit 158886cd2cf4599e04f9b7e10cb767f5f39b14f1 upstream.

When system enters suspend, xHCI driver clears command ring by writing zero
to all the TRBs. However, this also writes zero to the Link TRB, and the ring
is mangled. This may cause driver accesses wrong memory address and the
result is unpredicted.

When clear the command ring, keep the last Link TRB intact, only clear its
cycle bit. This should fix the "command ring full" issue reported by Oliver
Neukum.

This should be backported to stable kernels as old as 2.6.37, since the
commit 89821320 "xhci: Fix command ring replay after resume" is merged.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoEHCI : Fix a regression in the ISO scheduler
Matthieu CASTET [Mon, 28 Nov 2011 10:30:22 +0000]
EHCI : Fix a regression in the ISO scheduler

commit e3420901eba65b1c46bed86d360e3a8685d20734 upstream.

Fix a regression that was introduced by commit
811c926c538f7e8d3c08b630dd5844efd7e000f6 (USB: EHCI: fix HUB TT scheduling
issue with iso transfer).

We detect an error if next == start, but this means uframe 0 can't be allocated
anymore for iso transfer...

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoUSB: EHCI: fix HUB TT scheduling issue with iso transfer
Thomas Poussevin [Thu, 27 Oct 2011 16:46:48 +0000]
USB: EHCI: fix HUB TT scheduling issue with iso transfer

commit 811c926c538f7e8d3c08b630dd5844efd7e000f6 upstream.

The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.

The IN iso stream can only start on the first uframe (0-2 for a 165 us)
because of CSPLIT transactions.
For the OUT iso stream there no such restriction. uframe 0-5 are possible.

The idea of this patch is that the first uframe are precious (for IN TT iso
stream) and we should allocate the last uframes first if possible.

For that we reverse the order of uframe allocation (last uframe first).

Here an example :

hid interrupt stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  | 125 |  39 |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

There no place for iso IN stream  (uframe 0-2 are used) and we got "cannot
submit datapipe for urb 0, error -28: not enough bandwidth" error.

With the patch this become.

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  |  0  |  0  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------

iso IN stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  | 125 | 40  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------

Signed-off-by: Matthieu Castet <matthieu.castet@parrot.com>
Signed-off-by: Thomas Poussevin <thomas.poussevin@parrot.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoIB: Fix RCU lockdep splats
Eric Dumazet [Tue, 29 Nov 2011 21:31:23 +0000]
IB: Fix RCU lockdep splats

commit 580da35a31f91a594f3090b7a2c39b85cb051a12 upstream.

Commit f2c31e32b37 ("net: fix NULL dereferences in check_peer_redir()")
forgot to take care of infiniband uses of dst neighbours.

Many thanks to Marc Aurele who provided a nice bug report and feedback.

Reported-by: Marc Aurele La France <tsi@ualberta.ca>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Roland Dreier <roland@purestorage.com>

7 years agoUSB: usb-storage: unusual_devs entry for Kingston DT 101 G2
Qinglin Ye [Wed, 23 Nov 2011 15:39:32 +0000]
USB: usb-storage: unusual_devs entry for Kingston DT 101 G2

commit cec28a5428793b6bc64e56687fb239759d6da74e upstream.

Kingston DT 101 G2 replies a wrong tag while transporting, add an
unusal_devs entry to ignore the tag validation.

Signed-off-by: Qinglin Ye <yestyle@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agousb: option: add SIMCom SIM5218
Veli-Pekka Peltola [Thu, 24 Nov 2011 20:08:56 +0000]
usb: option: add SIMCom SIM5218

commit ec0cd94d881ca89cc9fb61d00d0f4b2b52e605b3 upstream.

Tested with SIM5218EVB-KIT evaluation kit.

Signed-off-by: Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agousb: option: add Huawei E353 controlling interfaces
Dirk Nehring [Thu, 24 Nov 2011 18:22:23 +0000]
usb: option: add Huawei E353 controlling interfaces

commit 46b1848360c8e634e0b063932a1261062fa0f7d6 upstream.

This patch creates the missing controlling devices for the Huawei E353
HSPA+ stick.

Signed-off-by: Dirk Nehring <dnehring@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agousb: ftdi_sio: add PID for Propox ISPcable III
Marcin Kościelnicki [Wed, 30 Nov 2011 16:01:04 +0000]
usb: ftdi_sio: add PID for Propox ISPcable III

commit 307369b0ca06b27b511b61714e335ddfccf19c4f upstream.

Signed-off-by: Marcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoHID: Correct General touch PID
Benjamin Tissoires [Wed, 16 Nov 2011 10:39:52 +0000]
HID: Correct General touch PID

commit b1807719f6acdf18cc4bde3b5400d05d77801494 upstream.

Genera Touch told us that 0001 is their single point device
and 0003 is the multitouch one. Apparently, we made the tests
someone having a prototype, and not the final product.
They said it should be safe to do the switch.

This partially reverts 5572da0 ("HID: hid-mulitouch: add support
for the 'Sensing Win7-TwoFinger'").

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoUSB: whci-hcd: fix endian conversion in qset_clear()
Dan Carpenter [Tue, 22 Nov 2011 07:28:31 +0000]
USB: whci-hcd: fix endian conversion in qset_clear()

commit 8746c83d538cab273d335acb2be226d096f4a5af upstream.

qset->qh.link is an __le64 field and we should be using cpu_to_le64()
to fill it.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agousb: musb: PM: fix context save/restore in suspend/resume path
Kevin Hilman [Wed, 23 Nov 2011 01:18:24 +0000]
usb: musb: PM: fix context save/restore in suspend/resume path

commit 5d193ce8f1fa7c67c7fd7be2c03ef31eed344a4f upstream.

Currently the driver tries to save context in the suspend path, but
will cause an abort if the device is already runtime suspended.  This
happens, for example, if MUSB loaded/compiled-in, in host mode, but no
USB devices are attached.  MUSB will be runtime suspended, but then
attempting a system suspend will crash due to the context save
being attempted while the device is disabled.

On OMAP, as of v3.1, the driver's ->runtime_suspend() callback will be
called late in the suspend path (by the PM domain layer) if the driver
is not already runtime suspended, ensuring a full shutdown.

Therefore, the context save is not needed in the ->suspend() method
since it will be called in the ->runtime_suspend() method anyways
(similarily for resume.)

NOTE: this leaves the suspend/resume methods basically empty (with
      some FIXMEs and comments, but I'll leave it to the maintainers
      to decide whether to remove them.

Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoStaging: comedi: fix signal handling in read and write
Federico Vaga [Sat, 29 Oct 2011 07:47:39 +0000]
Staging: comedi: fix signal handling in read and write

commit 6a9ce6b654e491981f6ef7e214cbd4f63e033848 upstream.

After sleeping on a wait queue, signal_pending(current) should be
checked (not before sleeping).

Acked-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Federico Vaga <federico.vaga@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoStaging: comedi: fix mmap_count
Federico Vaga [Sat, 29 Oct 2011 07:45:39 +0000]
Staging: comedi: fix mmap_count

commit df30b21cb0eed5ba8a8e0cdfeebc66ba8cde821d upstream.

In comedi_fops, mmap_count is decremented at comedi_vm_ops->close but
it is not incremented at comedi_vm_ops->open. This may result in a negative
counter.  The patch introduces the open method to keep the counter
consistent.

The bug was triggerd by this sample code:

        mmap(0, ...., comedi_fd);
        fork();
        exit(0);

Acked-by: Alessandro Rubini <rubini@gnudd.com>
Signed-off-by: Federico Vaga <federico.vaga@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agostaging: comedi: fix oops for USB DAQ devices.
Bernd Porr [Tue, 8 Nov 2011 21:23:03 +0000]
staging: comedi: fix oops for USB DAQ devices.

commit 3ffab428f40849ed5f21bcfd7285bdef7902f9ca upstream.

This fixes kernel oops when an USB DAQ device is plugged out while it's
communicating with the userspace software.

Signed-off-by: Bernd Porr <berndporr@f2s.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agostaging: usbip: bugfix for deadlock
Bart Westgeest [Tue, 1 Nov 2011 19:01:28 +0000]
staging: usbip: bugfix for deadlock

commit 438957f8d4a84daa7fa5be6978ad5897a2e9e5e5 upstream.

Interrupts must be disabled prior to calling usb_hcd_unlink_urb_from_ep.
If interrupts are not disabled, it can potentially lead to a deadlock.
The deadlock is readily reproduceable on a slower (ARM based) device
such as the TI Pandaboard.

Signed-off-by: Bart Westgeest <bart@elbrys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agostaging:rts_pstor:Complete scanning_done variable
wwang [Mon, 31 Oct 2011 07:02:53 +0000]
staging:rts_pstor:Complete scanning_done variable

commit f7364ba04b0961f3a1f978bbe77102606801e35f upstream.

Complete scanning_done variable if rtsx-scan thread created failed.

Signed-off-by: wwang <wei_wang@realsil.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agofirmware: Sigma: Fix endianess issues
Lars-Peter Clausen [Mon, 28 Nov 2011 08:44:16 +0000]
firmware: Sigma: Fix endianess issues

commit bda63586bc5929e97288cdb371bb6456504867ed upstream.

Currently the SigmaDSP firmware loader only works correctly on little-endian
systems. Fix this by using the proper endianess conversion functions.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agofirmware: Sigma: Skip header during CRC generation
Lars-Peter Clausen [Mon, 28 Nov 2011 08:44:15 +0000]
firmware: Sigma: Skip header during CRC generation

commit c56935bdc0a8edf50237d3b0205133a5b0adc604 upstream.

The firmware header is not part of the CRC, so skip it. Otherwise the firmware
will be rejected due to non-matching CRCs.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agofirmware: Sigma: Prevent out of bounds memory access
Lars-Peter Clausen [Mon, 28 Nov 2011 08:44:14 +0000]
firmware: Sigma: Prevent out of bounds memory access

commit 4f718a29fe4908c2cea782f751e9805319684e2b upstream.

The SigmaDSP firmware loader currently does not perform enough boundary size
checks when processing the firmware. As a result it is possible that a
malformed firmware can cause an out of bounds memory access.

This patch adds checks which ensure that both the action header and the payload
are completely inside the firmware data boundaries before processing them.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoASoC: Fix wrong define for AD1836_ADC_WORD_OFFSET
Axel Lin [Tue, 22 Nov 2011 01:46:51 +0000]
ASoC: Fix wrong define for AD1836_ADC_WORD_OFFSET

commit 72531c9434fa884d20cb3c36fcec83752f32fdf4 upstream.

According to the datasheet:
The BIT[5:4] of ADC Control Register 2 is to control the word width.
        00 = 25 Bits
        01 = 20 Bits
        10 = 16 Bits
        11 = Invalid

Thus, the AD1836_ADC_WORD_OFFSET should be defined as 4.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoALSA: hda - Fix S3/S4 problem on machines with VREF-pin mute-LED
Charles Chin [Thu, 1 Dec 2011 10:21:00 +0000]
ALSA: hda - Fix S3/S4 problem on machines with VREF-pin mute-LED

commit 88d686027bb43f585914c77dd363f6e817b42c2a upstream.

The verb command in stac92xx_post_suspend caused the audio to stop
working after resuming from S3 mode on HP laptops with the VREF-pin
mute-LED control.  Removing relevant post_suspend registering.

Although removing D3 on AFG is no optimal solution, the impact should
be small in comparison with the broken S3/S4.

Signed-off-by: Charles Chin <Charles.Chin@idt.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/radeon/kms: add some loop timeouts in pageflip code
Alex Deucher [Mon, 28 Nov 2011 19:49:26 +0000]
drm/radeon/kms: add some loop timeouts in pageflip code

commit f64964796dedca340608fb1075ab6baad5625851 upstream.

Avoid infinite loops waiting for surface updates if a GPU
reset happens while waiting for a page flip.

See:
https://bugs.freedesktop.org/show_bug.cgi?id=43191

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Tested-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/radeon/kms: add some new pci ids
Alex Deucher [Thu, 1 Dec 2011 16:02:11 +0000]
drm/radeon/kms: add some new pci ids

commit 2ed4d9d648cbd4fb1c232a646dbdbdfdd373ca94 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@suse.de>

7 years agoiwlwifi: allow pci_enable_msi fail
Wey-Yi Guy [Fri, 28 Oct 2011 00:19:39 +0000]
iwlwifi: allow pci_enable_msi fail

commit 8a39ef8ba0fa0410d71db8e981e887fe4fdeca88 upstream.

Continue the init process even fail to enable msi

out_iounmap is no longer used, remove it

Reported-by: werner <w.landgraf@ru.ru>
Tested-by: werner <w.landgraf@ru.ru>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agobridge: correct IPv6 checksum after pull
stephen hemminger [Tue, 15 Nov 2011 08:09:14 +0000]
bridge: correct IPv6 checksum after pull

commit fa2da8cdae1dd64f78fc915ca1d1a4a93c71e7cb upstream.

Bridge multicast snooping of ICMPv6 would incorrectly report a checksum problem
when used with Ethernet devices like sky2 that use CHECKSUM_COMPLETE.
When bytes are removed from skb, the computed checksum needs to be adjusted.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Tested-by: Martin Volf <martin.volf.42@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agohugetlb: release pages in the error path of hugetlb_cow()
Hillf Danton [Tue, 15 Nov 2011 22:36:12 +0000]
hugetlb: release pages in the error path of hugetlb_cow()

commit ea4039a34c4c206d015d34a49d0b00868e37db1d upstream.

If we fail to prepare an anon_vma, the {new, old}_page should be released,
or they will leak.

Signed-off-by: Hillf Danton <dhillf@gmail.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoSCSI: Silencing 'killing requests for dead queue'
Hannes Reinecke [Wed, 9 Nov 2011 07:39:24 +0000]
SCSI: Silencing 'killing requests for dead queue'

commit 745718132c3c7cac98a622b610e239dcd5217f71 upstream.

When we tear down a device we try to flush all outstanding
commands in scsi_free_queue(). However the check in
scsi_request_fn() is imperfect as it only signals that
we _might start_ aborting commands, not that we've actually
aborted some.
So move the printk inside the scsi_kill_request function,
this will also give us a hint about which commands are aborted.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoxfs: use doalloc flag in xfs_qm_dqattach_one()
Mitsuo Hayasaka [Thu, 1 Dec 2011 23:27:44 +0000]
xfs: use doalloc flag in xfs_qm_dqattach_one()

commit db3e74b582915d66e10b0c73a62763418f54c340 upstream.

The doalloc arg in xfs_qm_dqattach_one() is a flag that indicates
whether a new area to handle quota information will be allocated
if needed. Originally, it was passed to xfs_qm_dqget(), but has
been removed by the following commit (probably by mistake):

commit 8e9b6e7fa4544ea8a0e030c8987b918509c8ff47
Author: Christoph Hellwig <hch@lst.de>
Date:   Sun Feb 8 21:51:42 2009 +0100

xfs: remove the unused XFS_QMOPT_DQLOCK flag

As the result, xfs_qm_dqget() called from xfs_qm_dqattach_one()
never allocates the new area even if it is needed.

This patch gives the doalloc arg to xfs_qm_dqget() in
xfs_qm_dqattach_one() to fix this problem.

Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Cc: Alex Elder <aelder@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoxfs: Fix possible memory corruption in xfs_readlink
Carlos Maiolino [Thu, 1 Dec 2011 23:27:43 +0000]
xfs: Fix possible memory corruption in xfs_readlink

commit b52a360b2aa1c59ba9970fb0f52bbb093fcc7a24 upstream.

Fixes a possible memory corruption when the link is larger than
MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the
S_ISLNK assert, since the inode mode is checked previously in
xfs_readlink_by_handle() and via VFS.

Updated to address concerns raised by Ben Hutchings about the loose
attention paid to 32- vs 64-bit values, and the lack of handling a
potentially negative pathlen value:
 - Changed type of "pathlen" to be xfs_fsize_t, to match that of
   ip->i_d.di_size
 - Added checking for a negative pathlen to the too-long pathlen
   test, and generalized the message that gets reported in that case
   to reflect the change
As a result, if a negative pathlen were encountered, this function
would return EFSCORRUPTED (and would fail an assertion for a debug
build)--just as would a too-long pathlen.

Signed-off-by: Alex Elder <aelder@sgi.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoxfs: fix buffer flushing during unmount
Christoph Hellwig [Thu, 1 Dec 2011 23:27:42 +0000]
xfs: fix buffer flushing during unmount

commit 87c7bec7fc3377b3873eb3a0f4b603981ea16ebb upstream.

The code to flush buffers in the umount code is a bit iffy: we first
flush all delwri buffers out, but then might be able to queue up a
new one when logging the sb counts.  On a normal shutdown that one
would get flushed out when doing the synchronous superblock write in
xfs_unmountfs_writesb, but we skip that one if the filesystem has
been shut down.

Fix this by moving the delwri list flushing until just before unmounting
the log, and while we're at it also remove the superflous delwri list
and buffer lru flusing for the rt and log device that can never have
cached or delwri buffers.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Amit Sahrawat <amit.sahrawat83@gmail.com>
Tested-by: Amit Sahrawat <amit.sahrawat83@gmail.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Cc: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoxfs: Return -EIO when xfs_vn_getattr() failed
Mitsuo Hayasaka [Thu, 1 Dec 2011 23:27:41 +0000]
xfs: Return -EIO when xfs_vn_getattr() failed

commit ed32201e65e15f3e6955cb84cbb544b08f81e5a5 upstream.

An attribute of inode can be fetched via xfs_vn_getattr() in XFS.
Currently it returns EIO, not negative value, when it failed.  As a
result, the system call returns not negative value even though an
error occured. The stat(2), ls and mv commands cannot handle this
error and do not work correctly.

This patch fixes this bug, and returns -EIO, not EIO when an error
is detected in xfs_vn_getattr().

Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
Cc: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoxfs: avoid direct I/O write vs buffered I/O race
Christoph Hellwig [Thu, 1 Dec 2011 23:27:40 +0000]
xfs: avoid direct I/O write vs buffered I/O race

commit c58cb165bd44de8aaee9755a144136ae743be116 upstream.

Currently a buffered reader or writer can add pages to the pagecache
while we are waiting for the iolock in xfs_file_dio_aio_write.  Prevent
this by re-checking mapping->nrpages after we got the iolock, and if
nessecary upgrade the lock to exclusive mode.  To simplify this a bit
only take the ilock inside of xfs_file_aio_write_checks.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Cc: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoxfs: don't serialise direct IO reads on page cache checks
Dave Chinner [Thu, 1 Dec 2011 23:27:39 +0000]
xfs: don't serialise direct IO reads on page cache checks

commit 0c38a2512df272b14ef4238b476a2e4f70da1479 upstream.

There is no need to grab the i_mutex of the IO lock in exclusive
mode if we don't need to invalidate the page cache. Taking these
locks on every direct IO effective serialises them as taking the IO
lock in exclusive mode has to wait for all shared holders to drop
the lock. That only happens when IO is complete, so effective it
prevents dispatch of concurrent direct IO reads to the same inode.

Fix this by taking the IO lock shared to check the page cache state,
and only then drop it and take the IO lock exclusively if there is
work to be done. Hence for the normal direct IO case, no exclusive
locking will occur.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Joern Engel <joern@logfs.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
Cc: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agomac80211: fix race between the AGG SM and the Tx data path
Emmanuel Grumbach [Sun, 27 Nov 2011 13:29:44 +0000]
mac80211: fix race between the AGG SM and the Tx data path

commit 2a1e0fd175dcfd72096ba9291d31e3b1b5342e60 upstream.

When a packet is supposed to sent be as an a-MPDU, mac80211 sets
IEEE80211_TX_CTL_AMPDU to let the driver know. On the other
hand, mac80211 configures the driver for aggregration with the
ampdu_action callback.
There is race between these two mechanisms since the following
scenario can occur when the BA agreement is torn down:

Tx softIRQ   drv configuration
========== =================

check OPERATIONAL bit
Set the TX_CTL_AMPDU bit in the packet

clear OPERATIONAL bit
stop Tx AGG
Pass Tx packet to the driver.

In that case the driver would get a packet with TX_CTL_AMPDU set
although it has already been notified that the BA session has been
torn down.

To fix this, we need to synchronize all the Qdisc activity after we
cleared the OPERATIONAL bit. After that step, all the following
packets will be buffered until the driver reports it is ready to get
new packets for this RA / TID. This buffering allows not to run into
another race that would send packets with TX_CTL_AMPDU unset while
the driver hasn't been requested to tear down the BA session yet.

This race occurs in practice and iwlwifi complains with a WARN_ON
when it happens.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agomac80211: don't stop a single aggregation session twice
Johannes Berg [Thu, 24 Nov 2011 19:06:14 +0000]
mac80211: don't stop a single aggregation session twice

commit 24f50a9d165745fd0701c6e089d35f58a229ea69 upstream.

Nikolay noticed (by code review) that mac80211 can
attempt to stop an aggregation session while it is
already being stopped. So to fix it, check whether
stop is already being done and bail out if so.

Also move setting the STOPPING state into the lock
so things are properly atomic.

Reported-by: Nikolay Martynov <mar.kolya@gmail.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@suse.de>

7 years agocfg80211: fix regulatory NULL dereference
Johannes Berg [Mon, 21 Nov 2011 09:44:00 +0000]
cfg80211: fix regulatory NULL dereference

commit de3584bd62d87b4c250129fbc46ca52c80330add upstream.

By the time userspace returns with a response to
the regulatory domain request, the wiphy causing
the request might have gone away. If this is so,
reject the update but mark the request as having
been processed anyway.

Cc: Luis R. Rodriguez <lrodriguez@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@suse.de>

7 years agonl80211: fix MAC address validation
Eliad Peller [Thu, 24 Nov 2011 16:13:56 +0000]
nl80211: fix MAC address validation

commit e007b857e88097c96c45620bf3b04a4e309053d1 upstream.

MAC addresses have a fixed length. The current
policy allows passing < ETH_ALEN bytes, which
might result in reading beyond the buffer.

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agort2x00: Fix efuse EEPROM reading on PPC32.
Gertjan van Wingerde [Wed, 16 Nov 2011 22:16:15 +0000]
rt2x00: Fix efuse EEPROM reading on PPC32.

commit 68fa64ef606bcee688fce46d07aa68f175070156 upstream.

Fix __le32 to __le16 conversion of the first word of an 8-word block
of EEPROM read via the efuse method.

Reported-and-tested-by: Ingvar Hagelund <ingvar@redpill-linpro.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agop54spi: Fix workqueue deadlock
Michael Büsch [Wed, 16 Nov 2011 22:55:46 +0000]
p54spi: Fix workqueue deadlock

commit 2d1618170eb493d18f66f2ac03775409a6fb97c6 upstream.

priv->work must not be synced while priv->mutex is locked, because
the mutex is taken in the work handler.
Move cancel_work_sync down to after the device shutdown code.
This is safe, because the work handler checks fw_state and bails out
early in case of a race.

Signed-off-by: Michael Buesch <m@bues.ch>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agop54spi: Add missing spin_lock_init
Michael Büsch [Wed, 16 Nov 2011 22:48:31 +0000]
p54spi: Add missing spin_lock_init

commit 32d3a3922d617a5a685a5e2d24b20d0e88f192a9 upstream.

The tx_lock is not initialized properly. Add spin_lock_init().

Signed-off-by: Michael Buesch <m@bues.ch>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoclocksource: Avoid selecting mult values that might overflow when adjusted
John Stultz [Mon, 31 Oct 2011 21:06:35 +0000]
clocksource: Avoid selecting mult values that might overflow when adjusted

commit d65670a78cdbfae94f20a9e05ec705871d7cdf2b upstream.

For some frequencies, the clocks_calc_mult_shift() function will
unfortunately select mult values very close to 0xffffffff.  This
has the potential to overflow when NTP adjusts the clock, adding
to the mult value.

This patch adds a clocksource.maxadj value, which provides
an approximation of an 11% adjustment(NTP limits adjustments to
500ppm and the tick adjustment is limited to 10%), which could
be made to the clocksource.mult value. This is then used to both
check that the current mult value won't overflow/underflow, as
well as warning us if the timekeeping_adjust() code pushes over
that 11% boundary.

v2: Fix max_adjustment calculation, and improve WARN_ONCE
messages.

v3: Don't warn before maxadj has actually been set

CC: Yong Zhang <yong.zhang0@gmail.com>
CC: David Daney <ddaney.cavm@gmail.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Chen Jie <chenj@lemote.com>
CC: zhangfx <zhangfx@lemote.com>
Reported-by: Chen Jie <chenj@lemote.com>
Reported-by: zhangfx <zhangfx@lemote.com>
Tested-by: Yong Zhang <yong.zhang0@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agohrtimer: Fix extra wakeups from __remove_hrtimer()
Jeff Ohlstein [Fri, 18 Nov 2011 23:47:10 +0000]
hrtimer: Fix extra wakeups from __remove_hrtimer()

commit 27c9cd7e601632b3794e1c3344d37b86917ffb43 upstream.

__remove_hrtimer() attempts to reprogram the clockevent device when
the timer being removed is the next to expire. However,
__remove_hrtimer() reprograms the clockevent *before* removing the
timer from the timerqueue and thus when hrtimer_force_reprogram()
finds the next timer to expire it finds the timer we're trying to
remove.

This is especially noticeable when the system switches to NOHz mode
and the system tick is removed. The timer tick is removed from the
system but the clockevent is programmed to wakeup in another HZ
anyway.

Silence the extra wakeup by removing the timer from the timerqueue
before calling hrtimer_force_reprogram() so that we actually program
the clockevent for the next timer to expire.

This was broken by 998adc3 "hrtimers: Convert hrtimers to use
timerlist infrastructure".

Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>
Link: http://lkml.kernel.org/r/1321660030-8520-1-git-send-email-johlstei@codeaurora.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agotimekeeping: add arch_offset hook to ktime_get functions
Hector Palacios [Mon, 14 Nov 2011 10:15:25 +0000]
timekeeping: add arch_offset hook to ktime_get functions

commit d004e024058a0eaca097513ce62cbcf978913e0a upstream.

ktime_get and ktime_get_ts were calling timekeeping_get_ns()
but later they were not calling arch_gettimeoffset() so architectures
using this mechanism returned 0 ns when calling these functions.

This happened for example when running Busybox's ping which calls
syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts) which eventually
calls ktime_get. As a result the returned ping travel time was zero.

Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agocgroup_freezer: fix freezing groups with stopped tasks
Michal Hocko [Tue, 22 Nov 2011 15:44:47 +0000]
cgroup_freezer: fix freezing groups with stopped tasks

commit 884a45d964dd395eda945842afff5e16bcaedf56 upstream.

2d3cbf8b (cgroup_freezer: update_freezer_state() does incorrect state
transitions) removed is_task_frozen_enough and replaced it with a simple
frozen call. This, however, breaks freezing for a group with stopped tasks
because those cannot be frozen and so the group remains in CGROUP_FREEZING
state (update_if_frozen doesn't count stopped tasks) and never reaches
CGROUP_FROZEN.

Let's add is_task_frozen_enough back and use it at the original locations
(update_if_frozen and try_to_freeze_cgroup). Semantically we consider
stopped tasks as frozen enough so we should consider both cases when
testing frozen tasks.

Testcase:
mkdir /dev/freezer
mount -t cgroup -o freezer none /dev/freezer
mkdir /dev/freezer/foo
sleep 1h &
pid=$!
kill -STOP $pid
echo $pid > /dev/freezer/foo/tasks
echo FROZEN > /dev/freezer/foo/freezer.state
while true
do
cat /dev/freezer/foo/freezer.state
[ "`cat /dev/freezer/foo/freezer.state`" = "FROZEN" ] && break
sleep 1
done
echo OK

Signed-off-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Li Zefan <lizf@cn.fujitsu.com>
Cc: Tomasz Buchert <tomasz.buchert@inria.fr>
Cc: Paul Menage <paul@paulmenage.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoregulator: twl: fix twl4030 support for smps regulators
Tero Kristo [Mon, 28 Nov 2011 14:53:19 +0000]
regulator: twl: fix twl4030 support for smps regulators

commit ba305e31e88ea5c2f598ff9fbc5424711a429e30 upstream.

SMPS regulator voltage control differs from the one of the LDO ones.
Current TWL code was using LDO regulator ops for controlling the SMPS
regulators, which fails. This was fixed fixed by adding separate
regulator type which uses correct logic and calculations for the
voltage levels.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoregulator: aat2870: Fix the logic of checking if no id is matched in aat2870_get_regu...
Axel Lin [Mon, 28 Nov 2011 06:06:31 +0000]
regulator: aat2870: Fix the logic of checking if no id is matched in aat2870_get_regulator

commit d4d6373c1109b11c8118340be97ae31b8f94d66a upstream.

In current implementation, the pointer ri is not NULL if no id is matched.
Fix it by checking i == ARRAY_SIZE(aat2870_regulators) if no id is matched.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agogenirq: fix regression in irqfixup, irqpoll
Edward Donovan [Mon, 28 Nov 2011 04:07:34 +0000]
genirq: fix regression in irqfixup, irqpoll

commit 52553ddffad76ccf192d4dd9ce88d5818f57f62a upstream.

Commit fa27271bc8d2("genirq: Fixup poll handling") introduced a
regression that broke irqfixup/irqpoll for some hardware configurations.

Amidst reorganizing 'try_one_irq', that patch removed a test that
checked for 'action->handler' returning IRQ_HANDLED, before acting on
the interrupt.  Restoring this test back returns the functionality lost
since 2.6.39.  In the current set of tests, after 'action' is set, it
must precede '!action->next' to take effect.

With this and my previous patch to irq/spurious.c, c75d720fca8a, all
IRQ regressions that I have encountered are fixed.

Signed-off-by: Edward Donovan <edward.donovan@numble.net>
Reported-and-tested-by: Rogério Brito <rbrito@ime.usp.br>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agortlwifi: fix lps_lock deadlock
Stanislaw Gruszka [Mon, 28 Nov 2011 09:33:40 +0000]
rtlwifi: fix lps_lock deadlock

commit e55b32c110b025ce07b40227f620e99700bf8741 upstream.

rtl_lps_leave can be called from interrupt context, so we have to
disable interrupts when taking lps_lock.

Below is full lockdep info about deadlock:

[   93.815269] =================================
[   93.815390] [ INFO: inconsistent lock state ]
[   93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1
[   93.815556] ---------------------------------
[   93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   93.815832]  (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.815947] {SOFTIRQ-ON-W} state was registered at:
[   93.815947]   [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c
[   93.815947]   [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
[   93.815947]   [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
[   93.815947]   [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi]
[   93.815947]   [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi]
[   93.815947]   [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211]
[   93.815947]   [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211]
[   93.815947]   [<ffffffff81075aa5>] process_one_work+0x205/0x3e7
[   93.815947]   [<ffffffff81076753>] worker_thread+0xda/0x15d
[   93.815947]   [<ffffffff8107a119>] kthread+0xa8/0xb0
[   93.815947]   [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10
[   93.815947] irq event stamp: 547822
[   93.815947] hardirqs last  enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61
[   93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e
[   93.815947] softirqs last  enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15
[   93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30
[   93.815947]
[   93.815947] other info that might help us debug this:
[   93.815947]  Possible unsafe locking scenario:
[   93.815947]
[   93.815947]        CPU0
[   93.815947]        ----
[   93.815947]   lock(&(&rtlpriv->locks.lps_lock)->rlock);
[   93.815947]   <Interrupt>
[   93.815947]     lock(&(&rtlpriv->locks.lps_lock)->rlock);
[   93.815947]
[   93.815947]  *** DEADLOCK ***
[   93.815947]
[   93.815947] no locks held by swapper/0.
[   93.815947]
[   93.815947] stack backtrace:
[   93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1
[   93.815947] Call Trace:
[   93.815947]  <IRQ>  [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8
[   93.815947]  [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49
[   93.815947]  [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0
[   93.815947]  [<ffffffff8108dc8a>] mark_lock+0x106/0x220
[   93.815947]  [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c
[   93.815947]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
[   93.830125]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
[   93.830125]  [<ffffffff81080181>] ? sched_clock_local+0x12/0x75
[   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
[   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
[   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d
[   93.830125]  [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi]
[   93.830125]  [<ffffffff8106281f>] tasklet_action+0x8d/0xee
[   93.830125]  [<ffffffff810629ce>] __do_softirq+0x112/0x25a
[   93.830125]  [<ffffffff814f327c>] call_softirq+0x1c/0x30
[   93.830125]  [<ffffffff81010bf6>] do_softirq+0x4b/0xa1
[   93.830125]  [<ffffffff81062d7d>] irq_exit+0x5d/0xcf
[   93.830125]  [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5
[   93.830125]  [<ffffffff814ea533>] common_interrupt+0x73/0x73
[   93.830125]  <EOI>  [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf
[   93.830125]  [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c
[   93.830125]  [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c
[   93.830125]  [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe
[   93.830125]  [<ffffffff8100e2ef>] cpu_idle+0xab/0x101
[   93.830125]  [<ffffffff814c6373>] rest_init+0xd7/0xde
[   93.830125]  [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c
[   93.830125]  [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea
[   93.830125]  [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3
[   93.830125]  [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140
[   93.830125]  [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111

Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=755154

Reported-by: vjain02@students.poly.edu
Reported-and-tested-by: Oliver Paukstadt <pstadt@sourcentral.org>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoext4: fix racy use-after-free in ext4_end_io_dio()
Tejun Heo [Fri, 25 Nov 2011 00:22:24 +0000]
ext4: fix racy use-after-free in ext4_end_io_dio()

commit 4c81f045c0bd2cbb78cc6446a4cd98038fe11a2e upstream.

ext4_end_io_dio() queues io_end->work and then clears iocb->private;
however, io_end->work calls aio_complete() which frees the iocb
object.  If that slab object gets reallocated, then ext4_end_io_dio()
can end up clearing someone else's iocb->private, this use-after-free
can cause a leak of a struct ext4_io_end_t structure.

Detected and tested with slab poisoning.

[ Note: Can also reproduce using 12 fio's against 12 file systems with the
  following configuration file:

  [global]
  direct=1
  ioengine=libaio
  iodepth=1
  bs=4k
  ba=4k
  size=128m

  [create]
  filename=${TESTDIR}
  rw=write

  -- tytso ]

Google-Bug-Id: 5354697
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Kent Overstreet <koverstreet@google.com>
Tested-by: Kent Overstreet <koverstreet@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoSUNRPC: Ensure we return EAGAIN in xs_nospace if congestion is cleared
Trond Myklebust [Tue, 22 Nov 2011 12:44:28 +0000]
SUNRPC: Ensure we return EAGAIN in xs_nospace if congestion is cleared

commit 24ca9a847791fd53d9b217330b15f3c285827a18 upstream.

By returning '0' instead of 'EAGAIN' when the tests in xs_nospace() fail
to find evidence of socket congestion, we are making the RPC engine believe
that the message was incorrectly sent and so it disconnects the socket
instead of just retrying.

The bug appears to have been introduced by commit
5e3771ce2d6a69e10fcc870cdf226d121d868491 (SUNRPC: Ensure that xs_nospace
return values are propagated).

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoASoC: Ensure WM8731 register cache is synced when resuming from disabled
Mark Brown [Mon, 21 Nov 2011 11:55:41 +0000]
ASoC: Ensure WM8731 register cache is synced when resuming from disabled

commit ed3e80c4c991a52f9fce3421536a78e331ae0949 upstream.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoASoC: wm8753: Skip noop reconfiguration of DAI mode
Timo Juhani Lindfors [Thu, 17 Nov 2011 00:52:50 +0000]
ASoC: wm8753: Skip noop reconfiguration of DAI mode

commit 2391a0e06789a3f1718dee30b282562f7ed28c87 upstream.

This patch makes it possible to set DAI mode to its currently applied
value even if codec is active. This is necessary to allow

aplay -t raw -r 44100 -f S16_LE -c 2 < /dev/urandom &
alsactl store -f backup.state
alsactl restore -f backup.state

to work without returning errors. This patch is based on a patch sent
by Klaus Kurzmann <mok@fluxnetz.de>.

Signed-off-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoASoC: fsl_ssi: properly initialize the sysfs attribute object
Timur Tabi [Mon, 14 Nov 2011 22:35:26 +0000]
ASoC: fsl_ssi: properly initialize the sysfs attribute object

commit 0f768a7235d3dfb6f4833030a95a06419df089cb upstream.

Commit 6992f533 ("sysfs: Use one lockdep class per sysfs attribute")
requires 'struct attribute' objects to be initialized with sysfs_attr_init().

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoASoC: sta32x: preserve coefficient RAM
Johannes Stezenbach [Mon, 14 Nov 2011 16:23:16 +0000]
ASoC: sta32x: preserve coefficient RAM

commit 54dc6cabe684375b3cf549c7b0545613d694aba8 upstream.

The coefficient RAM must be saved in a shadow so it can
be restored when the codec is powered on using
regulator_bulk_enable().

Signed-off-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoALSA: hda/realtek - Fix missing inits of item indices for auto-mic
Takashi Iwai [Wed, 23 Nov 2011 06:38:59 +0000]
ALSA: hda/realtek - Fix missing inits of item indices for auto-mic

commit 6759dc323826c2c806c998cd93945c5476688dd2 upstream.

When the imux entries are rebuilt in alc_rebuild_imux_for_auto_mic(),
the initialization of index field is missing.  It may work without it
casually when the original imux was created by the auto-parser, but
it's definitely broken in the case of static configs where no imux was
parsed beforehand.  Because of this, the auto-mic switching doesn't
work properly on some model options.

This patch adds the missing initialization of index field.

Reported-by: Dmitry Nezhevenko <dion@inhex.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoALSA: lx6464es - fix device communication via command bus
Tim Blechmann [Tue, 22 Nov 2011 10:15:45 +0000]
ALSA: lx6464es - fix device communication via command bus

commit a29878553a9a7b4c06f93c7e383527cf014d4ceb upstream.

commit 6175ddf06b6172046a329e3abfd9c901a43efd2e optimized the mem*io
functions that have been used to send commands to the device. these
optimizations somehow corrupted the communication with the lx6464es,
that resulted the device to be unusable with kernels after 2.6.33.

this patch emulates the memcpy_*_io functions via a loop to avoid these
problems.

Signed-off-by: Tim Blechmann <tim@klingt.org>
LKML-Reference: <4ECB5257.4040600@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoALSA: hda - Fix jack-detection control of VT1708
Takashi Iwai [Thu, 24 Nov 2011 15:33:09 +0000]
ALSA: hda - Fix jack-detection control of VT1708

commit 187d333edc0a8e1bb507900ce89853ffe3bd2c84 upstream.

VT1708 has no support for unsolicited events per jack-plug, the driver
implements the workq for polling the jack-detection.  The mixer element
"Jack Detect" was supposed to control this behavior on/off, but this
doesn't work properly as is now.  The workq is always started and the
HP automute is always enabled.

This patch fixes the jack-detect control behavior by triggering / stopping
the work appropriately at the state change.  Also the work checks the
internal state to continue scheduling or not.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoARM: 7161/1: errata: no automatic store buffer drain
Will Deacon [Mon, 14 Nov 2011 16:24:58 +0000]
ARM: 7161/1: errata: no automatic store buffer drain

commit 11ed0ba1754841316d4095478944300acf19acc3 upstream.

This patch implements a workaround for PL310 erratum 769419. On
revisions of the PL310 prior to r3p2, the Store Buffer does not
automatically drain. This can cause normal, non-cacheable writes to be
retained when the memory system is idle, leading to suboptimal I/O
performance for drivers using coherent DMA.

This patch adds an optional wmb() call to the cpu_idle loop. On systems
with an outer cache, this causes an explicit flush of the store buffer.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoARM: OMAP: PM: only register TWL with voltage layer when device is present
Kevin Hilman [Wed, 23 Nov 2011 22:43:01 +0000]
ARM: OMAP: PM: only register TWL with voltage layer when device is present

commit 46232a3622c6e33605906ee6690dfef372925f53 upstream.

Current code registers voltage layer details for TWL PMIC even when a TWL
has not been registered.  Fix this to only register the TWL with voltage
layer when the TWL PMIC is initialized by board-level code.

Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoARM: OMAP2: select ARM_AMBA if OMAP3_EMU is defined
Ming Lei [Wed, 23 Nov 2011 22:44:50 +0000]
ARM: OMAP2: select ARM_AMBA if OMAP3_EMU is defined

commit a8a6565c7615cab3608d75af95b5c8a3522cd7c4 upstream.

This patch selects ARM_AMBA if OMAP3_EMU is defined because
OC_ETM depends on ARM_AMBA, so fix the link failure[1].

[1],
arch/arm/kernel/built-in.o: In function `etm_remove':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined
reference to `amba_release_regions'
arch/arm/kernel/built-in.o: In function `etb_remove':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined
reference to `amba_release_regions'
arch/arm/kernel/built-in.o: In function `etm_init':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined
reference to `amba_driver_register'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined
reference to `amba_driver_register'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined
reference to `amba_driver_unregister'
arch/arm/kernel/built-in.o: In function `etm_probe':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined
reference to `amba_request_regions'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined
reference to `amba_release_regions'
arch/arm/kernel/built-in.o: In function `etb_probe':
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined
reference to `amba_request_regions'
/home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined
reference to `amba_release_regions'
arch/arm/mach-omap2/built-in.o: In function `emu_init':
/home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62:
undefined reference to `amba_device_register'
/home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63:
undefined reference to `amba_device_register'
make: *** [.tmp_vmlinux1] Error 1
making modules

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs
sricharan [Wed, 23 Nov 2011 22:35:07 +0000]
ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs

commit cc1b0765da6078b906772b79ff211b88cc0ae958 upstream.

The address spaces, irqs and dma reqs count APIs return the
number of corresponding entries in a hwmod including a additional
null value or a -1 terminator in the structure introduced recently.
More information here:

212738a4: omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs
  arrays

78183f3f: omap_hwmod: use a null structure record to terminate
  omap_hwmod_addr_space arrays

bc614958: omap_hwmod: use a terminator record with omap_hwmod_dma_info
  arrays

The issue with irqs and dma info was originally reported by Benoit Cousson.

The devices which have multiple hwmods and use device_build_ss are
broken with this, as their resources are populated with a extra null
value, subsequently the probe fails. So fix the API not to include
the array terminator in the count.

Reported-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimar@ti.com>
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoARM: OMAP: smartreflex: fix IRQ handling bug
Felipe Balbi [Wed, 23 Nov 2011 22:43:37 +0000]
ARM: OMAP: smartreflex: fix IRQ handling bug

commit 5a4f1844c2ba21f804d7729306d9b16eaeb724a8 upstream.

Fix a bug which has been on this driver since
it was added by the original commit 984aa6db
which would never clear IRQSTATUS bits.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoarm: mx28: fix bit operation in clock setting
Wolfram Sang [Sat, 10 Sep 2011 10:26:07 +0000]
arm: mx28: fix bit operation in clock setting

commit c2735391fbc68feae10d6d14e60956c8106e725f upstream.

reg | (1 << clk->enable_shift) always evaluates to true. Switch it
to & which makes much more sense. Same fix as 13be9f00 (ARM i.MX28: fix
bit operation) at a different location.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoARM: pxa: fix inconsistent CONFIG_USB_PXA27X
Haojian Zhuang [Wed, 9 Nov 2011 23:13:07 +0000]
ARM: pxa: fix inconsistent CONFIG_USB_PXA27X

commit c0a39151a4055332897cba615623d3de2f3896df upstream.

Since CONFIG_USB_GADGET_PXA27X and other macros are renamed to
CONFIG_USB_PXA27X. Update them in arch/arm/mach-pxa and arch/arm/configs
to keep consistent.

Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoviafb: correct sync polarity for OLPC DCON
Daniel Drake [Mon, 21 Nov 2011 15:05:56 +0000]
viafb: correct sync polarity for OLPC DCON

commit a32839696a8eef813a1aff604fbad9a32dff6c95 upstream.

While the OLPC display appears to be able to handle either positive
or negative sync, the Display Controller only recognises positive sync.

This brings viafb (for XO-1.5) in line with lxfb (for XO-1) and
fixes a recent regression where the XO-1.5 DCON could no longer be
frozen. Thanks to Florian Tobias Schandinat for helping identify
the fix.

Test case: from a vt,
echo 1 > /sys/devices/platform/dcon/freeze
should cause the current screen contents to freeze, rather than garbage being
displayed.

Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/radeon/kms: fix up gpio i2c mask bits for r4xx
Alex Deucher [Mon, 14 Nov 2011 19:32:01 +0000]
drm/radeon/kms: fix up gpio i2c mask bits for r4xx

commit 6c47e5c23aa2a7c54ad7ac13af4bd56cd9e703bf upstream.

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoPCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs
Bjorn Helgaas [Tue, 23 Aug 2011 16:16:43 +0000]
PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs

commit 4cac2eb158c6da0c761689345c6cc5df788a6292 upstream.

Previously we claimed device ID 0x7450, regardless of the vendor, which is
clearly wrong.  Now we'll claim that device ID only for AMD.

I suspect this was just a typo in the original code, but it's possible this
change will break shpchp on non-7450 AMD bridges.  If so, we'll have to fix
them as we find them.

Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
Reported-by: Ralf Jung <ralfjung-e@gmx.de>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/i915: Fix inconsistent backlight level during disabled
Takashi Iwai [Wed, 16 Nov 2011 09:58:03 +0000]
drm/i915: Fix inconsistent backlight level during disabled

commit 04b38670cf46c096705f24e92a8747d1ab89e53c upstream.

When the brightness property is inquired while the backlight is disabled,
the driver returns a wrong value (zero) because it probes the value after
the backlight was turned off.  This caused a black screen even after the
backlight is enabled again.  It should return the internal backlight_level
instead, so that it won't be influenced by the backlight-enable state.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=41926
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652

Tested-by: Kamal Mostafa <kamal@canonical.com>
Cc: Alex Davis <alex14641@yahoo.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/i915: Turn on another required clock gating bit on gen6.
Eric Anholt [Tue, 8 Nov 2011 00:07:05 +0000]
drm/i915: Turn on another required clock gating bit on gen6.

commit 9ca1d10d748e56964de95e3ed80211b192f56cf4 upstream.

Unlike the previous one, I don't have known testcases it fixes.  I'd
rather not go through the same debug cycle on whatever testcases those
might be.

Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/i915: Turn on a required 3D clock gating bit on Sandybridge.
Eric Anholt [Tue, 8 Nov 2011 00:07:04 +0000]
drm/i915: Turn on a required 3D clock gating bit on Sandybridge.

commit 406478dc911e16677fbd9c84d1d50cdffbc031ab upstream.

Fixes rendering failures in Unigine Tropics and Sanctuary and the mesa
"fire" demo.

Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/i915: Ivybridge still has fences!
Daniel Vetter [Sun, 9 Oct 2011 19:52:01 +0000]
drm/i915: Ivybridge still has fences!

commit 775d17b6ca4357048f36c22151335addfe15db4b upstream.

So don't forget to restore them on resume and dump them into
the error state.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm/radeon/kms: fix up gpio i2c mask bits for r4xx for real
Alex Deucher [Mon, 21 Nov 2011 17:10:14 +0000]
drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real

commit d724502a9d7a46f4a56a1663b1f50d2dc9d1ef40 upstream.

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

I missed this part the first time through.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agodrm: integer overflow in drm_mode_dirtyfb_ioctl()
Xi Wang [Wed, 23 Nov 2011 06:12:01 +0000]
drm: integer overflow in drm_mode_dirtyfb_ioctl()

commit a5cd335165e31db9dbab636fd29895d41da55dd2 upstream.

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.

Reported-by: Haogang Chen <haogangchen@gmail.com>
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agocrypto: mv_cesa - fix hashing of chunks > 1920 bytes
Phil Sutter [Wed, 16 Nov 2011 17:28:01 +0000]
crypto: mv_cesa - fix hashing of chunks > 1920 bytes

commit 274252862f386b7868f35bf5ceaa5391a8ccfdf3 upstream.

This was broken by commit 7759995c75ae0cbd4c861582908449f6b6208e7a (yes,
myself). The basic problem here is since the digest state is only saved
after the last chunk, the state array is only valid when handling the
first chunk of the next buffer. Broken since linux-3.0.

Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoeCryptfs: Extend array bounds for all filename chars
Tyler Hicks [Wed, 23 Nov 2011 17:31:24 +0000]
eCryptfs: Extend array bounds for all filename chars

commit 0f751e641a71157aa584c2a2e22fda52b52b8a56 upstream.

From mhalcrow's original commit message:

    Characters with ASCII values greater than the size of
    filename_rev_map[] are valid filename characters.
    ecryptfs_decode_from_filename() will access kernel memory beyond
    that array, and ecryptfs_parse_tag_70_packet() will then decrypt
    those characters. The attacker, using the FNEK of the crafted file,
    can then re-encrypt the characters to reveal the kernel memory past
    the end of the filename_rev_map[] array. I expect low security
    impact since this array is statically allocated in the text area,
    and the amount of memory past the array that is accessible is
    limited by the largest possible ASCII filename character.

This patch solves the issue reported by mhalcrow but with an
implementation suggested by Linus to simply extend the length of
filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
0x00, which is how invalid characters less than 0x7A were previously
being handled.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoi2c-algo-bit: Generate correct i2c address sequence for 10-bit target
Jeffrey (Sheng-Hui) Chu [Wed, 23 Nov 2011 10:33:07 +0000]
i2c-algo-bit: Generate correct i2c address sequence for 10-bit target

commit cc6bcf7d2ec2234e7b41770185e4dc826390185e upstream.

The wrong bits were put on the wire, fix that.

This fixes kernel bug #42562.

Signed-off-by: Sheng-Hui J. Chu <jeffchu@broadcom.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoeCryptfs: Flush file in vma close
Tyler Hicks [Mon, 21 Nov 2011 23:31:29 +0000]
eCryptfs: Flush file in vma close

commit 32001d6fe9ac6b0423e674a3093aa56740849f3b upstream.

Dirty pages weren't being written back when an mmap'ed eCryptfs file was
closed before the mapping was unmapped. Since f_ops->flush() is not
called by the munmap() path, the lower file was simply being released.
This patch flushes the eCryptfs file in the vm_ops->close() path.

https://launchpad.net/bugs/870326

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoeCryptfs: Prevent file create race condition
Tyler Hicks [Mon, 21 Nov 2011 23:31:02 +0000]
eCryptfs: Prevent file create race condition

commit b59db43ad4434519feb338eacb01d77eb50825c5 upstream.

The file creation path prematurely called d_instantiate() and
unlock_new_inode() before the eCryptfs inode info was fully
allocated and initialized and before the eCryptfs metadata was written
to the lower file.

This could result in race conditions in subsequent file and inode
operations leading to unexpected error conditions or a null pointer
dereference while attempting to use the unallocated memory.

https://launchpad.net/bugs/813146

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoLinux 3.1.4
Greg Kroah-Hartman [Mon, 28 Nov 2011 22:48:14 +0000]
Linux 3.1.4

7 years agoRevert "USB: EHCI: fix HUB TT scheduling issue with iso transfer"
Greg Kroah-Hartman [Mon, 28 Nov 2011 22:40:10 +0000]
Revert "USB: EHCI: fix HUB TT scheduling issue with iso transfer"

This reverts commit f0cc710a6dec5b808a6f13f1f8853c094fce5f12.

Cc: Matthieu Castet <matthieu.castet@parrot.com>
Cc: Thomas Poussevin <thomas.poussevin@parrot.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agoLinux 3.1.3
Greg Kroah-Hartman [Sat, 26 Nov 2011 17:08:57 +0000]
Linux 3.1.3

7 years agovmscan: fix shrinker callback bug in fs/super.c
Mikulas Patocka [Tue, 1 Nov 2011 00:08:57 +0000]
vmscan: fix shrinker callback bug in fs/super.c

commit 09f363c7363eb10cfb4b82094bd7064e5608258b upstream.

The callback must not return -1 when nr_to_scan is zero. Fix the bug in
fs/super.c and add this requirement to the callback specification.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

7 years agobatman-adv: unify hash_entry field position in tt_local/global_entry
Antonio Quartulli [Fri, 21 Oct 2011 22:55:39 +0000]
batman-adv: unify hash_entry field position in tt_local/global_entry

commit 93840ac40bb0d0f177ef8af74e64671be67e8c37 upstream.

Function tt_response_fill_table() actually uses a tt_local_entry pointer to
iterate either over the local or the global table entries (it depends on the
what hash table is passed as argument). To iterate over such entries the
hlist_for_each_entry_rcu() macro has to access their "hash_entry" field which
MUST be at the same position in both the tt_global/local_entry structures.

Reported-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>