10 years agointel_idle: enable IVB Xeon support
Ben Hutchings [Sun, 2 Dec 2012 13:14:30 +0000 (13:14 +0000)]
intel_idle: enable IVB Xeon support

commit 23795e580cad5d6b73d47d51b9074ce3e58bf334 upstream.

IVB Xeon currently shares the same parameters IVB client.

For 3.2, add model number to the switch in intel_idle_probe(), as
there is no device ID table.

Signed-off-by: Ben Hutchings <>
10 years agointel_idle: initial IVB support
Len Brown [Fri, 1 Jun 2012 23:45:32 +0000 (19:45 -0400)]
intel_idle: initial IVB support

commit 6edab08c24f9141d69cfa4683a0a027d86ab303e upstream.

From an OS point of view, IVB looks like SNB, but quicker.

Signed-off-by: Len Brown <>
[bwh: Backported to 3.2: add model number to the switch in
 intel_idle_probe(), as there is no device ID table]
Signed-off-by: Ben Hutchings <>
10 years agoworkqueue: exit rescuer_thread() as TASK_RUNNING
Mike Galbraith [Wed, 28 Nov 2012 06:17:18 +0000 (07:17 +0100)]
workqueue: exit rescuer_thread() as TASK_RUNNING

commit 412d32e6c98527078779e5b515823b2810e40324 upstream.

A rescue thread exiting TASK_INTERRUPTIBLE can lead to a task scheduling
off, never to be seen again.  In the case where this occurred, an exiting
thread hit reiserfs homebrew conditional resched while holding a mutex,
bringing the box to its knees.

PID: 18105  TASK: ffff8807fd412180  CPU: 5   COMMAND: "kdmflush"
 #0 [ffff8808157e7670] schedule at ffffffff8143f489
 #1 [ffff8808157e77b8] reiserfs_get_block at ffffffffa038ab2d [reiserfs]
 #2 [ffff8808157e79a8] __block_write_begin at ffffffff8117fb14
 #3 [ffff8808157e7a98] reiserfs_write_begin at ffffffffa0388695 [reiserfs]
 #4 [ffff8808157e7ad8] generic_perform_write at ffffffff810ee9e2
 #5 [ffff8808157e7b58] generic_file_buffered_write at ffffffff810eeb41
 #6 [ffff8808157e7ba8] __generic_file_aio_write at ffffffff810f1a3a
 #7 [ffff8808157e7c58] generic_file_aio_write at ffffffff810f1c88
 #8 [ffff8808157e7cc8] do_sync_write at ffffffff8114f850
 #9 [ffff8808157e7dd8] do_acct_process at ffffffff810a268f
    [exception RIP: kernel_thread_helper]
    RIP: ffffffff8144a5c0  RSP: ffff8808157e7f58  RFLAGS: 00000202
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: ffffffff8107af60  RDI: ffff8803ee491d18
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000
    R13: 0000000000000000  R14: 0000000000000000  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018

Signed-off-by: Mike Galbraith <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
10 years agomm: soft offline: split thp at the beginning of soft_offline_page()
Naoya Horiguchi [Thu, 29 Nov 2012 21:54:34 +0000 (13:54 -0800)]
mm: soft offline: split thp at the beginning of soft_offline_page()

commit 783657a7dc20e5c0efbc9a09a9dd38e238a723da upstream.

When we try to soft-offline a thp tail page, put_page() is called on the
tail page unthinkingly and VM_BUG_ON is triggered in put_compound_page().

This patch splits thp before going into the main body of soft-offlining.

Signed-off-by: Naoya Horiguchi <>
Cc: Andi Kleen <>
Cc: Tony Luck <>
Cc: Andi Kleen <>
Cc: Wu Fengguang <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
10 years agomm: vmscan: fix endless loop in kswapd balancing
Johannes Weiner [Thu, 29 Nov 2012 21:54:23 +0000 (13:54 -0800)]
mm: vmscan: fix endless loop in kswapd balancing

commit 60cefed485a02bd99b6299dad70666fe49245da7 upstream.

Kswapd does not in all places have the same criteria for a balanced
zone.  Zones are only being reclaimed when their high watermark is
breached, but compaction checks loop over the zonelist again when the
zone does not meet the low watermark plus two times the size of the
allocation.  This gets kswapd stuck in an endless loop over a small
zone, like the DMA zone, where the high watermark is smaller than the
compaction requirement.

Add a function, zone_balanced(), that checks the watermark, and, for
higher order allocations, if compaction has enough free memory.  Then
use it uniformly to check for balanced zones.

This makes sure that when the compaction watermark is not met, at least
reclaim happens and progress is made - or the zone is declared
unreclaimable at some point and skipped entirely.

Signed-off-by: Johannes Weiner <>
Reported-by: George Spelvin <>
Reported-by: Johannes Hirte <>
Reported-by: Tomas Racek <>
Tested-by: Johannes Hirte <>
Reviewed-by: Rik van Riel <>
Cc: Mel Gorman <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agomm/vmemmap: fix wrong use of virt_to_page
Jianguo Wu [Thu, 29 Nov 2012 21:54:21 +0000 (13:54 -0800)]
mm/vmemmap: fix wrong use of virt_to_page

commit ae64ffcac35de0db628ba9631edf8ff34c5cd7ac upstream.

memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20.

It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is
only used for kernel direct mapping address, but sparse-vmemmap uses
vmemmap address, so it is going wrong here.

  ------------[ cut here ]------------
  kernel BUG at arch/x86/mm/physaddr.c:20!
  invalid opcode: 0000 [#1] SMP
  Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
  CPU 39
  Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ #45 QCI QSSC-S4R/QSSC-S4R
  RIP: 0010:[<ffffffff8103c908>]  [<ffffffff8103c908>] __phys_addr+0x88/0x90
  RSP: 0018:ffff8804440d7c08  EFLAGS: 00010006
  RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c

Signed-off-by: Jianguo Wu <>
Signed-off-by: Jiang Liu <>
Reviewd-by: Wen Congyang <>
Acked-by: Johannes Weiner <>
Reviewed-by: Yasuaki Ishimatsu <>
Reviewed-by: Michal Hocko <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
10 years agofutex: avoid wake_futex() for a PI futex_q
Darren Hart [Tue, 27 Nov 2012 00:29:56 +0000 (16:29 -0800)]
futex: avoid wake_futex() for a PI futex_q

commit aa10990e028cac3d5e255711fb9fb47e00700e35 upstream.

Dave Jones reported a bug with futex_lock_pi() that his trinity test
exposed.  Sometime between queue_me() and taking the q.lock_ptr, the
lock_ptr became NULL, resulting in a crash.

While futex_wake() is careful to not call wake_futex() on futex_q's with
a pi_state or an rt_waiter (which are either waiting for a
futex_unlock_pi() or a PI futex_requeue()), futex_wake_op() and
futex_requeue() do not perform the same test.

Update futex_wake_op() and futex_requeue() to test for q.pi_state and
q.rt_waiter and abort with -EINVAL if detected.  To ensure any future
breakage is caught, add a WARN() to wake_futex() if the same condition
is true.

This fix has seen 3 hours of testing with "trinity -c futex" on an
x86_64 VM with 4 CPUS.

[ tidy up the WARN()]
Signed-off-by: Darren Hart <>
Reported-by: Dave Jones <>
Cc: Thomas Gleixner <>
Cc: Peter Zijlstra <>
Cc: Ingo Molnar <>
Cc: John Kacur <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
10 years agocan: bcm: initialize ifindex for timeouts without previous frame reception
Oliver Hartkopp [Mon, 26 Nov 2012 21:24:23 +0000 (22:24 +0100)]
can: bcm: initialize ifindex for timeouts without previous frame reception

commit 81b401100c01d2357031e874689f89bd788d13cd upstream.

Set in the rx_ifindex to pass the correct interface index in the case of a
message timeout detection. Usually the rx_ifindex value is set at receive
time. But when no CAN frame has been received the RX_TIMEOUT notification
did not contain a valid value.

Reported-by: Andre Naujoks <>
Signed-off-by: Oliver Hartkopp <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
10 years agojbd: Fix lock ordering bug in journal_unmap_buffer()
Jan Kara [Fri, 23 Nov 2012 13:03:04 +0000 (14:03 +0100)]
jbd: Fix lock ordering bug in journal_unmap_buffer()

commit 25389bb207987b5774182f763b9fb65ff08761c8 upstream.

Commit 09e05d48 introduced a wait for transaction commit into
journal_unmap_buffer() in the case we are truncating a buffer undergoing commit
in the page stradding i_size on a filesystem with blocksize < pagesize. Sadly
we forgot to drop buffer lock before waiting for transaction commit and thus
deadlock is possible when kjournald wants to lock the buffer.

Fix the problem by dropping the buffer lock before waiting for transaction
commit. Since we are still holding page lock (and that is OK), buffer cannot
disappear under us.

Signed-off-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
10 years agoblock: Don't access request after it might be freed
Roland Dreier [Thu, 22 Nov 2012 10:00:11 +0000 (02:00 -0800)]
block: Don't access request after it might be freed

commit 893d290f1d7496db97c9471bc352ad4a11dc8a25 upstream.

After we've done __elv_add_request() and __blk_run_queue() in
blk_execute_rq_nowait(), the request might finish and be freed
immediately.  Therefore checking if the type is REQ_TYPE_PM_RESUME
isn't safe afterwards, because if it isn't, rq might be gone.
Instead, check beforehand and stash the result in a temporary.

This fixes crashes in blk_execute_rq_nowait() I get occasionally when
running with lots of memory debugging options enabled -- I think this
race is usually harmless because the window for rq to be reallocated
is so small.

Signed-off-by: Roland Dreier <>
Signed-off-by: Jens Axboe <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agodm: fix deadlock with request based dm and queue request_fn recursion
Jens Axboe [Tue, 6 Nov 2012 11:24:26 +0000 (12:24 +0100)]
dm: fix deadlock with request based dm and queue request_fn recursion

commit a8c32a5c98943d370ea606a2e7dc04717eb92206 upstream.

Request based dm attempts to re-run the request queue off the
request completion path. If used with a driver that potentially does
end_io from its request_fn, we could deadlock trying to recurse
back into request dispatch. Fix this by punting the request queue
run to kblockd.

Tested to fix a quickly reproducible deadlock in such a scenario.

Acked-by: Alasdair G Kergon <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
10 years agofix user-triggerable panic on parisc
Al Viro [Wed, 21 Nov 2012 19:27:23 +0000 (19:27 +0000)]
fix user-triggerable panic on parisc

commit 441a179dafc0f99fc8b3a8268eef66958621082e upstream.

int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset,
                                    unsigned int sigsetsize)
        sigset_t old_set, new_set;
        int ret;

        if (set && get_sigset32(set, &new_set, sigsetsize))

static int
get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz)
        compat_sigset_t s;
        int r;

        if (sz != sizeof *set) panic("put_sigset32()");

In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process
will promptly panic the box.

Signed-off-by: Al Viro <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
10 years agoARM: Kirkwood: Update PCI-E fixup
Jason Gunthorpe [Wed, 21 Nov 2012 07:19:06 +0000 (00:19 -0700)]
ARM: Kirkwood: Update PCI-E fixup

commit 1dc831bf53fddcc6443f74a39e72db5bcea4f15d upstream.

- The code relies on rc_pci_fixup being called, which only happens
  when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting
  this causes a booting failure with a non-obvious cause.
- Update rc_pci_fixup to set the class properly, copying the
  more modern style from other places
- Correct the rc_pci_fixup comment

Signed-off-by: Jason Gunthorpe <>
Signed-off-by: Jason Cooper <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agoDove: Fix irq_to_pmu()
Russell King - ARM Linux [Sun, 18 Nov 2012 16:39:32 +0000 (16:39 +0000)]
Dove: Fix irq_to_pmu()

commit d356cf5a74afa32b40decca3c9dd88bc3cd63eb5 upstream.

PMU interrupts start at IRQ_DOVE_PMU_START, not IRQ_DOVE_PMU_START + 1.
Fix the condition.  (It may have been less likely to occur had the code
been written "if (irq >= IRQ_DOVE_PMU_START" which imho is the easier
to understand notation, and matches the normal way of thinking about
these things.)

Signed-off-by: Russell King <>
Signed-off-by: Jason Cooper <>
Signed-off-by: Ben Hutchings <>
10 years agoDove: Attempt to fix PMU/RTC interrupts
Russell King - ARM Linux [Sun, 18 Nov 2012 16:29:44 +0000 (16:29 +0000)]
Dove: Attempt to fix PMU/RTC interrupts

commit 5d3df935426271016b895aecaa247101b4bfa35e upstream.

Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware
has not been sensibly designed so that interrupts can be handled in a
race free manner.  The PMU is one such instance.

The pending (aka 'cause') register is a bunch of RW bits, meaning that
these bits can be both cleared and set by software (confirmed on the
Armada-510 on the cubox.)

Hardware sets the appropriate bit when an interrupt is asserted, and
software is required to clear the bits which are to be processed.  If
we write ~(1 << bit), then we end up asserting every other interrupt
except the one we're processing.  So, we need to do a read-modify-write
cycle to clear the asserted bit.

However, any interrupts which occur in the middle of this cycle will
also be written back as zero, which will also clear the new interrupts.

The upshot of this is: there is _no_ way to safely clear down interrupts
in this register (and other similarly behaving interrupt pending
registers on this device.)  The patch below at least stops us creating
new interrupts.

Signed-off-by: Russell King <>
Signed-off-by: Jason Cooper <>
Signed-off-by: Ben Hutchings <>
10 years agoselinux: fix sel_netnode_insert() suspicious rcu dereference
Dave Jones [Fri, 9 Nov 2012 00:09:27 +0000 (16:09 -0800)]
selinux: fix sel_netnode_insert() suspicious rcu dereference

commit 88a693b5c1287be4da937699cb82068ce9db0135 upstream.

[ INFO: suspicious RCU usage. ]
3.5.0-rc1+ #63 Not tainted
security/selinux/netnode.c:178 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
1 lock held by trinity-child1/8750:
 #0:  (sel_netnode_lock){+.....}, at: [<ffffffff812d8f8a>] sel_netnode_sid+0x16a/0x3e0

stack backtrace:
Pid: 8750, comm: trinity-child1 Not tainted 3.5.0-rc1+ #63
Call Trace:
 [<ffffffff810cec2d>] lockdep_rcu_suspicious+0xfd/0x130
 [<ffffffff812d91d1>] sel_netnode_sid+0x3b1/0x3e0
 [<ffffffff812d8e20>] ? sel_netnode_find+0x1a0/0x1a0
 [<ffffffff812d24a6>] selinux_socket_bind+0xf6/0x2c0
 [<ffffffff810cd1dd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff810cdb55>] ? lock_release_holdtime.part.9+0x15/0x1a0
 [<ffffffff81093841>] ? lock_hrtimer_base+0x31/0x60
 [<ffffffff812c9536>] security_socket_bind+0x16/0x20
 [<ffffffff815550ca>] sys_bind+0x7a/0x100
 [<ffffffff816c03d5>] ? sysret_check+0x22/0x5d
 [<ffffffff810d392d>] ? trace_hardirqs_on_caller+0x10d/0x1a0
 [<ffffffff8133b09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff816c03a9>] system_call_fastpath+0x16/0x1b

This patch below does what Paul McKenney suggested in the previous thread.

Signed-off-by: Dave Jones <>
Reviewed-by: Paul E. McKenney <>
Acked-by: Paul Moore <>
Cc: Eric Paris <>
Signed-off-by: Andrew Morton <>
Signed-off-by: James Morris <>
Signed-off-by: Ben Hutchings <>
10 years agoALSA: hda - Add support for Realtek ALC292
David Henningsson [Wed, 21 Nov 2012 07:57:58 +0000 (08:57 +0100)]
ALSA: hda - Add support for Realtek ALC292

commit af02dde8a609d8d071c4b31a82df811a55690a4a upstream.

We found a new codec ID 292, and that just a simple quirk would enable
sound output/input on this ALC292 chip.

Tested-by: Acelan Kao <>
Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
10 years agoALSA: hda - Add new codec ALC283 ALC290 support
Kailang Yang [Sat, 6 Oct 2012 15:02:30 +0000 (17:02 +0200)]
ALSA: hda - Add new codec ALC283 ALC290 support

commit 7ff34ad80b7080fafaac8efa9ef0061708eddd51 upstream.

These are compatible with standard ALC269 parser.

Signed-off-by: Kailang Yang <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
10 years agox86, microcode, AMD: Add support for family 16h processors
Boris Ostrovsky [Thu, 15 Nov 2012 18:41:50 +0000 (13:41 -0500)]
x86, microcode, AMD: Add support for family 16h processors

commit 36c46ca4f322a7bf89aad5462a3a1f61713edce7 upstream.

Add valid patch size for family 16h processors.

[ hpa: promoting to urgent/stable since it is hw enabling and trivial ]

Signed-off-by: Boris Ostrovsky <>
Acked-by: Andreas Herrmann <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
10 years agox86-32: Export kernel_stack_pointer() for modules
H. Peter Anvin [Wed, 21 Nov 2012 06:21:02 +0000 (22:21 -0800)]
x86-32: Export kernel_stack_pointer() for modules

commit cb57a2b4cff7edf2a4e32c0163200e9434807e0a upstream.

Modules, in particular oprofile (and possibly other similar tools)
need kernel_stack_pointer(), so export it using EXPORT_SYMBOL_GPL().

Cc: Yang Wei <>
Cc: Robert Richter <>
Cc: Jun Zhang <>
Signed-off-by: H. Peter Anvin <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agox86-32: Fix invalid stack address while in softirq
Robert Richter [Mon, 3 Sep 2012 18:54:48 +0000 (20:54 +0200)]
x86-32: Fix invalid stack address while in softirq

commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream.

In 32 bit the stack address provided by kernel_stack_pointer() may
point to an invalid range causing NULL pointer access or page faults
while in NMI (see trace below). This happens if called in softirq
context and if the stack is empty. The address at &regs->sp is then
out of range.

Fixing this by checking if regs and &regs->sp are in the same stack
context. Otherwise return the previous stack pointer stored in struct
thread_info. If that address is invalid too, return address of regs.

 BUG: unable to handle kernel NULL pointer dereference at 0000000a
 IP: [<c1004237>] print_context_stack+0x6e/0x8d
 *pde = 00000000
 Oops: 0000 [#1] SMP
 Modules linked in:
 Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch
 EIP: 0060:[<c1004237>] EFLAGS: 00010093 CPU: 0
 EIP is at print_context_stack+0x6e/0x8d
 EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a
 ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0
  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0
 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
 DR6: ffff0ff0 DR7: 00000400
 Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000)
  000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c
  f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000
  f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c
 Call Trace:
  [<c1003723>] dump_trace+0x7b/0xa1
  [<c12dce1c>] x86_backtrace+0x40/0x88
  [<c12db712>] ? oprofile_add_sample+0x56/0x84
  [<c12db731>] oprofile_add_sample+0x75/0x84
  [<c12ddb5b>] op_amd_check_ctrs+0x46/0x260
  [<c12dd40d>] profile_exceptions_notify+0x23/0x4c
  [<c1395034>] nmi_handle+0x31/0x4a
  [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [<c13950ed>] do_nmi+0xa0/0x2ff
  [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [<c13949e5>] nmi_stack_correct+0x28/0x2d
  [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [<c1003603>] ? do_softirq+0x4b/0x7f
  [<c102a06f>] irq_exit+0x35/0x5b
  [<c1018f56>] smp_apic_timer_interrupt+0x6c/0x7a
  [<c1394746>] apic_timer_interrupt+0x2a/0x30
 Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 <8b> 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc
 EIP: [<c1004237>] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0
 CR2: 000000000000000a
 ---[ end trace 62afee3481b00012 ]---
 Kernel panic - not syncing: Fatal exception in interrupt

* add comments to kernel_stack_pointer()
* always return a valid stack address by falling back to the address
  of regs

Reported-by: Yang Wei <>
Signed-off-by: Robert Richter <>
Signed-off-by: H. Peter Anvin <>
Cc: Jun Zhang <>
Signed-off-by: Ben Hutchings <>
10 years agoradeon: add AGPMode 1 quirk for RV250
Paul Bolle [Mon, 19 Nov 2012 20:17:31 +0000 (21:17 +0100)]
radeon: add AGPMode 1 quirk for RV250

commit 45171002b01b2e2ec4f991eca81ffd8430fd0aec upstream.

The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination
in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under
KMS, that is). So add a quirk for it.

(Change R250 to RV250 in comment for preceding quirk too.)

Signed-off-by: Paul Bolle <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
10 years agodrm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()
Alex Deucher [Mon, 19 Nov 2012 14:11:27 +0000 (09:11 -0500)]
drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()

commit 804cc4a0ad3a896ca295f771a28c6eb36ced7903 upstream.

The save struct is not initialized previously so explicitly
mark the crtcs as not used when they are not in use.

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
10 years agomd: Avoid write invalid address if read_seqretry returned true.
majianpeng [Thu, 8 Nov 2012 00:56:27 +0000 (08:56 +0800)]
md: Avoid write invalid address if read_seqretry returned true.

commit 35f9ac2dcec8f79d7059ce174fd7b7ee3290d620 upstream.

If read_seqretry returned true and bbp was changed, it will write
invalid address which can cause some serious problem.

This bug was introduced by commit v3.0-rc7-130-g2699b67.
So fix is suitable for 3.0.y thru 3.6.y.

Signed-off-by: Jianpeng Ma <>
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
10 years agomd: Reassigned the parameters if read_seqretry returned true in func md_is_badblock.
majianpeng [Tue, 6 Nov 2012 09:13:44 +0000 (17:13 +0800)]
md: Reassigned the parameters if read_seqretry returned true in func md_is_badblock.

commit ab05613a0646dcc11049692d54bae76ca9ffa910 upstream.

This bug was introduced by commit(v3.0-rc7-126-g2230dfe).
So fix is suitable for 3.0.y thru 3.6.y.

Signed-off-by: Jianpeng Ma <>
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
10 years agoreiserfs: Move quota calls out of write lock
Jan Kara [Tue, 13 Nov 2012 16:05:14 +0000 (17:05 +0100)]
reiserfs: Move quota calls out of write lock

commit 7af11686933726e99af22901d622f9e161404e6b upstream.

Calls into highlevel quota code cannot happen under the write lock. These
calls take dqio_mutex which ranks above write lock. So drop write lock
before calling back into quota code.

Signed-off-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
10 years agoreiserfs: Protect reiserfs_quota_write() with write lock
Jan Kara [Tue, 13 Nov 2012 17:25:38 +0000 (18:25 +0100)]
reiserfs: Protect reiserfs_quota_write() with write lock

commit 361d94a338a3fd0cee6a4ea32bbc427ba228e628 upstream.

Calls into reiserfs journalling code and reiserfs_get_block() need to
be protected with write lock. We remove write lock around calls to high
level quota code in the next patch so these paths would suddently become

Signed-off-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
10 years agoreiserfs: Protect reiserfs_quota_on() with write lock
Jan Kara [Tue, 13 Nov 2012 15:34:17 +0000 (16:34 +0100)]
reiserfs: Protect reiserfs_quota_on() with write lock

commit b9e06ef2e8706fe669b51f4364e3aeed58639eb2 upstream.

In reiserfs_quota_on() we do quite some work - for example unpacking
tail of a quota file. Thus we have to hold write lock until a moment
we call back into the quota code.

Signed-off-by: Jan Kara <>
[bwh: Backported to 3.2: there is no distinction between USRQUOTA and
 GRPQUOTA mount options here]
Signed-off-by: Ben Hutchings <>
10 years agoreiserfs: Fix lock ordering during remount
Jan Kara [Tue, 13 Nov 2012 13:55:52 +0000 (14:55 +0100)]
reiserfs: Fix lock ordering during remount

commit 3bb3e1fc47aca554e7e2cc4deeddc24750987ac2 upstream.

When remounting reiserfs dquot_suspend() or dquot_resume() can be called.
These functions take dqonoff_mutex which ranks above write lock so we have
to drop it before calling into quota code.

Signed-off-by: Jan Kara <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agosparc64: not any error from do_sigaltstack() should fail rt_sigreturn()
Al Viro [Mon, 19 Nov 2012 03:27:03 +0000 (22:27 -0500)]
sparc64: not any error from do_sigaltstack() should fail rt_sigreturn()

commit fae2ae2a900a5c7bb385fe4075f343e7e2d5daa2 upstream.

If a signal handler is executed on altstack and another signal comes,
we will end up with rt_sigreturn() on return from the second handler
getting -EPERM from do_sigaltstack().  It's perfectly OK, since we
are not asking to change the settings; in fact, they couldn't have been
changed during the second handler execution exactly because we'd been
on altstack all along.  64bit sigreturn on sparc treats any error from
do_sigaltstack() as "SIGSEGV now"; we need to switch to the same semantics
we are using on other architectures.

Signed-off-by: Al Viro <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agoALSA: ua101, usx2y: fix broken MIDI output
Clemens Ladisch [Wed, 31 Oct 2012 15:35:30 +0000 (16:35 +0100)]
ALSA: ua101, usx2y: fix broken MIDI output

commit e99ddfde6ae0dd2662bb40435696002b590e4057 upstream.

Commit 88a8516a2128 (ALSA: usbaudio: implement USB autosuspend) added
autosuspend code to all files making up the snd-usb-audio driver.
However, midi.c is part of snd-usb-lib and is also used by other
drivers, not all of which support autosuspend.  Thus, calls to
usb_autopm_get_interface() could fail, and this unexpected error would
result in the MIDI output being completely unusable.

Make it work by ignoring the error that is expected with drivers that do
not support autosuspend.

Reported-by: Colin Fletcher <>
Reported-by: Devin Venable <>
Reported-by: Dr Nick Bailey <>
Reported-by: Jannis Achstetter <>
Reported-by: Rui Nuno Capela <>
Cc: Oliver Neukum <>
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Ben Hutchings <>
10 years agoxfs: drop buffer io reference when a bad bio is built
Dave Chinner [Mon, 12 Nov 2012 11:09:46 +0000 (22:09 +1100)]
xfs: drop buffer io reference when a bad bio is built

commit d69043c42d8c6414fa28ad18d99973aa6c1c2e24 upstream.

Error handling in xfs_buf_ioapply_map() does not handle IO reference
counts correctly. We increment the b_io_remaining count before
building the bio, but then fail to decrement it in the failure case.
This leads to the buffer never running IO completion and releasing
the reference that the IO holds, so at unmount we can leak the
buffer. This leak is captured by this assert failure during unmount:

XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 273

This is not a new bug - the b_io_remaining accounting has had this
problem for a long, long time - it's just very hard to get a
zero length bio being built by this code...

Further, the buffer IO error can be overwritten on a multi-segment
buffer by subsequent bio completions for partial sections of the
buffer. Hence we should only set the buffer error status if the
buffer is not already carrying an error status. This ensures that a
partial IO error on a multi-segment buffer will not be lost. This
part of the problem is a regression, however.

Signed-off-by: Dave Chinner <>
Reviewed-by: Mark Tinguely <>
Signed-off-by: Ben Myers <>
Signed-off-by: Ben Hutchings <>
10 years agomwifiex: report error to MMC core if we cannot suspend
Bing Zhao [Thu, 15 Nov 2012 23:58:48 +0000 (15:58 -0800)]
mwifiex: report error to MMC core if we cannot suspend

commit dd321acddc3be1371263b8c9e6c6f2af89f63d57 upstream.

When host_sleep_config command fails we should return error to
MMC core to indicate the failure for our device.

The misspelled variable is also removed as it's redundant.

Signed-off-by: Bing Zhao <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
10 years agomwifiex: fix system hang issue in cmd timeout error case
Bing Zhao [Thu, 15 Nov 2012 23:58:47 +0000 (15:58 -0800)]
mwifiex: fix system hang issue in cmd timeout error case

commit b1a47aa5e1e159e2cb06d7dfcc17ef5149b09299 upstream.

Reported by Tim Shepard:
I was seeing sporadic failures (wedgeups), and the majority of those
failures I saw printed the printouts in mwifiex_cmd_timeout_func with
cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH.  When this happens, two
minutes later I get notified that the rtcwake thread is blocked, like
      INFO: task rtcwake:3495 blocked for more than 120 seconds.

To get the hung thread unblocked we wake up the cmd wait queue and
cancel the ioctl.

Reported-by: Tim Shepard <>
Signed-off-by: Bing Zhao <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agortlwifi: rtl8192cu: Add new USB ID
Albert Pool [Tue, 30 Oct 2012 19:58:06 +0000 (20:58 +0100)]
rtlwifi: rtl8192cu: Add new USB ID

commit a485e827f07bfdd0762059386e6e787bed6e81ee upstream.

This is an ISY IWL 2000. Probably a clone of Belkin F7D1102 050d:1102.
Its FCC ID is the same.

Signed-off-by: Albert Pool <>
Acked-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
10 years agofix virtual aliasing issue in get_shared_area()
James Bottomley [Fri, 2 Nov 2012 12:30:53 +0000 (12:30 +0000)]
fix virtual aliasing issue in get_shared_area()

commit 949a05d03490e39e773e8652ccab9157e6f595b4 upstream.

On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote:
> Looking at the arch/parisc/kernel/sys_parisc.c implementation of
> get_shared_area(), I do have a concern though. The function basically
> ignores the pgoff argument, so that if one creates a shared mapping of
> pages 0-N of a file, and then a separate shared mapping of pages 1-N
> of that same file, both will have the same cache offset for their
> starting address.
> This looks like this would create obvious aliasing issues. Am I
> misreading this ? I can't understand how this could work good enough
> to be undetected, so there must be something I'm missing here ???

This turns out to be correct and we need to pay attention to the pgoff as
well as the address when creating the virtual address for the area.
Fortunately, the bug is rarely triggered as most applications which use pgoff
tend to use large values (git being the primary one, and it uses pgoff in
multiples of 16MB) which are larger than our cache coherency modulus, so the
problem isn't often seen in practise.

Reported-by: Michel Lespinasse <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
10 years agomac80211: deinitialize ibss-internals after emptiness check
Simon Wunderlich [Tue, 13 Nov 2012 17:43:03 +0000 (18:43 +0100)]
mac80211: deinitialize ibss-internals after emptiness check

commit b78a4932f5fb11fadf41e69c606a33fa6787574c upstream.

The check whether the IBSS is active and can be removed should be
performed before deinitializing the fields used for the check/search.
Otherwise, the configured BSS will not be found and removed properly.

To make it more clear for the future, rename sdata->u.ibss to the
local pointer ifibss which is used within the checks.

This behaviour was introduced by
("mac80211: fix IBSS teardown race")

Cc: Ignacy Gawedzki <>
Signed-off-by: Simon Wunderlich <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
10 years agoisci: copy fis 0x34 response into proper buffer
Maciej Patelczyk [Mon, 15 Oct 2012 12:29:03 +0000 (14:29 +0200)]
isci: copy fis 0x34 response into proper buffer

commit 49bd665c5407a453736d3232ee58f2906b42e83c upstream.

SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register
Device to Host (FIS 0x34) frame Initiator resets phy.
In the frame handler routine response (FIS 0x34) was copied into wrong
buffer and upper layer did not receive any answer which resulted in
timeout and reset.
This patch corrects this bug.

Signed-off-by: Maciej Patelczyk <>
Signed-off-by: Lukasz Dorau <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
10 years agojffs2: Fix lock acquisition order bug in jffs2_write_begin
Thomas Betker [Wed, 17 Oct 2012 20:59:30 +0000 (22:59 +0200)]
jffs2: Fix lock acquisition order bug in jffs2_write_begin

commit 5ffd3412ae5536a4c57469cb8ea31887121dcb2e upstream.

jffs2_write_begin() first acquires the page lock, then f->sem. This
causes an AB-BA deadlock with jffs2_garbage_collect_live(), which first
acquires f->sem, then the page lock:

    mutex_lock(&f->sem)                         (A)
                    lock_page(page)             (B)

            lock_page(page)                     (B)
    mutex_lock(&f->sem)                         (A)

We fix this by restructuring jffs2_write_begin() to take f->sem before
the page lock. However, we make sure that f->sem is not held when
calling jffs2_reserve_space(), as this is not permitted by the locking

The deadlock above was observed multiple times on an SoC with a dual
ARMv7 (Cortex-A9), running the long-term 3.4.11 kernel; it occurred
when using scp to copy files from a host system to the ARM target
system. The fix was heavily tested on the same target system.

Signed-off-by: Thomas Betker <>
Acked-by: Joakim Tjernlund <>
Signed-off-by: Artem Bityutskiy <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use D1(printk(KERN_DEBUG ...)) instead of jffs2_dbg(1, ...)]
Signed-off-by: Ben Hutchings <>
10 years agomtd: slram: invalid checking of absolute end address
Jiri Engelthaler [Thu, 20 Sep 2012 14:49:50 +0000 (16:49 +0200)]
mtd: slram: invalid checking of absolute end address

commit c36a7ff4578ab6294885aef5ef241aeec4cdb1f0 upstream.

Fixed parsing end absolute address.

Signed-off-by: Jiri Engelthaler <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Ben Hutchings <>
10 years agomtd: ofpart: Fix incorrect NULL check in parse_ofoldpart_partitions()
Sachin Kamat [Tue, 25 Sep 2012 09:57:13 +0000 (15:27 +0530)]
mtd: ofpart: Fix incorrect NULL check in parse_ofoldpart_partitions()

commit 5a6ea4af0907f995dc06df21a9c9ef764c7cd3bc upstream.

The pointer returned by kzalloc should be tested for NULL
to avoid potential NULL pointer dereference later. Incorrect
pointer was being tested for NULL. Bug introduced by commit fbcf62a3
(mtd: physmap_of: move parse_obsolete_partitions to become separate
This patch fixes this bug.

Cc: Dmitry Eremin-Solenikov <>
Cc: Artem Bityutskiy <>
Signed-off-by: Sachin Kamat <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Ben Hutchings <>
10 years agox86, amd: Disable way access filter on Piledriver CPUs
Andre Przywara [Wed, 31 Oct 2012 16:20:50 +0000 (17:20 +0100)]
x86, amd: Disable way access filter on Piledriver CPUs

commit 2bbf0a1427c377350f001fbc6260995334739ad7 upstream.

The Way Access Filter in recent AMD CPUs may hurt the performance of
some workloads, caused by aliasing issues in the L1 cache.
This patch disables it on the affected CPUs.

The issue is similar to that one of last year:
This new patch does not replace the old one, we just need another
quirk for newer CPUs.

The performance penalty without the patch depends on the
circumstances, but is a bit less than the last year's 3%.

The workloads affected would be those that access code from the same
physical page under different virtual addresses, so different
processes using the same libraries with ASLR or multiple instances of
PIE-binaries. The code needs to be accessed simultaneously from both
cores of the same compute unit.

More details can be found here:

CPUs affected are anything with the core known as Piledriver.
That includes the new parts of the AMD A-Series (aka Trinity) and the
just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2,
A-Series has model 10h, with possible extensions to 1Fh. Hence the
range of model ids.

Signed-off-by: Andre Przywara <>
Signed-off-by: H. Peter Anvin <>
[bwh: Backported to 3.2: wrmsrl_safe() is called checking_wrmsrl()]
Signed-off-by: Ben Hutchings <>
10 years agowatchdog: using u64 in get_sample_period()
Chuansheng Liu [Tue, 27 Nov 2012 00:29:54 +0000 (16:29 -0800)]
watchdog: using u64 in get_sample_period()

commit 8ffeb9b0e6369135bf03a073514f571ef10606b9 upstream.

In get_sample_period(), unsigned long is not enough:

  watchdog_thresh * 2 * (NSEC_PER_SEC / 5)

  watchdog_thresh is 10 by default, the sample value will be: 0xEE6B2800

 set watchdog_thresh is 20, the sample value will be: 0x1 DCD6 5000

In case2, we need use u64 to express the sample period.  Otherwise,
changing the threshold thru proc often can not be successful.

Signed-off-by: liu chuansheng <>
Acked-by: Don Zickus <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
10 years agoInput: bcm5974 - set BUTTONPAD property
Jussi Pakkanen [Wed, 11 Jan 2012 07:04:16 +0000 (23:04 -0800)]
Input: bcm5974 - set BUTTONPAD property

commit 52965cc012f7a3cf35f06485ec275ebf3b3fddae upstream.

Some bcm5974 trackpads have a physical button beneath the physical surface.
This patch sets the property bit so user space applications can detect the
trackpad type and act accordingly.

Signed-off-by: Jussi Pakkanen <>
Reviewed-by: Henrik Rydberg <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
10 years agox86, mce, therm_throt: Don't report power limit and package level thermal throttle...
Fenghua Yu [Fri, 4 Nov 2011 20:31:23 +0000 (13:31 -0700)]
x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog

commit 29e9bf1841e4f9df13b4992a716fece7087dd237 upstream.

Thermal throttle and power limit events are not defined as MCE errors in x86
architecture and should not generate MCE errors in mcelog.

Current kernel generates fake software defined MCE errors for these events.
This may confuse users because they may think the machine has real MCE errors
while actually only thermal throttle or power limit events happen.

To make it worse, buggy firmware on some platforms may falsely generate
the events. Therefore, kernel reports MCE errors which users think as real
hardware errors. Although the firmware bugs should be fixed, on the other hand,
kernel should not report MCE errors either.

So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
package_power_limit_count, core_throttle_count, and package_throttle_count) in
/sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
for each event on each CPU. Please note that all CPU's on one package report
duplicate counters. It's user application's responsibity to retrieve a package
level counter for one package.

This patch doesn't report package level power limit, core level power limit, and
package level thermal throttle events in mcelog. When the events happen, only
report them in respective counters in sysfs.

Since core level thermal throttle has been legacy code in kernel for a while and
users accepted it as MCE error in mcelog, core level thermal throttle is still
reported in mcelog. In the mean time, the event is counted in a counter in sysfs
as well.

Signed-off-by: Fenghua Yu <>
Acked-by: Borislav Petkov <>
Acked-by: Tony Luck <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
10 years agoxhci: Remove scary warnings about transfer issues.
Sarah Sharp [Tue, 25 Oct 2011 11:55:30 +0000 (13:55 +0200)]
xhci: Remove scary warnings about transfer issues.

commit 2a9227a5eeaeb3f91e3a72ceea4fa59016ca5d20 upstream.

Getting a short packet or a babble error is usually a recoverable error,
so stop scaring users with warnings in dmesg when xHCI debugging is turned

Signed-off-by: Sarah Sharp <>
Signed-off-by: Ben Hutchings <>
10 years agoxhci: Remove warnings about MSI and MSI-X capabilities.
Sarah Sharp [Thu, 22 Dec 2011 23:02:13 +0000 (15:02 -0800)]
xhci: Remove warnings about MSI and MSI-X capabilities.

commit 3b9783b277e66731891ab42eeaacebbdcdd6e629 upstream.

xHCI host controllers may not be capable of MSI, but they should be able
to be used in legacy PCI interrupt mode.  Similarly, some xHCI host
controllers will have MSI support but not MSI-X support.  Lower the
dmesg log level from an error to debug.  The message won't appear unless

If we need to find out whether the device can support MSI or MSI-X and
it's not being enabled by the driver, it's easy to ask the user to run

Signed-off-by: Sarah Sharp <>
Signed-off-by: Ben Hutchings <>
10 years agoacer-wmi: support for P key on TM8372
Merlin Schumacher [Mon, 23 Jan 2012 20:35:35 +0000 (04:35 +0800)]
acer-wmi: support for P key on TM8372

commit 67e1d34cd54cbf33f093f1dd53e7bda1124eb972 upstream.

There is no entry for P key on TM8372, so when P key is pressed, only
"acer_wmi: Unknown key number - 0x29" in dmesg.

Signed-off-by: Merlin Schumacher <>
Signed-off-by: Ike Panhc <>
Signed-off-by: Matthew Garrett <>
Signed-off-by: Ben Hutchings <>
10 years agowatchdog: iTCO_wdt: add Intel Lynx Point DeviceIDs
Seth Heasley [Tue, 24 Jan 2012 00:40:55 +0000 (16:40 -0800)]
watchdog: iTCO_wdt: add Intel Lynx Point DeviceIDs

commit 84e83c2846ffb42772056a0f825d8578dc92d586 upstream.

This patch adds the TCO Watchdog DeviceIDs for the Intel Lynx Point PCH.

Signed-off-by: Seth Heasley <>
Signed-off-by: Wim Van Sebroeck <>
Signed-off-by: Ben Hutchings <>
10 years agoptp: update adjfreq callback description
Jacob Keller [Thu, 1 Nov 2012 12:30:16 +0000 (12:30 +0000)]
ptp: update adjfreq callback description

commit 87f4d7c1d36f44b0822053b7e5dedc31fdd0ab99 upstream.

This patch updates the adjfreq callback description to include a note that the
delta in ppb is always relative to the base frequency, and not to the current
frequency of the hardware clock.

Signed-off-by: Jacob Keller <>
CC: Richard Cochran <>
CC: John Stultz <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agoGFS2: Test bufdata with buffer locked and gfs2_log_lock held
Benjamin Marzinski [Wed, 7 Nov 2012 06:38:06 +0000 (00:38 -0600)]
GFS2: Test bufdata with buffer locked and gfs2_log_lock held

commit 96e5d1d3adf56f1c7eeb07258f6a1a0a7ae9c489 upstream.

In gfs2_trans_add_bh(), gfs2 was testing if a there was a bd attached to the
buffer without having the gfs2_log_lock held. It was then assuming it would
stay attached for the rest of the function. However, without either the log
lock being held of the buffer locked, __gfs2_ail_flush() could detach bd at any
time.  This patch moves the locking before the test.  If there isn't a bd
already attached, gfs2 can safely allocate one and attach it before locking.
There is no way that the newly allocated bd could be on the ail list,
and thus no way for __gfs2_ail_flush() to detach it.

Signed-off-by: Benjamin Marzinski <>
Signed-off-by: Steven Whitehouse <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agobas_gigaset: fix pre_reset handling
Tilman Schmidt [Wed, 24 Oct 2012 08:44:32 +0000 (08:44 +0000)]
bas_gigaset: fix pre_reset handling

commit c6fdd8e5d0c65bb8821dc6da26ee1a2ddd58b3cc upstream.

The delayed work function int_in_work() may call usb_reset_device()
and thus, indirectly, the driver's pre_reset method. Trying to
cancel the work synchronously in that situation would deadlock.
Fix by avoiding cancel_work_sync() in the pre_reset method.

If the reset was NOT initiated by int_in_work() this might cause
int_in_work() to run after the post_reset method, with urb_int_in
already resubmitted, so handle that case gracefully.

Signed-off-by: Tilman Schmidt <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agobrcm80211: smac: only print block-ack timeout message at trace level
Arend van Spriel [Thu, 23 Feb 2012 17:38:23 +0000 (18:38 +0100)]
brcm80211: smac: only print block-ack timeout message at trace level

commit 2b0a53d51b5f263bb581bbdb40ebb9f7e09609b1 upstream.

In regular use block-ack timeouts can happen so it does not make
sense to fill the log with these messages.

Reviewed-by: Pieter-Paul Giesberts <>
Reviewed-by: Alwin Beukers <>
Signed-off-by: Arend van Spriel <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
10 years agoHID: add quirk for Freescale i.MX28 ROM recovery
Marek Vasut [Sun, 5 Aug 2012 21:57:15 +0000 (23:57 +0200)]
HID: add quirk for Freescale i.MX28 ROM recovery

commit 2843b673d03421e0e73cf061820d1db328f7c8eb upstream.

The USB recovery mode present in i.MX28 ROM emulates USB HID.
It needs this quirk to behave properly.

Signed-off-by: Marek Vasut <>
Cc: Chen Peter <>
Cc: Greg KH <>
Cc: Jiri Kosina <>
[ fix alphabetical ordering]
Signed-off-by: Jiri Kosina <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agom68k: fix sigset_t accessor functions
Andreas Schwab [Sat, 17 Nov 2012 21:27:04 +0000 (22:27 +0100)]
m68k: fix sigset_t accessor functions

commit 34fa78b59c52d1db3513db4c1a999db26b2e9ac2 upstream.

The sigaddset/sigdelset/sigismember functions that are implemented with
bitfield insn cannot allow the sigset argument to be placed in a data
register since the sigset is wider than 32 bits.  Remove the "d"
constraint from the asm statements.

The effect of the bug is that sending RT signals does not work, the signal
number is truncated modulo 32.

Signed-off-by: Andreas Schwab <>
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Ben Hutchings <>
10 years agoget_dvb_firmware: fix download site for tda10046 firmware
Mauro Carvalho Chehab [Fri, 28 Sep 2012 19:16:00 +0000 (16:16 -0300)]
get_dvb_firmware: fix download site for tda10046 firmware

commit 25ec43d3e6306978cf66060ed18c4160ce8fc302 upstream.

The previous website doesn't exist anymore. Update it to one site that
actually exists.

Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
10 years agodrm/i915: Check VBIOS value for determining LVDS dual channel mode, too
Takashi Iwai [Tue, 20 Mar 2012 12:07:05 +0000 (13:07 +0100)]
drm/i915: Check VBIOS value for determining LVDS dual channel mode, too

commit b03543857fd75876b96e10d4320b775e95041bb7 upstream.

Currently i915 driver checks [PCH_]LVDS register bits to decide
whether to set up the dual-link or the single-link mode.  This relies
implicitly on that BIOS initializes the register properly at boot.
However, BIOS doesn't initialize it always.  When the machine is
booted with the closed lid, BIOS skips the LVDS reg initialization.
This ends up in blank output on a machine with a dual-link LVDS when
you open the lid after the boot.

This patch adds a workaround for that problem by checking the initial
LVDS register value in VBT.

Tested-By: Paulo Zanoni <>
Reviewed-by: Rodrigo Vivi <>
Reviewed-by: Adam Jackson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
10 years agoixgbe: add support for X540-AT1 [Fri, 21 Sep 2012 00:08:21 +0000 (00:08 +0000)]
ixgbe: add support for X540-AT1

commit df376f0de167754da9b3ece4afdb5bb8bf3fbf3e upstream.

This patch adds device support for Ethernet Controller X540-AT1.

Signed-off-by: Josh Hay <>
Tested-by: Phil Schmitt <>
Signed-off-by: Jeff Kirsher <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agoixgbe: add support for new 82599 device id
Emil Tantilov [Fri, 4 Nov 2011 06:43:29 +0000 (06:43 +0000)]
ixgbe: add support for new 82599 device id

commit 9e791e4a04c08868f02cd579a428a7268492e1b4 upstream.

Support for new 82599 based quad port adapter.

Signed-off-by: Emil Tantilov <>
Tested-by: Phil Schmitt <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: Ben Hutchings <>
10 years agoInput: i8042 - also perform controller reset when suspending
Dmitry Torokhov [Sat, 29 Oct 2011 19:37:06 +0000 (12:37 -0700)]
Input: i8042 - also perform controller reset when suspending

commit 1729ad1f4f9e167ade84ca8b5269695c42351160 upstream.

In addition to some laptops needing i8042 reset after resuming from S2R to
get their touchpads working there is another class of laptops - ones that
need i8042 reset before going to S2R, otherwise they will simply reboot
instead of resuming.


This change forces reset of i8042 before doing S2R.

Reported-by: Stefan Koch <>
Tested-by: Alexander van Loon <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
10 years agoPCI : Calculate right add_size
Yinghai Lu [Sat, 21 Jan 2012 10:08:17 +0000 (02:08 -0800)]
PCI : Calculate right add_size

commit a4ac9fea016fc5c09227eb479bd35e34978323a4 upstream.

During debug of one SRIOV enabled hotplug device, we found found that
add_size is not passed properly.

The device has devices under two level bridges:

 |           +-01.0-[90-9f]--
 |           +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0  Oracle Corporation Device
 |           |                               \-03.0-[a3]--+-00.0  Oracle Corporation Device

Which means later the parent bridge will not try to add a big enough range:

[  557.455077] pci 0000:a0:00.0: BAR 14: assigned [mem 0xf9000000-0xf93fffff]
[  557.461974] pci 0000:a0:00.0: BAR 15: assigned [mem 0xf6000000-0xf61fffff pref]
[  557.469340] pci 0000:a1:02.0: BAR 14: assigned [mem 0xf9000000-0xf91fffff]
[  557.476231] pci 0000:a1:02.0: BAR 15: assigned [mem 0xf6000000-0xf60fffff pref]
[  557.483582] pci 0000:a1:03.0: BAR 14: assigned [mem 0xf9200000-0xf93fffff]
[  557.490468] pci 0000:a1:03.0: BAR 15: assigned [mem 0xf6100000-0xf61fffff pref]
[  557.497833] pci 0000:a1:03.0: BAR 14: can't assign mem (size 0x200000)
[  557.504378] pci 0000:a1:03.0: failed to add optional resources res=[mem 0xf9200000-0xf93fffff]
[  557.513026] pci 0000:a1:02.0: BAR 14: can't assign mem (size 0x200000)
[  557.519578] pci 0000:a1:02.0: failed to add optional resources res=[mem 0xf9000000-0xf91fffff]

It turns out we did not calculate size1 properly.

static resource_size_t calculate_memsize(resource_size_t size,
                resource_size_t min_size,
                resource_size_t size1,
                resource_size_t old_size,
                resource_size_t align)
        if (size < min_size)
                size = min_size;
        if (old_size == 1 )
                old_size = 0;
        if (size < old_size)
                size = old_size;
        size = ALIGN(size + size1, align);
        return size;

We should not pass add_size with min_size in calculate_memsize since
that will make add_size not contribute final add_size.

So just pass add_size with size1 to calculate_memsize().

With this change, we should have chance to remove extra addon in

Signed-off-by: Yinghai Lu <>
Signed-off-by: Jesse Barnes <>
Signed-off-by: Ben Hutchings <>
10 years agousb: use usb_serial_put in usb_serial_probe errors
Jan Safrata [Tue, 22 May 2012 12:04:50 +0000 (14:04 +0200)]
usb: use usb_serial_put in usb_serial_probe errors

commit 0658a3366db7e27fa32c12e886230bb58c414c92 upstream.

The use of kfree(serial) in error cases of usb_serial_probe
was invalid - usb_serial structure allocated in create_serial()
gets reference of usb_device that needs to be put, so we need
to use usb_serial_put() instead of simple kfree().

Signed-off-by: Jan Safrata <>
Acked-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
10 years agonet-rps: Fix brokeness causing OOO packets
Tom Herbert [Fri, 16 Nov 2012 09:04:15 +0000 (09:04 +0000)]
net-rps: Fix brokeness causing OOO packets

[ Upstream commit baefa31db2f2b13a05d1b81bdf2d20d487f58b0a ]

In commit c445477d74ab3779 which adds aRFS to the kernel, the CPU
selected for RFS is not set correctly when CPU is changing.
This is causing OOO packets and probably other issues.

Signed-off-by: Tom Herbert <>
Acked-by: Eric Dumazet <>
Acked-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agonet: correct check in dev_addr_del()
Jiri Pirko [Wed, 14 Nov 2012 02:51:04 +0000 (02:51 +0000)]
net: correct check in dev_addr_del()

[ Upstream commit a652208e0b52c190e57f2a075ffb5e897fe31c3b ]

Check (ha->addr == dev->dev_addr) is always true because dev_addr_init()
sets this. Correct the check to behave properly on addr removal.

Signed-off-by: Jiri Pirko <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agoipv6: setsockopt(IPIPPROTO_IPV6, IPV6_MINHOPCOUNT) forgot to set return value
Hannes Frederic Sowa [Sat, 10 Nov 2012 19:52:34 +0000 (19:52 +0000)]
ipv6: setsockopt(IPIPPROTO_IPV6, IPV6_MINHOPCOUNT) forgot to set return value

[ Upstream commit d4596bad2a713fcd0def492b1960e6d899d5baa8 ]

Cc: Stephen Hemminger <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agoipv4: avoid undefined behavior in do_ip_setsockopt()
Xi Wang [Sun, 11 Nov 2012 11:20:01 +0000 (11:20 +0000)]
ipv4: avoid undefined behavior in do_ip_setsockopt()

[ Upstream commit 0c9f79be295c99ac7e4b569ca493d75fdcc19e4e ]

(1<<optname) is undefined behavior in C with a negative optname or
optname larger than 31.  In those cases the result of the shift is
not necessarily zero (e.g., on x86).

This patch simplifies the code with a switch statement on optname.
It also allows the compiler to generate better code (e.g., using a
64-bit mask).

Signed-off-by: Xi Wang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agonetfilter: nf_nat: don't check for port change on ICMP tuples
Ulrich Weber [Thu, 25 Oct 2012 05:34:45 +0000 (05:34 +0000)]
netfilter: nf_nat: don't check for port change on ICMP tuples

commit 38fe36a248ec3228f8e6507955d7ceb0432d2000 upstream.

ICMP tuples have id in src and type/code in dst.
So comparing src.u.all with dst.u.all will always fail here
and ip_xfrm_me_harder() is called for every ICMP packet,
even if there was no NAT.

Signed-off-by: Ulrich Weber <>
[Pablo Neira Ayuso: Backported to.3.0]
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
10 years agonetfilter: Validate the sequence number of dataless ACK packets as well
Jozsef Kadlecsik [Fri, 31 Aug 2012 09:55:54 +0000 (09:55 +0000)]
netfilter: Validate the sequence number of dataless ACK packets as well

commit 4a70bbfaef0361d27272629d1a250a937edcafe4 upstream.

We spare nothing by not validating the sequence number of dataless
ACK packets and enabling it makes harder off-path attacks.

See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel,

Signed-off-by: Jozsef Kadlecsik <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
10 years agonetfilter: Mark SYN/ACK packets as invalid from original direction
Jozsef Kadlecsik [Fri, 31 Aug 2012 09:55:53 +0000 (09:55 +0000)]
netfilter: Mark SYN/ACK packets as invalid from original direction

commit 64f509ce71b08d037998e93dd51180c19b2f464c upstream.

Clients should not send such packets. By accepting them, we open
up a hole by wich ephemeral ports can be discovered in an off-path

See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel,

Signed-off-by: Jozsef Kadlecsik <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
10 years agox86, mm: Undo incorrect revert in arch/x86/mm/init.c
Yinghai Lu [Thu, 25 Oct 2012 22:45:26 +0000 (15:45 -0700)]
x86, mm: Undo incorrect revert in arch/x86/mm/init.c

commit f82f64dd9f485e13f29f369772d4a0e868e5633a upstream.


    844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped

added back some lines back wrongly that has been removed in commit

    7b16bbf97 Revert "x86/mm: Fix the size calculation of mapping tables"

remove them again.

Signed-off-by: Yinghai Lu <>
Acked-by: Jacob Shin <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
10 years agox86, mm: Find_early_table_space based on ranges that are actually being mapped
Jacob Shin [Wed, 24 Oct 2012 19:24:44 +0000 (14:24 -0500)]
x86, mm: Find_early_table_space based on ranges that are actually being mapped

commit 844ab6f993b1d32eb40512503d35ff6ad0c57030 upstream.

Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by

This is needed after 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a, to address
the panic reported here:

Signed-off-by: Jacob Shin <>
Tested-by: Tom Rini <>
Signed-off-by: H. Peter Anvin <>
[bwh: Backported to 3.2:
 - Adjust context
 - The log message format is a bit different]
Signed-off-by: Ben Hutchings <>
10 years agox86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.
Jacob Shin [Thu, 20 Oct 2011 21:15:26 +0000 (16:15 -0500)]
x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.

commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream.

On systems with very large memory (1 TB in our case), BIOS may report a
reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
these from the direct mapping.

[ hpa: this should be done not just for > 4 GB but for everything above the legacy
  region (1 MB), at the very least.  That, however, turns out to require significant
  restructuring.  That work is well underway, but is not suitable for rc/stable. ]

Signed-off-by: Jacob Shin <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
10 years agotmpfs: change final i_blocks BUG to WARNING
Hugh Dickins [Fri, 16 Nov 2012 22:15:04 +0000 (14:15 -0800)]
tmpfs: change final i_blocks BUG to WARNING

commit 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 upstream.

Under a particular load on one machine, I have hit shmem_evict_inode()'s
BUG_ON(inode->i_blocks), enough times to narrow it down to a particular
race between swapout and eviction.

It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(),
and the lack of coherent locking between mapping's nrpages and shmem's
swapped count.  There's a window in shmem_writepage(), between lowering
nrpages in shmem_delete_from_page_cache() and then raising swapped
count, when the freed count appears to be +1 when it should be 0, and
then the asymmetry stops it from being corrected with -1 before hitting
the BUG.

One answer is coherent locking: using tree_lock throughout, without
info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on
used_blocks makes that messier than expected.  Another answer may be a
further effort to eliminate the weird shmem_recalc_inode() altogether,
but previous attempts at that failed.

So far undecided, but for now change the BUG_ON to WARN_ON: in usual
circumstances it remains a useful consistency check.

Signed-off-by: Hugh Dickins <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agomemcg: oom: fix totalpages calculation for memory.swappiness==0
Michal Hocko [Fri, 16 Nov 2012 22:14:49 +0000 (14:14 -0800)]
memcg: oom: fix totalpages calculation for memory.swappiness==0

commit 9a5a8f19b43430752067ecaee62fc59e11e88fa6 upstream.

oom_badness() takes a totalpages argument which says how many pages are
available and it uses it as a base for the score calculation.  The value
is calculated by mem_cgroup_get_limit which considers both limit and
total_swap_pages (resp.  memsw portion of it).

This is usually correct but since fe35004fbf9e ("mm: avoid swapping out
with swappiness==0") we do not swap when swappiness is 0 which means
that we cannot really use up all the totalpages pages.  This in turn
confuses oom score calculation if the memcg limit is much smaller than
the available swap because the used memory (capped by the limit) is
negligible comparing to totalpages so the resulting score is too small
if adj!=0 (typically task with CAP_SYS_ADMIN or non zero oom_score_adj).
A wrong process might be selected as result.

The problem can be worked around by checking mem_cgroup_swappiness==0
and not considering swap at all in such a case.

Signed-off-by: Michal Hocko <>
Acked-by: David Rientjes <>
Acked-by: Johannes Weiner <>
Acked-by: KOSAKI Motohiro <>
Acked-by: KAMEZAWA Hiroyuki <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
10 years agottm: Clear the ttm page allocated from high memory zone correctly
Zhao Yakui [Tue, 13 Nov 2012 18:31:55 +0000 (18:31 +0000)]
ttm: Clear the ttm page allocated from high memory zone correctly

commit ac207ed2471150e06af0afc76e4becc701fa2733 upstream.

The TTM page can be allocated from high memory. In such case it is
wrong to use the page_address(page) as the virtual address for the high memory


Signed-off-by: Zhao Yakui <>
Reviewed-by: Thomas Hellstrom <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agodrm/radeon: fix logic error in atombios_encoders.c
Alex Deucher [Wed, 14 Nov 2012 14:10:39 +0000 (09:10 -0500)]
drm/radeon: fix logic error in atombios_encoders.c

commit b9196395c905edec512dfd6690428084228c16ec upstream.


Reported-by: David Binderman <>
Signed-off-by: Alex Deucher <>
Reviewed-by: Michel Dänzer <>
Signed-off-by: Ben Hutchings <>
10 years agoUSB: option: add Alcatel X220/X500D USB IDs
Dan Williams [Thu, 8 Nov 2012 17:56:53 +0000 (11:56 -0600)]
USB: option: add Alcatel X220/X500D USB IDs

commit c0bc3098871dd9b964f6b45ec1e4d70d87811744 upstream.

Signed-off-by: Dan Williams <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
10 years agoUSB: option: add Novatel E362 and Dell Wireless 5800 USB IDs
Dan Williams [Thu, 8 Nov 2012 17:56:42 +0000 (11:56 -0600)]
USB: option: add Novatel E362 and Dell Wireless 5800 USB IDs

commit fcb21645f1bd86d2be29baf48aa1b298de52ccc7 upstream.

The Dell 5800 appears to be a simple rebrand of the Novatel E362.

Signed-off-by: Dan Williams <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
10 years agos390/gup: add missing TASK_SIZE check to get_user_pages_fast()
Heiko Carstens [Mon, 22 Oct 2012 13:49:02 +0000 (15:49 +0200)]
s390/gup: add missing TASK_SIZE check to get_user_pages_fast()

commit d55c4c613fc4d4ad2ba0fc6fa2b57176d420f7e4 upstream.

When walking page tables we need to make sure that everything
is within bounds of the ASCE limit of the task's address space.
Otherwise we might calculate e.g. a pud pointer which is not
within a pud and dereference it.
So check against TASK_SIZE (which is the ASCE limit) before
walking page tables.

Reviewed-by: Gerald Schaefer <>
Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
Signed-off-by: Ben Hutchings <>
10 years agodrm/i915/sdvo: clean up connectors on intel_sdvo_init() failures
Jani Nikula [Mon, 12 Nov 2012 16:31:35 +0000 (18:31 +0200)]
drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures

commit d0ddfbd3d1346c1f481ec2289eef350cdba64b42 upstream.

Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call
left behind ghost connectors, attached (with a dangling pointer) to the
sdvo that has been cleaned up and freed. Properly destroy any connectors
attached to the encoder.

CC: Chris Wilson <>
Signed-off-by: Jani Nikula <>
[danvet: added a comment to explain why we need to clean up connectors
even when sdvo_output_setup fails.]
Signed-off-by: Daniel Vetter <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
10 years agowireless: allow 40 MHz on world roaming channels 12/13
Johannes Berg [Mon, 12 Nov 2012 09:51:34 +0000 (10:51 +0100)]
wireless: allow 40 MHz on world roaming channels 12/13

commit 43c771a1963ab461a2f194e3c97fded1d5fe262f upstream.

When in world roaming mode, allow 40 MHz to be used
on channels 12 and 13 so that an AP that is, e.g.,
using HT40+ on channel 9 (in the UK) can be used.

Reported-by: Eddie Chapman <>
Tested-by: Eddie Chapman <>
Acked-by: Luis R. Rodriguez <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
10 years agos390/signal: set correct address space control
Martin Schwidefsky [Wed, 7 Nov 2012 09:44:08 +0000 (10:44 +0100)]
s390/signal: set correct address space control

commit fa968ee215c0ca91e4a9c3a69ac2405aae6e5d2f upstream.

If user space is running in primary mode it can switch to secondary
or access register mode, this is used e.g. in the clock_gettime code
of the vdso. If a signal is delivered to the user space process while
it has been running in access register mode the signal handler is
executed in access register mode as well which will result in a crash
most of the time.

Set the address space control bits in the PSW to the default for the
execution of the signal handler and make sure that the previous
address space control is restored on signal return. Take care
that user space can not switch to the kernel address space by
modifying the registers in the signal frame.

Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2:
 - Adjust filename
 - The RI bit is not included in PSW_MASK_USER]
Signed-off-by: Ben Hutchings <>
10 years agoASoC: dapm: Use card_list during DAPM shutdown
Misael Lopez Cruz [Thu, 8 Nov 2012 18:03:12 +0000 (12:03 -0600)]
ASoC: dapm: Use card_list during DAPM shutdown

commit 445632ad6dda42f4d3f9df2569a852ca0d4ea608 upstream.

DAPM shutdown incorrectly uses "list" field of codec struct while
iterating over probed components (codec_dev_list). "list" field
refers to codecs registered in the system, "card_list" field is
used for probed components.

Signed-off-by: Misael Lopez Cruz <>
Signed-off-by: Liam Girdwood <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
10 years agodevice_cgroup: fix RCU usage
Tejun Heo [Tue, 6 Nov 2012 17:17:37 +0000 (09:17 -0800)]
device_cgroup: fix RCU usage

commit 201e72acb2d3821e2de9ce6091e98859c316b29a upstream.

dev_cgroup->exceptions is protected with devcgroup_mutex for writes
and RCU for reads; however, RCU usage isn't correct.

* dev_exception_clean() doesn't use RCU variant of list_del() and
  kfree().  The function can race with may_access() and may_access()
  may end up dereferencing already freed memory.  Use list_del_rcu()
  and kfree_rcu() instead.

* may_access() may be called only with RCU read locked but doesn't use
  RCU safe traversal over ->exceptions.  Use list_for_each_entry_rcu().

Signed-off-by: Tejun Heo <>
Acked-by: Serge E. Hallyn <>
Cc: Aristeu Rozanski <>
Cc: Li Zefan <>
[bwh: Backported to 3.2:
 - Adjust context
 - Exception list is called whitelist]
Signed-off-by: Ben Hutchings <>
10 years agoASoC: wm8978: pll incorrectly configured when codec is master
Eric Millbrandt [Fri, 2 Nov 2012 21:05:44 +0000 (17:05 -0400)]
ASoC: wm8978: pll incorrectly configured when codec is master

commit 55c6f4cb6ef49afbb86222c6a3ff85329199c729 upstream.

When MCLK is supplied externally and BCLK and LRC are configured as outputs
(codec is master), the PLL values are only calculated correctly on the first
transmission.  On subsequent transmissions, at differenct sample rates, the
wrong PLL values are used.  Test for f_opclk instead of f_pllout to determine
if the PLL values are needed.

Signed-off-by: Eric Millbrandt <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
10 years agomac80211: sync acccess to tx_filtered/ps_tx_buf queues
Arik Nemtsov [Mon, 5 Nov 2012 08:27:52 +0000 (10:27 +0200)]
mac80211: sync acccess to tx_filtered/ps_tx_buf queues

commit 987c285c2ae2e4e32aca3a9b3252d28171c75711 upstream.

These are accessed without a lock when ending STA PSM. If the
sta_cleanup timer accesses these lists at the same time, we might crash.

This may fix some mysterious crashes we had during

Signed-off-by: Arik Nemtsov <>
Signed-off-by: Ido Yariv <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
10 years agofutex: Handle futex_pi OWNER_DIED take over correctly
Thomas Gleixner [Tue, 23 Oct 2012 20:29:38 +0000 (22:29 +0200)]
futex: Handle futex_pi OWNER_DIED take over correctly

commit 59fa6245192159ab5e1e17b8e31f15afa9cff4bf upstream.

Siddhesh analyzed a failure in the take over of pi futexes in case the
owner died and provided a workaround.

The detailed problem analysis shows:

Futex F is initialized with PTHREAD_PRIO_INHERIT and

T1 lock_futex_pi(F);

T2 lock_futex_pi(F);
   --> T2 blocks on the futex and creates pi_state which is associated
       to T1.

T1 exits
   --> exit_robust_list() runs
       --> Futex F userspace value TID field is set to 0 and
           FUTEX_OWNER_DIED bit is set.

T3 lock_futex_pi(F);
   --> Succeeds due to the check for F's userspace TID field == 0
   --> Claims ownership of the futex and sets its own TID into the
       userspace TID field of futex F
   --> returns to user space

T1 --> exit_pi_state_list()
       --> Transfers pi_state to waiter T2 and wakes T2 via

T2 --> acquires pi_state->mutex and gains real ownership of the
   --> Claims ownership of the futex and sets its own TID into the
       userspace TID field of futex F
   --> returns to user space

T3 --> observes inconsistent state

This problem is independent of UP/SMP, preemptible/non preemptible
kernels, or process shared vs. private. The only difference is that
certain configurations are more likely to expose it.

So as Siddhesh correctly analyzed the following check in
futex_lock_pi_atomic() is the culprit:

if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {

We check the userspace value for a TID value of 0 and take over the
futex unconditionally if that's true.

AFAICT this check is there as it is correct for a different corner
case of futexes: the WAITERS bit became stale.

Now the proposed change

- if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
+       if (unlikely(ownerdied ||
+                       !(curval & (FUTEX_TID_MASK | FUTEX_WAITERS)))) {

solves the problem, but it's not obvious why and it wreckages the
"stale WAITERS bit" case.

What happens is, that due to the WAITERS bit being set (T2 is blocked
on that futex) it enforces T3 to go through lookup_pi_state(), which
in the above case returns an existing pi_state and therefor forces T3
to legitimately fight with T2 over the ownership of the pi_state (via
pi_state->mutex). Probelm solved!

Though that does not work for the "WAITERS bit is stale" problem
because if lookup_pi_state() does not find existing pi_state it
returns -ERSCH (due to TID == 0) which causes futex_lock_pi() to
return -ESRCH to user space because the OWNER_DIED bit is not set.

Now there is a different solution to that problem. Do not look at the
user space value at all and enforce a lookup of possibly available
pi_state. If pi_state can be found, then the new incoming locker T3
blocks on that pi_state and legitimately races with T2 to acquire the
rt_mutex and the pi_state and therefor the proper ownership of the
user space futex.

lookup_pi_state() has the correct order of checks. It first tries to
find a pi_state associated with the user space futex and only if that
fails it checks for futex TID value = 0. If no pi_state is available
nothing can create new state at that point because this happens with
the hash bucket lock held.

So the above scenario changes to:

T1 lock_futex_pi(F);

T2 lock_futex_pi(F);
   --> T2 blocks on the futex and creates pi_state which is associated
       to T1.

T1 exits
   --> exit_robust_list() runs
       --> Futex F userspace value TID field is set to 0 and
           FUTEX_OWNER_DIED bit is set.

T3 lock_futex_pi(F);
   --> Finds pi_state and blocks on pi_state->rt_mutex

T1 --> exit_pi_state_list()
       --> Transfers pi_state to waiter T2 and wakes it via

T2 --> acquires pi_state->mutex and gains ownership of the pi_state
   --> Claims ownership of the futex and sets its own TID into the
       userspace TID field of futex F
   --> returns to user space

This covers all gazillion points on which T3 might come in between
T1's exit_robust_list() clearing the TID field and T2 fixing it up. It
also solves the "WAITERS bit stale" problem by forcing the take over.

Another benefit of changing the code this way is that it makes it less
dependent on untrusted user space values and therefor minimizes the
possible wreckage which might be inflicted.

As usual after staring for too long at the futex code my brain hurts
so much that I really want to ditch that whole optimization of
avoiding the syscall for the non contended case for PI futexes and rip
out the maze of corner case handling code. Unfortunately we can't as
user space relies on that existing behaviour, but at least thinking
about it helps me to preserve my mental sanity. Maybe we should
nevertheless :)

Reported-and-tested-by: Siddhesh Poyarekar <>
Acked-by: Darren Hart <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
10 years agoUBIFS: fix mounting problems after power cuts
Artem Bityutskiy [Tue, 9 Oct 2012 13:20:15 +0000 (16:20 +0300)]
UBIFS: fix mounting problems after power cuts

commit a28ad42a4a0c6f302f488f26488b8b37c9b30024 upstream.

This is a bugfix for a problem with the following symptoms:

1. A power cut happens
2. After reboot, we try to mount UBIFS
3. Mount fails with "No space left on device" error message

UBIFS complains like this:

UBIFS error (pid 28225): grab_empty_leb: could not find an empty LEB

The root cause of this problem is that when we mount, not all LEBs are
categorized. Only those which were read are. However, the
'ubifs_find_free_leb_for_idx()' function assumes that all LEBs were
categorized and 'c->freeable_cnt' is valid, which is a false assumption.

This patch fixes the problem by teaching 'ubifs_find_free_leb_for_idx()'
to always fall back to LPT scanning if no freeable LEBs were found.

This problem was reported by few people in the past, but Brent Taylor
was able to reproduce it and send me a flash image which cannot be mounted,
which made it easy to hunt the bug. Kudos to Brent.

Reported-by: Brent Taylor <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Ben Hutchings <>
10 years agoUBIFS: introduce categorized lprops counter
Artem Bityutskiy [Wed, 10 Oct 2012 07:55:28 +0000 (10:55 +0300)]
UBIFS: introduce categorized lprops counter

commit 98a1eebda3cb2a84ecf1f219bb3a95769033d1bf upstream.

This commit is a preparation for a subsequent bugfix. We introduce a
counter for categorized lprops.

Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Ben Hutchings <>
10 years agoLinux 3.2.34 v3.2.34
Ben Hutchings [Fri, 16 Nov 2012 16:47:22 +0000 (16:47 +0000)]
Linux 3.2.34

10 years agoALSA: usb-audio: Fix mutex deadlock at disconnection
Takashi Iwai [Tue, 13 Nov 2012 10:22:48 +0000 (11:22 +0100)]
ALSA: usb-audio: Fix mutex deadlock at disconnection

commit 10e44239f67d0b6fb74006e61a7e883b8075247a upstream.

The recent change for USB-audio disconnection race fixes introduced a
mutex deadlock again.  There is a circular dependency between
chip->shutdown_rwsem and pcm->open_mutex, depicted like below, when a
device is opened during the disconnection operation:

A. snd_usb_audio_disconnect() ->
     card.c::register_mutex ->
       chip->shutdown_rwsem (write) ->
         snd_card_disconnect() ->
           pcm.c::register_mutex ->

B. snd_pcm_open() ->
     pcm->open_mutex ->
       snd_usb_pcm_open() ->
         chip->shutdown_rwsem (read)

Since the chip->shutdown_rwsem protection in the case A is required
only for turning on the chip->shutdown flag and it doesn't have to be
taken for the whole operation, we can reduce its window in

Reported-by: Jiri Slaby <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
10 years agosky2: Fix for interrupt handler
Mirko Lindner [Tue, 3 Jul 2012 23:38:46 +0000 (23:38 +0000)]
sky2: Fix for interrupt handler

commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream.

Re-enable interrupts if it is not our interrupt

Signed-off-by: Mirko Lindner <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agor8169: use unlimited DMA burst for TX
Michal Schmidt [Sun, 9 Sep 2012 13:55:26 +0000 (13:55 +0000)]
r8169: use unlimited DMA burst for TX

commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream.

The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
a box where this prevents the interface from using the gigabit line to its full
potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.

The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
(XID 0c900880). TSO is enabled.

I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
'7'=unlimited). This chart shows the results:

Interesting points:
 - With the current DMA burst limit (1024):
   - at the default MTU=1500 I get only 842 Mbit/s.
   - when going from small MTU, the performance rises monotonically with
     increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
     a sudden drop to 762 MBit/s from which the throughput rises monotonically
     again with further MTU increases.
 - With a smaller DMA burst limit (512):
   - there's a similar peak at MTU=1076 and another one at MTU=564.
 - With unlimited DMA burst:
   - at the default MTU=1500 I get nice 940 Mbit/s.
   - the throughput rises monotonically with increasing MTU with no strange

Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
limit plus 52. Why 52? Because:
  20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52

The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
the smaller burst limit, or if any other versions have similar requirements.

Signed-off-by: Michal Schmidt <>
Acked-by: Francois Romieu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agor8169: Fix WoL on RTL8168d/8111d.
Cyril Brulebois [Wed, 31 Oct 2012 14:00:46 +0000 (14:00 +0000)]
r8169: Fix WoL on RTL8168d/8111d.

commit b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd upstream.

This regression was spotted between Debian squeeze and Debian wheezy
kernels (respectively based on 2.6.32 and 3.2). More info about
Wake-on-LAN issues with Realtek's 816x chipsets can be found in the
following thread:

Probable regression from d4ed95d796e5126bba51466dc07e287cebc8bd19;
more chipsets are likely affected.

Tested on top of a 3.2.23 kernel.

Reported-by: Florent Fourcot <>
Tested-by: Florent Fourcot <>
Hinted-by: Francois Romieu <>
Signed-off-by: Cyril Brulebois <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agor8169: allow multicast packets on sub-8168f chipset.
Nathan Walp [Thu, 1 Nov 2012 12:08:47 +0000 (12:08 +0000)]
r8169: allow multicast packets on sub-8168f chipset.

commit 0481776b7a70f09acf7d9d97c288c3a8403fbfe4 upstream.

RTL_GIGA_MAC_VER_35 includes no multicast hardware filter.

Signed-off-by: Nathan Walp <>
Suggested-by: Hayes Wang <>
Acked-by: Francois Romieu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agoeCryptfs: check for eCryptfs cipher support at mount
Tim Sally [Thu, 12 Jul 2012 23:10:24 +0000 (19:10 -0400)]
eCryptfs: check for eCryptfs cipher support at mount

commit 5f5b331d5c21228a6519dcb793fc1629646c51a6 upstream.

The issue occurs when eCryptfs is mounted with a cipher supported by
the crypto subsystem but not by eCryptfs. The mount succeeds and an
error does not occur until a write. This change checks for eCryptfs
cipher support at mount time.

Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009.

Signed-off-by: Tim Sally <>
Signed-off-by: Tyler Hicks <>
Signed-off-by: Ben Hutchings <>
10 years agoeCryptfs: Copy up POSIX ACL and read-only flags from lower mount
Tyler Hicks [Mon, 11 Jun 2012 22:42:32 +0000 (15:42 -0700)]
eCryptfs: Copy up POSIX ACL and read-only flags from lower mount

commit 069ddcda37b2cf5bb4b6031a944c0e9359213262 upstream.

When the eCryptfs mount options do not include '-o acl', but the lower
filesystem's mount options do include 'acl', the MS_POSIXACL flag is not
flipped on in the eCryptfs super block flags. This flag is what the VFS
checks in do_last() when deciding if the current umask should be applied
to a newly created inode's mode or not. When a default POSIX ACL mask is
set on a directory, the current umask is incorrectly applied to new
inodes created in the directory. This patch ignores the MS_POSIXACL flag
passed into ecryptfs_mount() and sets the flag on the eCryptfs super
block depending on the flag's presence on the lower super block.

Additionally, it is incorrect to allow a writeable eCryptfs mount on top
of a read-only lower mount. This missing check did not allow writes to
the read-only lower mount because permissions checks are still performed
on the lower filesystem's objects but it is best to simply not allow a
rw mount on top of ro mount. However, a ro eCryptfs mount on top of a rw
mount is valid and still allowed.

Signed-off-by: Tyler Hicks <>
Reported-by: Stefan Beller <>
Cc: John Johansen <>
Signed-off-by: Ben Hutchings <>
10 years agoipv6: send unsolicited neighbour advertisements to all-nodes
Hannes Frederic Sowa [Tue, 6 Nov 2012 16:18:41 +0000 (16:18 +0000)]
ipv6: send unsolicited neighbour advertisements to all-nodes

[ Upstream commit 60713a0ca7fd6651b951cc1b4dbd528d1fc0281b ]

As documented in RFC4861 (Neighbor Discovery for IP version 6) 7.2.6.,
unsolicited neighbour advertisements should be sent to the all-nodes
multicast address.

Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agoaf-packet: fix oops when socket is not present
Eric Leblond [Tue, 6 Nov 2012 02:10:10 +0000 (02:10 +0000)]
af-packet: fix oops when socket is not present

[ Upstream commit a3d744e995d2b936c500585ae39d99ee251c89b4 ]

Due to a NULL dereference, the following patch is causing oops
in normal trafic condition:

commit c0de08d04215031d68fa13af36f347a6cfa252ca
Author: Eric Leblond <>
Date:   Thu Aug 16 22:02:58 2012 +0000

    af_packet: don't emit packet on orig fanout group

This buggy patch was a feature fix and has reached most stable

When skb->sk is NULL and when packet fanout is used, there is a
crash in match_fanout_group where skb->sk is accessed.
This patch fixes the issue by returning false as soon as the
socket is NULL: this correspond to the wanted behavior because
the kernel as to resend the skb to all the listening socket in
this case.

Signed-off-by: Eric Leblond <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
10 years agol2tp: fix oops in l2tp_eth_create() error path
Tom Parkin [Mon, 29 Oct 2012 23:41:48 +0000 (23:41 +0000)]
l2tp: fix oops in l2tp_eth_create() error path

[ Upstream commit 789336360e0a2aeb9750c16ab704a02cbe035e9e ]

When creating an L2TPv3 Ethernet session, if register_netdev() should fail for
any reason (for example, automatic naming for "l2tpeth%d" interfaces hits the
32k-interface limit), the netdev is freed in the error path.  However, the
l2tp_eth_sess structure's dev pointer is left uncleared, and this results in
l2tp_eth_delete() then attempting to unregister the same netdev later in the
session teardown.  This results in an oops.

To avoid this, clear the session dev pointer in the error path.

Signed-off-by: Tom Parkin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>