8 years agoKVM: x86: Emulator fixes for eip canonical checks on near branches
Nadav Amit [Thu, 18 Sep 2014 19:39:38 +0000 (22:39 +0300)]
KVM: x86: Emulator fixes for eip canonical checks on near branches

commit 234f3ce485d54017f15cf5e0699cff4100121601 upstream.

Before changing rip (during jmp, call, ret, etc.) the target should be asserted
to be canonical one, as real CPUs do.  During sysret, both target rsp and rip
should be canonical. If any of these values is noncanonical, a #GP exception
should occur.  The exception to this rule are syscall and sysenter instructions
in which the assigned rip is checked during the assignment to the relevant

This patch fixes the emulator to behave as real CPUs do for near branches.
Far branches are handled by the next patch.

This fixes CVE-2014-3647.

Signed-off-by: Nadav Amit <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use ctxt->regs[] instead of reg_read(), reg_write(), reg_rmw()]
Signed-off-by: Ben Hutchings <>
8 years agoKVM: x86: Fix wrong masking on relative jump/call
Nadav Amit [Thu, 18 Sep 2014 19:39:37 +0000 (22:39 +0300)]
KVM: x86: Fix wrong masking on relative jump/call

commit 05c83ec9b73c8124555b706f6af777b10adf0862 upstream.

Relative jumps and calls do the masking according to the operand size, and not
according to the address size as the KVM emulator does today.

This patch fixes KVM behavior.

Signed-off-by: Nadav Amit <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
8 years agoKVM: x86 emulator: Use opcode::execute for CALL
Takuya Yoshikawa [Tue, 22 Nov 2011 06:18:35 +0000 (15:18 +0900)]
KVM: x86 emulator: Use opcode::execute for CALL

commit d4ddafcdf2201326ec9717172767cfad0ede1472 upstream.


Signed-off-by: Takuya Yoshikawa <>
Signed-off-by: Marcelo Tosatti <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agokvm: vmx: handle invvpid vm exit gracefully
Petr Matousek [Tue, 23 Sep 2014 18:22:30 +0000 (20:22 +0200)]
kvm: vmx: handle invvpid vm exit gracefully

commit a642fc305053cc1c6e47e4f4df327895747ab485 upstream.

On systems with invvpid instruction support (corresponding bit in
IA32_VMX_EPT_VPID_CAP MSR is set) guest invocation of invvpid
causes vm exit, which is currently not handled and results in
propagation of unknown exit to userspace.

Fix this by installing an invvpid vm exit handler.

This is CVE-2014-3646.

Signed-off-by: Petr Matousek <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - Adjust filename
 - Drop inapplicable change to exit reason string array]
Signed-off-by: Ben Hutchings <>
8 years agonEPT: Nested INVEPT
Nadav Har'El [Mon, 5 Aug 2013 08:07:17 +0000 (11:07 +0300)]

commit bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream.

If we let L1 use EPT, we should probably also support the INVEPT instruction.

In our current nested EPT implementation, when L1 changes its EPT table
for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in
the course of this modification already calls INVEPT. But if last level
of shadow page is unsync not all L1's changes to EPT12 are intercepted,
which means roots need to be synced when L1 calls INVEPT. Global INVEPT
should not be different since roots are synced by kvm_mmu_load() each
time EPTP02 changes.

Reviewed-by: Xiao Guangrong <>
Signed-off-by: Nadav Har'El <>
Signed-off-by: Jun Nakajima <>
Signed-off-by: Xinhao Xu <>
Signed-off-by: Yang Zhang <>
Signed-off-by: Gleb Natapov <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - Adjust context, filename
 - Simplify handle_invept() as recommended by Paolo - nEPT is not
   supported so we always raise #UD]
Signed-off-by: Ben Hutchings <>
8 years agoKVM: x86: Improve thread safety in pit
Andy Honig [Wed, 27 Aug 2014 21:42:54 +0000 (14:42 -0700)]
KVM: x86: Improve thread safety in pit

commit 2febc839133280d5a5e8e1179c94ea674489dae2 upstream.

There's a race condition in the PIT emulation code in KVM.  In
__kvm_migrate_pit_timer the pit_timer object is accessed without
synchronization.  If the race condition occurs at the wrong time this
can crash the host kernel.

This fixes CVE-2014-3611.

Signed-off-by: Andrew Honig <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoKVM: x86: Check non-canonical addresses upon WRMSR
Nadav Amit [Tue, 16 Sep 2014 00:24:05 +0000 (03:24 +0300)]
KVM: x86: Check non-canonical addresses upon WRMSR

commit 854e8bb1aa06c578c2c9145fa6bfe3680ef63b23 upstream.

Upon WRMSR, the CPU should inject #GP if a non-canonical value (address) is
written to certain MSRs. The behavior is "almost" identical for AMD and Intel
(ignoring MSRs that are not implemented in either architecture since they would
anyhow #GP). However, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP cause #GP if
non-canonical address is written on Intel but not on AMD (which ignores the top

Accordingly, this patch injects a #GP on the MSRs which behave identically on
Intel and AMD.  To eliminate the differences between the architecutres, the
value which is written to IA32_SYSENTER_ESP and IA32_SYSENTER_EIP is turned to
canonical value before writing instead of injecting a #GP.

Some references from Intel and AMD manuals:

According to Intel SDM description of WRMSR instruction #GP is expected on
WRMSR "If the source register contains a non-canonical address and ECX
specifies one of the following MSRs: IA32_DS_AREA, IA32_FS_BASE, IA32_GS_BASE,

According to AMD manual instruction manual:
LSTAR/CSTAR (SYSCALL): "The WRMSR instruction loads the target RIP into the
LSTAR and CSTAR registers.  If an RIP written by WRMSR is not in canonical
form, a general-protection exception (#GP) occurs."
IA32_GS_BASE and IA32_FS_BASE (WRFSBASE/WRGSBASE): "The address written to the
base field must be in canonical form or a #GP fault will occur."
IA32_KERNEL_GS_BASE (SWAPGS): "The address stored in the KernelGSbase MSR must
be in canonical form."

This patch fixes CVE-2014-3610.

Signed-off-by: Nadav Amit <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - The various set_msr() functions all separate msr_index and data parameters]
Signed-off-by: Ben Hutchings <>
8 years agoipv6: reuse ip6_frag_id from ip6_ufo_append_data
Hannes Frederic Sowa [Fri, 21 Feb 2014 01:55:35 +0000 (02:55 +0100)]
ipv6: reuse ip6_frag_id from ip6_ufo_append_data

commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6 upstream.

Currently we generate a new fragmentation id on UFO segmentation. It
is pretty hairy to identify the correct net namespace and dst there.
Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst
available at all.

This causes unreliable or very predictable ipv6 fragmentation id
generation while segmentation.

Luckily we already have pregenerated the ip6_frag_id in
ip6_ufo_append_data and can use it here.

Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust filename, indentation]
Signed-off-by: Ben Hutchings <>
8 years agoext4: fix BUG_ON in mb_free_blocks()
Theodore Ts'o [Sat, 23 Aug 2014 21:47:28 +0000 (17:47 -0400)]
ext4: fix BUG_ON in mb_free_blocks()

commit c99d1e6e83b06744c75d9f5e491ed495a7086b7b upstream.

If we suffer a block allocation failure (for example due to a memory
allocation failure), it's possible that we will call
ext4_discard_allocated_blocks() before we've actually allocated any
blocks.  In that case, fe_len and fe_start in ac->ac_f_ex will still
be zero, and this will result in mb_free_blocks(inode, e4b, 0, 0)
triggering the BUG_ON on mb_free_blocks():

BUG_ON(last >= (sb->s_blocksize << 3));

Fix this by bailing out of ext4_discard_allocated_blocks() if fs_len
is zero.

Also fix a missing ext4_mb_unload_buddy() call in

Google-Bug-Id: 16844242

Fixes: 86f0afd463215fc3e58020493482faa4ac3a4d69
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoipv6: reallocate addrconf router for ipv6 address when lo device up
chenweilong [Wed, 6 Aug 2014 08:18:17 +0000 (16:18 +0800)]
ipv6: reallocate addrconf router for ipv6 address when lo device up

It fix the bug 67951 on bugzilla

The patch can't be applied directly, as it' used the function introduced
by "commit 94e187c0" ip6_rt_put(), that patch can't be applied directly


From: Gao feng <>

commit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream.

This commit don't have a stable tag, but it fix the bug
no reply after loopback down-up.It's very worthy to be
applied to stable 3.4 kernels.

The bug is 67951 on bugzilla

CC: Sabrina Dubroca <>
CC: Hannes Frederic Sowa <>
Reported-by: Weilong Chen <>
Signed-off-by: Weilong Chen <>
Signed-off-by: Gao feng <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
[weilong: s/ip6_rt_put/dst_release]
Signed-off-by: Chen Weilong <>
Signed-off-by: Ben Hutchings <>
8 years agoipv4: disable bh while doing route gc
Marcelo Ricardo Leitner [Mon, 13 Oct 2014 17:03:30 +0000 (14:03 -0300)]
ipv4: disable bh while doing route gc

Further tests revealed that after moving the garbage collector to a work
queue and protecting it with a spinlock may leave the system prone to
soft lockups if bottom half gets very busy.

It was reproced with a set of firewall rules that REJECTed packets. If
the NIC bottom half handler ends up running on the same CPU that is
running the garbage collector on a very large cache, the garbage
collector will not be able to do its job due to the amount of work
needed for handling the REJECTs and also won't reschedule.

The fix is to disable bottom half during the garbage collecting, as it
already was in the first place (most calls to it came from softirqs).

Signed-off-by: Marcelo Ricardo Leitner <>
Acked-by: Hannes Frederic Sowa <>
Acked-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
8 years agoipv4: avoid parallel route cache gc executions
Marcelo Ricardo Leitner [Thu, 14 Aug 2014 19:44:53 +0000 (16:44 -0300)]
ipv4: avoid parallel route cache gc executions

When rt_intern_hash() has to deal with neighbour cache overflowing,
it triggers the route cache garbage collector in an attempt to free
some references on neighbour entries.

Such call cannot be done async but should also not run in parallel with
an already-running one, so that they don't collapse fighting over the
hash lock entries.

This patch thus blocks parallel executions with spinlocks:
- A call from worker and from rt_intern_hash() are not the same, and
cannot be merged, thus they will wait each other on rt_gc_lock.
- Calls to gc from rt_intern_hash() may happen in parallel but we must
wait for it to finish in order to try again. This dedup and
synchrinozation is then performed by the locking just before calling

Signed-off-by: Marcelo Ricardo Leitner <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: Ben Hutchings <>
8 years agoipv4: move route garbage collector to work queue
Marcelo Ricardo Leitner [Thu, 14 Aug 2014 19:44:52 +0000 (16:44 -0300)]
ipv4: move route garbage collector to work queue

Currently the route garbage collector gets called by dst_alloc() if it
have more entries than the threshold. But it's an expensive call, that
don't really need to be done by then.

Another issue with current way is that it allows running the garbage
collector with the same start parameters on multiple CPUs at once, which
is not optimal. A system may even soft lockup if the cache is big enough
as the garbage collectors will be fighting over the hash lock entries.

This patch thus moves the garbage collector to run asynchronously on a
work queue, much similar to how rt_expire_check runs.

There is one condition left that allows multiple executions, which is
handled by the next patch.

Signed-off-by: Marcelo Ricardo Leitner <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: Ben Hutchings <>
8 years agoMIPS: Fix forgotten preempt_enable() when CPU has inclusive pcaches
Yoichi Yuasa [Wed, 2 Oct 2013 06:03:03 +0000 (15:03 +0900)]
MIPS: Fix forgotten preempt_enable() when CPU has inclusive pcaches

commit 5596b0b245fb9d2cefb5023b11061050351c1398 upstream.

[    1.904000] BUG: scheduling while atomic: swapper/1/0x00000002
[    1.908000] Modules linked in:
[    1.916000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc2-lemote-los.git-5318619-dirty #1
[    1.920000] Stack : 0000000031aac000 ffffffff810d0000 0000000000000052 ffffffff802730a4
          0000000000000000 0000000000000001 ffffffff810cdf90 ffffffff810d0000
          ffffffff8068b968 ffffffff806f5537 ffffffff810cdf90 980000009f0782e8
          0000000000000001 ffffffff80720000 ffffffff806b0000 980000009f078000
          980000009f290000 ffffffff805f312c 980000009f05b5d8 ffffffff80233518
          980000009f05b5e8 ffffffff80274b7c 980000009f078000 ffffffff8068b968
          0000000000000000 0000000000000000 0000000000000000 0000000000000000
          0000000000000000 980000009f05b520 0000000000000000 ffffffff805f2f6c
          0000000000000000 ffffffff80700000 ffffffff80700000 ffffffff806fc758
          ffffffff80700000 ffffffff8020be98 ffffffff806fceb0 ffffffff805f2f6c
[    2.028000] Call Trace:
[    2.032000] [<ffffffff8020be98>] show_stack+0x80/0x98
[    2.036000] [<ffffffff805f2f6c>] __schedule_bug+0x44/0x6c
[    2.040000] [<ffffffff805fac58>] __schedule+0x518/0x5b0
[    2.044000] [<ffffffff805f8a58>] schedule_timeout+0x128/0x1f0
[    2.048000] [<ffffffff80240314>] msleep+0x3c/0x60
[    2.052000] [<ffffffff80495400>] do_probe+0x238/0x3a8
[    2.056000] [<ffffffff804958b0>] ide_probe_port+0x340/0x7e8
[    2.060000] [<ffffffff80496028>] ide_host_register+0x2d0/0x7a8
[    2.064000] [<ffffffff8049c65c>] ide_pci_init_two+0x4e4/0x790
[    2.068000] [<ffffffff8049f9b8>] amd74xx_probe+0x148/0x2c8
[    2.072000] [<ffffffff803f571c>] pci_device_probe+0xc4/0x130
[    2.076000] [<ffffffff80478f60>] driver_probe_device+0x98/0x270
[    2.080000] [<ffffffff80479298>] __driver_attach+0xe0/0xe8
[    2.084000] [<ffffffff80476ab0>] bus_for_each_dev+0x78/0xe0
[    2.088000] [<ffffffff80478468>] bus_add_driver+0x230/0x310
[    2.092000] [<ffffffff80479b44>] driver_register+0x84/0x158
[    2.096000] [<ffffffff80200504>] do_one_initcall+0x104/0x160

Signed-off-by: Yoichi Yuasa <>
Reported-by: Aaro Koskinen <>
Tested-by: Aaro Koskinen <>
Cc: Linux Kernel Mailing List <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
8 years agoinit/Kconfig: Hide printk log config if CONFIG_PRINTK=n
Josh Triplett [Fri, 3 Oct 2014 23:00:54 +0000 (16:00 -0700)]
init/Kconfig: Hide printk log config if CONFIG_PRINTK=n

commit 361e9dfbaae84b0b246ed18d1ab7c82a1a41b53e upstream.

The buffers sized by CONFIG_LOG_BUF_SHIFT and
CONFIG_LOG_CPU_MAX_BUF_SHIFT do not exist if CONFIG_PRINTK=n, so don't
ask about their size at all.

Signed-off-by: Josh Triplett <>
Acked-by: Randy Dunlap <>
[bwh: Backported to 3.2: drop change to CONFIG_LOG_CPU_MAX_BUF_SHIFT]
Signed-off-by: Ben Hutchings <>
8 years agoperf: fix perf bug in fork()
Peter Zijlstra [Thu, 2 Oct 2014 23:17:02 +0000 (16:17 -0700)]
perf: fix perf bug in fork()

commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream.

Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by
calling perf_event_free_task() when failing sched_fork() we will not yet
have done the memset() on ->perf_event_ctxp[] and will therefore try and
'free' the inherited contexts, which are still in use by the parent
process.  This is bad..

Suggested-by: Oleg Nesterov <>
Reported-by: Oleg Nesterov <>
Reported-by: Sylvain 'ythier' Hitier <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Ingo Molnar <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
8 years agomm: migrate: Close race between migration completion and mprotect
Mel Gorman [Thu, 2 Oct 2014 18:47:41 +0000 (19:47 +0100)]
mm: migrate: Close race between migration completion and mprotect

commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream.

A migration entry is marked as write if pte_write was true at the time the
entry was created. The VMA protections are not double checked when migration
entries are being removed as mprotect marks write-migration-entries as
read. It means that potentially we take a spurious fault to mark PTEs write
again but it's straight-forward. However, there is a race between write
migrations being marked read and migrations finishing. This potentially
allows a PTE to be write that should have been read. Close this race by
double checking the VMA permissions using maybe_mkwrite when migration

[ use maybe_mkwrite]
Signed-off-by: Mel Gorman <>
Acked-by: Rik van Riel <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoshmem: fix nlink for rename overwrite directory
Miklos Szeredi [Wed, 24 Sep 2014 15:56:17 +0000 (17:56 +0200)]
shmem: fix nlink for rename overwrite directory

commit b928095b0a7cff7fb9fcf4c706348ceb8ab2c295 upstream.

If overwriting an empty directory with rename, then need to drop the extra

Test prog:

#include <stdio.h>
#include <fcntl.h>
#include <err.h>
#include <sys/stat.h>

int main(void)
const char *test_dir1 = "test-dir1";
const char *test_dir2 = "test-dir2";
int res;
int fd;
struct stat statbuf;

res = mkdir(test_dir1, 0777);
if (res == -1)
err(1, "mkdir(\"%s\")", test_dir1);

res = mkdir(test_dir2, 0777);
if (res == -1)
err(1, "mkdir(\"%s\")", test_dir2);

fd = open(test_dir2, O_RDONLY);
if (fd == -1)
err(1, "open(\"%s\")", test_dir2);

res = rename(test_dir1, test_dir2);
if (res == -1)
err(1, "rename(\"%s\", \"%s\")", test_dir1, test_dir2);

res = fstat(fd, &statbuf);
if (res == -1)
err(1, "fstat(%i)", fd);

if (statbuf.st_nlink != 0) {
fprintf(stderr, "nlink is %lu, should be 0\n", statbuf.st_nlink);
return 1;

return 0;

Signed-off-by: Miklos Szeredi <>
Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
8 years agoocfs2/dlm: do not get resource spinlock if lockres is new
Joseph Qi [Thu, 25 Sep 2014 23:05:16 +0000 (16:05 -0700)]
ocfs2/dlm: do not get resource spinlock if lockres is new

commit 5760a97c7143c208fa3a8f8cad0ed7dd672ebd28 upstream.

There is a deadlock case which reported by Guozhonghua:

This case is caused by &res->spinlock and &dlm->master_lock
misordering in different threads.

It was introduced by commit 8d400b81cc83 ("ocfs2/dlm: Clean up refmap
helpers").  Since lockres is new, it doesn't not require the
&res->spinlock.  So remove it.

Fixes: 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers")
Signed-off-by: Joseph Qi <>
Reviewed-by: joyce.xue <>
Reported-by: Guozhonghua <>
Cc: Joel Becker <>
Cc: Mark Fasheh <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
8 years agonilfs2: fix data loss with mmap()
Andreas Rohner [Thu, 25 Sep 2014 23:05:14 +0000 (16:05 -0700)]
nilfs2: fix data loss with mmap()

commit 56d7acc792c0d98f38f22058671ee715ff197023 upstream.

This bug leads to reproducible silent data loss, despite the use of
msync(), sync() and a clean unmount of the file system.  It is easily
reproducible with the following script:

  ----------------[BEGIN SCRIPT]--------------------
  mkfs.nilfs2 -f /dev/sdb
  mount /dev/sdb /mnt

  dd if=/dev/zero bs=1M count=30 of=/mnt/testfile

  umount /mnt
  mount /dev/sdb /mnt
  CHECKSUM_BEFORE="$(md5sum /mnt/testfile)"

  /root/mmaptest/mmaptest /mnt/testfile 30 10 5

  CHECKSUM_AFTER="$(md5sum /mnt/testfile)"
  umount /mnt
  mount /dev/sdb /mnt
  CHECKSUM_AFTER_REMOUNT="$(md5sum /mnt/testfile)"
  umount /mnt

  ----------------[END SCRIPT]--------------------

The mmaptest tool looks something like this (very simplified, with
error checking removed):

  ----------------[BEGIN mmaptest]--------------------
  data = mmap(NULL, file_size - file_offset, PROT_READ | PROT_WRITE,
              MAP_SHARED, fd, file_offset);

  for (i = 0; i < write_count; ++i) {
        memcpy(data + i * 4096, buf, sizeof(buf));
        msync(data, file_size - file_offset, MS_SYNC))
  ----------------[END mmaptest]--------------------

The output of the script looks something like this:

  BEFORE MMAP:    281ed1d5ae50e8419f9b978aab16de83  /mnt/testfile
  AFTER MMAP:     6604a1c31f10780331a6850371b3a313  /mnt/testfile
  AFTER REMOUNT:  281ed1d5ae50e8419f9b978aab16de83  /mnt/testfile

So it is clear, that the changes done using mmap() do not survive a
remount.  This can be reproduced a 100% of the time.  The problem was
introduced in commit 136e8770cd5d ("nilfs2: fix issue of
nilfs_set_page_dirty() for page at EOF boundary").

If the page was read with mpage_readpage() or mpage_readpages() for
example, then it has no buffers attached to it.  In that case
page_has_buffers(page) in nilfs_set_page_dirty() will be false.
Therefore nilfs_set_file_dirty() is never called and the pages are never
collected and never written to disk.

This patch fixes the problem by also calling nilfs_set_file_dirty() if the
page has no buffers attached to it.

Signed-off-by: Andreas Rohner <>
Tested-by: Andreas Rohner <>
Signed-off-by: Ryusuke Konishi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
8 years agoMIPS: mcount: Adjust stack pointer for static trace in MIPS32
Markos Chandras [Tue, 16 Sep 2014 14:55:12 +0000 (15:55 +0100)]
MIPS: mcount: Adjust stack pointer for static trace in MIPS32

commit 8a574cfa2652545eb95595d38ac2a0bb501af0ae upstream.

Every mcount() call in the MIPS 32-bit kernel is done as follows:

move at, ra
jal _mcount
addiu sp, sp, -8

but upon returning from the mcount() function, the stack pointer
is not adjusted properly. This is explained in details in 58b69401c797
(MIPS: Function tracer: Fix broken function tracing).

Commit ad8c396936e3 ("MIPS: Unbreak function tracer for 64-bit kernel.)
fixed the stack manipulation for 64-bit but it didn't fix it completely
for MIPS32.

Signed-off-by: Markos Chandras <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
8 years agoARM: 8165/1: alignment: don't break misaligned NEON load/store
Robin Murphy [Thu, 25 Sep 2014 10:56:19 +0000 (11:56 +0100)]
ARM: 8165/1: alignment: don't break misaligned NEON load/store

commit 5ca918e5e3f9df4634077c06585c42bc6a8d699a upstream.

The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn
instructions (where the optional alignment hint is given but incorrect)
as LDR/STR, leading to register corruption. Detect these and correctly
treat them as unhandled, so that userspace gets the fault it expects.

Reported-by: Simon Hosie <>
Signed-off-by: Robin Murphy <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
8 years agosched: Fix unreleased llc_shared_mask bit during CPU hotplug
Wanpeng Li [Wed, 24 Sep 2014 08:38:05 +0000 (16:38 +0800)]
sched: Fix unreleased llc_shared_mask bit during CPU hotplug

commit 03bd4e1f7265548832a76e7919a81f3137c44fd1 upstream.

The following bug can be triggered by hot adding and removing a large number of
xen domain0's vcpus repeatedly:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group
PGD 5a9d5067 PUD 13067 PMD 0
Oops: 0000 [#3] SMP
Call Trace:
? _raw_spin_unlock_irqrestore
? lock_timer_base

Last level cache shared mask is built during CPU up and the
build_sched_domain() routine takes advantage of it to setup
the sched domain CPU topology.

However, llc_shared_mask is not released during CPU disable,
which leads to an invalid sched domainCPU topology.

This patch fix it by releasing the llc_shared_mask correctly
during CPU disable.

Yasuaki also reported that this can happen on real hardware:

His case is here:

Here is an example on my system.
My system has 4 sockets and each socket has 15 cores and HT is
enabled. In this case, each core of sockes is numbered as

 | CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-44, 90-104
Socket#3 | 45-59, 105-119

Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000.

It means that last level cache of Socket#2 is shared with
CPU#30-44 and 90-104.

When hot-removing socket#2 and #3, each core of sockets is
numbered as follows:

 | CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89

But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30
remains having 0x3fff80000001fffc0000000.

After that, when hot-adding socket#2 and #3, each core of
sockets is numbered as follows:

 | CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-59
Socket#3 | 90-119

Then llc_shared_mask of CPU#30 becomes
0x3fff8000fffffffc0000000. It means that last level cache of
Socket#2 is shared with CPU#30-59 and 90-104. So the mask has
the wrong value.

Signed-off-by: Wanpeng Li <>
Tested-by: Linn Crosetto <>
Reviewed-by: Borislav Petkov <>
Reviewed-by: Toshi Kani <>
Reviewed-by: Yasuaki Ishimatsu <>
Cc: David Rientjes <>
Cc: Prarit Bhargava <>
Cc: Steven Rostedt <>
Cc: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
8 years agoparisc: Only use -mfast-indirect-calls option for 32-bit kernel builds
John David Anglin [Tue, 23 Sep 2014 00:54:50 +0000 (20:54 -0400)]
parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds

commit d26a7730b5874a5fa6779c62f4ad7c5065a94723 upstream.

In spite of what the GCC manual says, the -mfast-indirect-calls has
never been supported in the 64-bit parisc compiler. Indirect calls have
always been done using function descriptors irrespective of the
-mfast-indirect-calls option.

Recently, it was noticed that a function descriptor was always requested
when the -mfast-indirect-calls option was specified. This caused
problems when the option was used in  application code and doesn't make
any sense because the whole point of the option is to avoid using a
function descriptor for indirect calls.

Fixing this broke 64-bit kernel builds.

I will fix GCC but for now we need the attached change. This results in
the same kernel code as before.

Signed-off-by: John David Anglin <>
Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
8 years agoFix nasty 32-bit overflow bug in buffer i/o code.
Anton Altaparmakov [Mon, 22 Sep 2014 00:53:03 +0000 (01:53 +0100)]
Fix nasty 32-bit overflow bug in buffer i/o code.

commit f2d5a94436cc7cc0221b9a81bba2276a25187dd3 upstream.

On 32-bit architectures, the legacy buffer_head functions are not always
handling the sector number with the proper 64-bit types, and will thus
fail on 4TB+ disks.

Any code that uses __getblk() (and thus bread(), breadahead(),
sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit
block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop
in __getblk_slow() with an infinite stream of errors logged to dmesg
like this:

  __find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648
  b_state=0x00000020, b_size=512
  device sda1 blocksize: 512

Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the
top 32-bits are missing (in this case the 0x1 at the top).

This is because grow_dev_page() is broken and has a 32-bit overflow due
to shifting the page index value (a pgoff_t - which is just 32 bits on
32-bit architectures) left-shifted as the block number.  But the top
bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit
before the shift.

This patch fixes this issue by type casting "index" to sector_t before
doing the left shift.

Note this is not a theoretical bug but has been seen in the field on a
4TiB hard drive with logical sector size 512 bytes.

This patch has been verified to fix the infinite loop problem on 3.17-rc5
kernel using a 4TB disk image mounted using "-o loop".  Without this patch
doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop
100% reproducibly whilst with the patch it works fine as expected.

Signed-off-by: Anton Altaparmakov <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
8 years agoALSA: pcm: fix fifo_size frame calculation
Clemens Ladisch [Sun, 21 Sep 2014 20:50:57 +0000 (22:50 +0200)]
ALSA: pcm: fix fifo_size frame calculation

commit a9960e6a293e6fc3ed414643bb4e4106272e4d0a upstream.

The calculated frame size was wrong because snd_pcm_format_physical_width()
actually returns the number of bits, not bytes.

Use snd_pcm_format_size() instead, which not only returns bytes, but also
simplifies the calculation.

Fixes: 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling")
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
8 years agocan: at91_can: add missing prepare and unprepare of the clock
David Dueck [Wed, 17 Sep 2014 12:26:48 +0000 (14:26 +0200)]
can: at91_can: add missing prepare and unprepare of the clock

commit e77980e50bc2850599d4d9c0192b67a9ffd6daac upstream.

In order to make the driver work with the common clock framework, this patch
converts the clk_enable()/clk_disable() to
clk_prepare_enable()/clk_disable_unprepare(). While there, add the missing
error handling.

Signed-off-by: David Dueck <>
Signed-off-by: Anthony Harivel <>
Acked-by: Boris Brezillon <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
8 years agocan: flexcan: put TX mailbox into TX_INACTIVE mode after tx-complete
Marc Kleine-Budde [Tue, 16 Sep 2014 13:31:27 +0000 (15:31 +0200)]
can: flexcan: put TX mailbox into TX_INACTIVE mode after tx-complete

commit de5944883ebbedbf5adc8497659772f5da7b7d72 upstream.

After sending a RTR frame the TX mailbox becomes a RX_EMPTY mailbox. To avoid
side effects when the RX-FIFO is full, this patch puts the TX mailbox into
TX_INACTIVE mode in the transmission complete interrupt handler. This, of
course, leaves a race window between the actual completion of the transmission
and the handling of tx-complete interrupt. However this is the best we can do
without busy polling the tx complete interrupt.

Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agocan: flexcan: implement workaround for errata ERR005829
David Jander [Wed, 3 Sep 2014 14:47:22 +0000 (16:47 +0200)]
can: flexcan: implement workaround for errata ERR005829

commit 25e924450fcb23c11c07c95ea8964dd9f174652e upstream.

This patch implements the workaround mentioned in ERR005829:

    ERR005829: FlexCAN: FlexCAN does not transmit a message that is enabled to
    be transmitted in a specific moment during the arbitration process.

Workaround: The workaround consists of two extra steps after setting up a
message for transmission:

Step 8: Reserve the first valid mailbox as an inactive mailbox (CODE=0b1000).
If RX FIFO is disabled, this mailbox must be message buffer 0. Otherwise, the
first valid mailbox can be found using the "RX FIFO filters" table in the
FlexCAN chapter of the chip reference manual.

Step 9: Write twice INACTIVE code (0b1000) into the first valid mailbox.

Signed-off-by: David Jander <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
8 years agocan: flexcan: correctly initialize mailboxes
David Jander [Wed, 27 Aug 2014 09:58:05 +0000 (11:58 +0200)]
can: flexcan: correctly initialize mailboxes

commit fc05b884a31dbf259cc73cc856e634ec3acbebb6 upstream.

Apparently mailboxes may contain random data at startup, causing some of them
being prepared for message reception. This causes overruns being missed or even
confusing the IRQ check for trasmitted messages, increasing the transmit
counter instead of the error counter.

This patch initializes all mailboxes after the FIFO as RX_INACTIVE.

Signed-off-by: David Jander <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
8 years agocan: flexcan: mark TX mailbox as TX_INACTIVE
Marc Kleine-Budde [Tue, 16 Sep 2014 10:39:28 +0000 (12:39 +0200)]
can: flexcan: mark TX mailbox as TX_INACTIVE

commit c32fe4ad3e4861b2bfa1f44114c564935a123dda upstream.

This patch fixes the initialization of the TX mailbox. It is now correctly
initialized as TX_INACTIVE not RX_EMPTY.

Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
8 years agonl80211: clear skb cb before passing to netlink
Johannes Berg [Wed, 30 Jul 2014 12:55:26 +0000 (14:55 +0200)]
nl80211: clear skb cb before passing to netlink

commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42 upstream.

In testmode and vendor command reply/event SKBs we use the
skb cb data to store nl80211 parameters between allocation
and sending. This causes the code for CONFIG_NETLINK_MMAP
to get confused, because it takes ownership of the skb cb
data when the SKB is handed off to netlink, and it doesn't
explicitly clear it.

Clear the skb cb explicitly when we're done and before it
gets passed to netlink to avoid this issue.

Reported-by: Assaf Azulay <>
Reported-by: David Spinadel <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoUSB: storage: Add quirks for Entrega/Xircom USB to SCSI converters
Mark [Wed, 17 Sep 2014 18:15:43 +0000 (19:15 +0100)]
USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters

commit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream.

This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB-
SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The
US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI
chain to be accessed. Without it only the (single) device with SCSI ID 0
can be used.

The standalone converter sold by Entrega had model number U1-SC25. Xircom
acquired Entrega and re-branded the product line PortGear. The PortGear USB
to SCSI Converter (model PGSCSI) is internally identical to the Entrega
product, but later models may use a different USB ID. The Entrega-branded
units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and
Macintosh drivers also support 085A:0028.

Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac
(8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as
a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may
have initially used the same ID as the standalone U1-SC25 (1645:0007), but
later production used 085A:0026.

My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133
probably also exist.

This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows
driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I
couldn't find any mention of that actually existing in the wild; perhaps it
was cancelled before release?

Signed-off-by: Mark Knibbs <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter
Mark [Tue, 16 Sep 2014 15:51:41 +0000 (16:51 +0100)]
USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter

commit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream.


The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g.
iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM
Microsystems chips. Only the connectors differ; both have the same USB ID.
The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other
than 0.

I don't have one of these, but based on the other entries for Shuttle/
SCM-based converters this patch is very likely correct. I used 0x0000 and
0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
bcdDevice value the products use.

Signed-off-by: Mark Knibbs <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter
Mark [Tue, 16 Sep 2014 15:22:50 +0000 (16:22 +0100)]
USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter

commit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream.

The Adaptec USBConnect 2000 is another SCSI-USB converter which uses
Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is
required to use SCSI devices with ID other than 0.

I don't have a USBConnect 2000, but based on the other entries for Shuttle/
SCM-based converters this patch is very likely correct. I used 0x0000 and
0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
bcdDevice value the product uses.

Signed-off-by: Mark Knibbs <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agolibiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu
Mike Christie [Wed, 3 Sep 2014 05:00:39 +0000 (00:00 -0500)]
libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu

commit db9bfd64b14a3a8f1868d2164518fdeab1b26ad1 upstream.

This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
This function is used by iscsi drivers and userspace to send iscsi PDUs/
commands. For login commands, we have a set buffer size. For all other
commands we do not support data buffers.

This was reported by Dan Carpenter here:

Reported-by: Dan Carpenter <>
Signed-off-by: Mike Christie <>
Reviewed-by: Sagi Grimberg <>
Signed-off-by: Christoph Hellwig <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
8 years agoNFSv4: Fix another bug in the close/open_downgrade code
Trond Myklebust [Thu, 18 Sep 2014 15:51:32 +0000 (11:51 -0400)]
NFSv4: Fix another bug in the close/open_downgrade code

commit cd9288ffaea4359d5cfe2b8d264911506aed26a4 upstream.

James Drew reports another bug whereby the NFS client is now sending
an OPEN_DOWNGRADE in a situation where it should really have sent a
CLOSE: the client is opening the file for O_RDWR, but then trying to
do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec.

Reported-by: James Drews <>
Fixes: aee7af356e15 (NFSv4: Fix problems with close in the presence...)
Signed-off-by: Trond Myklebust <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoiscsi-target: avoid NULL pointer in iscsi_copy_param_list failure
Joern Engel [Tue, 2 Sep 2014 21:49:54 +0000 (17:49 -0400)]
iscsi-target: avoid NULL pointer in iscsi_copy_param_list failure

commit 8ae757d09c45102b347a1bc2867f54ffc1ab8fda upstream.

In iscsi_copy_param_list() a failed iscsi_param_list memory allocation
currently invokes iscsi_release_param_list() to cleanup, and will promptly
trigger a NULL pointer dereference.

Instead, go ahead and return for the first iscsi_copy_param_list()
failure case.

Found by coverity.

Signed-off-by: Joern Engel <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
8 years agoiscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid
Nicholas Bellinger [Wed, 17 Sep 2014 18:45:17 +0000 (11:45 -0700)]
iscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid

commit b53b0d99d6fbf7d44330395349a895521cfdbc96 upstream.

This patch fixes a bug in iscsit_logout_post_handler_diffcid() where
a pointer used as storage for list_for_each_entry() was incorrectly
being used to determine if no matching entry had been found.

This patch changes iscsit_logout_post_handler_diffcid() to key off
bool conn_found to determine if the function needs to exit early.

Reported-by: Joern Engel <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
8 years agobe careful with nd->inode in path_init() and follow_dotdot_rcu()
Al Viro [Sun, 14 Sep 2014 01:59:43 +0000 (21:59 -0400)]
be careful with nd->inode in path_init() and follow_dotdot_rcu()

commit 4023bfc9f351a7994fb6a7d515476c320f94a574 upstream.

in the former we simply check if dentry is still valid after picking
its ->d_inode; in the latter we fetch ->d_inode in the same places
where we fetch dentry and its ->d_seq, under the same checks.

Signed-off-by: Al Viro <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agovfs: Fold follow_mount_rcu() into follow_dotdot_rcu()
Ben Hutchings [Sun, 19 Oct 2014 22:07:02 +0000 (23:07 +0100)]
vfs: Fold follow_mount_rcu() into follow_dotdot_rcu()

This is needed before commit 4023bfc9f351 ('be careful with nd->inode
in path_init() and follow_dotdot_rcu()').  A similar change was made
upstream as part of commit b37199e626b3 ('rcuwalk: recheck mount_lock
after mountpoint crossing attempts').

Signed-off-by: Ben Hutchings <>
8 years agodon't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
Al Viro [Sun, 14 Sep 2014 01:55:46 +0000 (21:55 -0400)]
don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()

commit 7bd88377d482e1eae3c5329b12e33cfd664fa6a9 upstream.

return the value instead, and have path_init() do the assignment.  Broken by
"vfs: Fix absolute RCU path walk failures due to uninitialized seq number",
which was Cc-stable with 2.6.38+ as destination.  This one should go where
it went.

To avoid dummy value returned in case when root is already set (it would do
no harm, actually, since the only caller that doesn't ignore the return value
is guaranteed to have nd->root *not* set, but it's more obvious that way),
lift the check into callers.  And do the same to set_root(), to keep them
in sync.

Signed-off-by: Al Viro <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
8 years agoalarmtimer: Lock k_itimer during timer callback
Richard Larocque [Wed, 10 Sep 2014 01:31:05 +0000 (18:31 -0700)]
alarmtimer: Lock k_itimer during timer callback

commit 474e941bed9262f5fa2394f9a4a67e24499e5926 upstream.

Locks the k_itimer's it_lock member when handling the alarm timer's
expiry callback.

The regular posix timers defined in posix-timers.c have this lock held
during timout processing because their callbacks are routed through
posix_timer_fn().  The alarm timers follow a different path, so they
ought to grab the lock somewhere else.

Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Richard Cochran <>
Cc: Prarit Bhargava <>
Cc: Sharvil Nanavati <>
Signed-off-by: Richard Larocque <>
Signed-off-by: John Stultz <>
Signed-off-by: Ben Hutchings <>
8 years agoalarmtimer: Do not signal SIGEV_NONE timers
Richard Larocque [Wed, 10 Sep 2014 01:31:04 +0000 (18:31 -0700)]
alarmtimer: Do not signal SIGEV_NONE timers

commit 265b81d23a46c39df0a735a3af4238954b41a4c2 upstream.

Avoids sending a signal to alarm timers created with sigev_notify set to
SIGEV_NONE by checking for that special case in the timeout callback.

The regular posix timers avoid sending signals to SIGEV_NONE timers by
not scheduling any callbacks for them in the first place.  Although it
would be possible to do something similar for alarm timers, it's simpler
to handle this as a special case in the timeout.

Prior to this patch, the alarm timer would ignore the sigev_notify value
and try to deliver signals to the process anyway.  Even worse, the
sanity check for the value of sigev_signo is skipped when SIGEV_NONE was
specified, so the signal number could be bogus.  If sigev_signo was an
unitialized value (as it often would be if SIGEV_NONE is used), then
it's hard to predict which signal will be sent.

Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Richard Cochran <>
Cc: Prarit Bhargava <>
Cc: Sharvil Nanavati <>
Signed-off-by: Richard Larocque <>
Signed-off-by: John Stultz <>
Signed-off-by: Ben Hutchings <>
8 years agoalarmtimer: Return relative times in timer_gettime
Richard Larocque [Wed, 10 Sep 2014 01:31:03 +0000 (18:31 -0700)]
alarmtimer: Return relative times in timer_gettime

commit e86fea764991e00a03ff1e56409ec9cacdbda4c9 upstream.

Returns the time remaining for an alarm timer, rather than the time at
which it is scheduled to expire.  If the timer has already expired or it
is not currently scheduled, the it_value's members are set to zero.

This new behavior matches that of the other posix-timers and the POSIX

This is a change in user-visible behavior, and may break existing
applications.  Hopefully, few users rely on the old incorrect behavior.

Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Richard Cochran <>
Cc: Prarit Bhargava <>
Cc: Sharvil Nanavati <>
Signed-off-by: Richard Larocque <>
[jstultz: minor style tweak]
Signed-off-by: John Stultz <>
[bwh: Backported to 3.2: Add definition of alarm_expires_remaining() from
 commit 6cffe00f7d4e ('alarmtimer: Add functions for timerfd support')]
Signed-off-by: Ben Hutchings <>
8 years agojiffies: Fix timeval conversion to jiffies
Andrew Hunter [Thu, 4 Sep 2014 21:17:16 +0000 (14:17 -0700)]
jiffies: Fix timeval conversion to jiffies

commit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream.

timeval_to_jiffies tried to round a timeval up to an integral number
of jiffies, but the logic for doing so was incorrect: intervals
corresponding to exactly N jiffies would become N+1. This manifested
itself particularly repeatedly stopping/starting an itimer:

setitimer(ITIMER_PROF, &val, NULL);
setitimer(ITIMER_PROF, NULL, &val);

would add a full tick to val, _even if it was exactly representable in
terms of jiffies_ (say, the result of a previous rounding.)  Doing
this repeatedly would cause unbounded growth in val.  So fix the math.

Here's what was wrong with the conversion: we essentially computed
(eliding seconds)

jiffies = usec  * (NSEC_PER_USEC/TICK_NSEC)

by using scaling arithmetic, which took the best approximation of
NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
x/(2^USEC_JIFFIE_SC), and computed:

jiffies = (usec * x) >> USEC_JIFFIE_SC

and rounded this calculation up in the intermediate form (since we
can't necessarily exactly represent TICK_NSEC in usec.) But the
scaling arithmetic is a (very slight) *over*approximation of the true
value; that is, instead of dividing by (1 usec/ 1 jiffie), we
effectively divided by (1 usec/1 jiffie)-epsilon (rounding
down). This would normally be fine, but we want to round timeouts up,
and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this
would be fine if our division was exact, but dividing this by the
slightly smaller factor was equivalent to adding just _over_ 1 to the
final result (instead of just _under_ 1, as desired.)

In particular, with HZ=1000, we consistently computed that 10000 usec
was 11 jiffies; the same was true for any exact multiple of

We could possibly still round in the intermediate form, adding
something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
convert usec->nsec, round in nanoseconds, and then convert using
time*spec*_to_jiffies.  This adds one constant multiplication, and is
not observably slower in microbenchmarks on recent x86 hardware.

Tested: the following program:

int main() {
  struct itimerval zero = {{0, 0}, {0, 0}};
  /* Initially set to 10 ms. */
  struct itimerval initial = zero;
  initial.it_interval.tv_usec = 10000;
  setitimer(ITIMER_PROF, &initial, NULL);
  /* Save and restore several times. */
  for (size_t i = 0; i < 10; ++i) {
    struct itimerval prev;
    setitimer(ITIMER_PROF, &zero, &prev);
    /* on old kernels, this goes up by TICK_USEC every iteration */
    printf("previous value: %ld %ld %ld %ld\n",
           prev.it_interval.tv_sec, prev.it_interval.tv_usec,
           prev.it_value.tv_sec, prev.it_value.tv_usec);
    setitimer(ITIMER_PROF, &prev, NULL);
    return 0;

Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Paul Turner <>
Cc: Richard Cochran <>
Cc: Prarit Bhargava <>
Reviewed-by: Paul Turner <>
Reported-by: Aaron Jacobs <>
Signed-off-by: Andrew Hunter <>
[jstultz: Tweaked to apply to 3.17-rc]
Signed-off-by: John Stultz <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
8 years agofutex: Unlock hb->lock in futex_wait_requeue_pi() error path
Thomas Gleixner [Thu, 11 Sep 2014 21:44:35 +0000 (23:44 +0200)]
futex: Unlock hb->lock in futex_wait_requeue_pi() error path

commit 13c42c2f43b19aab3195f2d357db00d1e885eaa8 upstream.

futex_wait_requeue_pi() calls futex_wait_setup(). If
futex_wait_setup() succeeds it returns with hb->lock held and
preemption disabled. Now the sanity check after this does:

        if (match_futex(&q.key, &key2)) {
    ret = -EINVAL;
goto out_put_keys;

which releases the keys but does not release hb->lock.

So we happily return to user space with hb->lock held and therefor
preemption disabled.

Unlock hb->lock before taking the exit route.

Reported-by: Dave "Trinity" Jones <>
Signed-off-by: Thomas Gleixner <>
Reviewed-by: Darren Hart <>
Reviewed-by: Davidlohr Bueso <>
Cc: Peter Zijlstra <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: queue_unlock() takes two parameters]
Signed-off-by: Ben Hutchings <>
8 years agoInput: i8042 - add nomux quirk for Avatar AVIU-145A6
Hans de Goede [Thu, 11 Sep 2014 17:10:26 +0000 (10:10 -0700)]
Input: i8042 - add nomux quirk for Avatar AVIU-145A6

commit d2682118f4bb3ceb835f91c1a694407a31bb7378 upstream.

The sys_vendor / product_name are somewhat generic unfortunately, so this
may lead to some false positives. But nomux usually does no harm, where as
not having it clearly is causing problems on the Avatar AVIU-145A6.

Reported-by: Hugo P <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
8 years agoInput: i8042 - add Fujitsu U574 to no_timeout dmi table
Hans de Goede [Wed, 10 Sep 2014 20:53:37 +0000 (13:53 -0700)]
Input: i8042 - add Fujitsu U574 to no_timeout dmi table

commit cc18a69c92d0972bc2fc5a047ee3be1e8398171b upstream.

Reported-by: Jason Robinson <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
8 years agoxhci: Fix null pointer dereference if xhci initialization fails
Mathias Nyman [Thu, 11 Sep 2014 10:55:48 +0000 (13:55 +0300)]
xhci: Fix null pointer dereference if xhci initialization fails

commit c207e7c50f31113c24a9f536fcab1e8a256985d7 upstream.

If xhci initialization fails before the roothub bandwidth
domains (xhci->rh_bw[i]) are allocated it will oops when
trying to access rh_bw members in xhci_mem_cleanup().

Reported-by: Manuel Reimer <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agostorage: Add single-LUN quirk for Jaz USB Adapter
Mark [Thu, 11 Sep 2014 12:15:45 +0000 (13:15 +0100)]
storage: Add single-LUN quirk for Jaz USB Adapter

commit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream.

The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware
seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/
SCM chip set. However its firmware restricts it to only work with Jaz

On connecting the cable a message like this appears four times in the log:
 reset full speed USB device number 4 using uhci_hcd

That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it.

Signed-off-by: Mark Knibbs <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agousb: hub: take hub->hdev reference when processing from eventlist
Joe Lawrence [Wed, 10 Sep 2014 19:07:50 +0000 (15:07 -0400)]
usb: hub: take hub->hdev reference when processing from eventlist

commit c605f3cdff53a743f6d875b76956b239deca1272 upstream.

During surprise device hotplug removal tests, it was observed that
hub_events may try to call usb_lock_device on a device that has already
been freed. Protect the usb_device by taking out a reference (under the
hub_event_lock) when hub_events pulls it off the list, returning the
reference after hub_events is finished using it.

Signed-off-by: Joe Lawrence <>
Suggested-by: David Bulkow <> for using kref
Suggested-by: Alan Stern <> for placement
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoInput: serport - add compat handling for SPIOCSTYPE ioctl
John Sung [Tue, 9 Sep 2014 17:06:51 +0000 (10:06 -0700)]
Input: serport - add compat handling for SPIOCSTYPE ioctl

commit a80d8b02751060a178bb1f7a6b7a93645a7a308b upstream.

When running a 32-bit inputattach utility in a 64-bit system, there will be
error code "inputattach: can't set device type". This is caused by the
serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl

Signed-off-by: John Sung <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
8 years agolibceph: do not hard code max auth ticket len
Ilya Dryomov [Tue, 9 Sep 2014 15:39:15 +0000 (19:39 +0400)]
libceph: do not hard code max auth ticket len

commit c27a3e4d667fdcad3db7b104f75659478e0c68d8 upstream.

We hard code cephx auth ticket buffer size to 256 bytes.  This isn't
enough for any moderate setups and, in case tickets themselves are not
encrypted, leads to buffer overflows (ceph_x_decrypt() errors out, but
ceph_decode_copy() doesn't - it's just a memcpy() wrapper).  Since the
buffer is allocated dynamically anyway, allocated it a bit later, at
the point where we know how much is going to be needed.


Signed-off-by: Ilya Dryomov <>
Reviewed-by: Sage Weil <>
Signed-off-by: Ben Hutchings <>
8 years agolibceph: add process_one_ticket() helper
Ilya Dryomov [Mon, 8 Sep 2014 13:25:34 +0000 (17:25 +0400)]
libceph: add process_one_ticket() helper

commit 597cda357716a3cf8d994cb11927af917c8d71fa upstream.

Add a helper for processing individual cephx auth tickets.  Needed for
the next commit, which deals with allocating ticket buffers.  (Most of
the diff here is whitespace - view with git diff -b).

Signed-off-by: Ilya Dryomov <>
Reviewed-by: Sage Weil <>
Signed-off-by: Ben Hutchings <>
8 years agolibceph: gracefully handle large reply messages from the mon
Sage Weil [Mon, 4 Aug 2014 14:01:54 +0000 (07:01 -0700)]
libceph: gracefully handle large reply messages from the mon

commit 73c3d4812b4c755efeca0140f606f83772a39ce4 upstream.

We preallocate a few of the message types we get back from the mon.  If we
get a larger message than we are expecting, fall back to trying to allocate
a new one instead of blindly using the one we have.

Signed-off-by: Sage Weil <>
Reviewed-by: Ilya Dryomov <>
Signed-off-by: Ben Hutchings <>
8 years agolibceph: rename ceph_msg::front_max to front_alloc_len
Ilya Dryomov [Thu, 9 Jan 2014 18:08:21 +0000 (20:08 +0200)]
libceph: rename ceph_msg::front_max to front_alloc_len

commit 3cea4c3071d4e55e9d7356efe9d0ebf92f0c2204 upstream.

Rename front_max field of struct ceph_msg to front_alloc_len to make
its purpose more clear.

Signed-off-by: Ilya Dryomov <>
Reviewed-by: Sage Weil <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoInput: synaptics - add support for ForcePads
Dmitry Torokhov [Sat, 30 Aug 2014 20:51:06 +0000 (13:51 -0700)]
Input: synaptics - add support for ForcePads

commit 5715fc764f7753d464dbe094b5ef9cffa6e479a4 upstream.

ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
physical buttons, instead they generate primary button click when user
presses somewhat hard on the surface of the touchpad. Unfortunately they
also report primary button click whenever there are 2 or more contacts
on the pad, messing up all multi-finger gestures (2-finger scrolling,
multi-finger tapping, etc). To cope with this behavior we introduce a
delay (currently 50 msecs) in reporting primary press in case more
contacts appear.

Reviewed-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
8 years agoperf: Fix a race condition in perf_remove_from_context()
Cong Wang [Tue, 2 Sep 2014 22:27:20 +0000 (15:27 -0700)]
perf: Fix a race condition in perf_remove_from_context()

commit 3577af70a2ce4853d58e57d832e687d739281479 upstream.

We saw a kernel soft lockup in perf_remove_from_context(),
it looks like the `perf` process, when exiting, could not go
out of the retry loop. Meanwhile, the target process was forking
a child. So either the target process should execute the smp
function call to deactive the event (if it was running) or it should
do a context switch which deactives the event.

It seems we optimize out a context switch in perf_event_context_sched_out(),
and what's more important, we still test an obsolete task pointer when
retrying, so no one actually would deactive that event in this situation.
Fix it directly by reloading the task pointer in perf_remove_from_context().

This should cure the above soft lockup.

Signed-off-by: Cong Wang <>
Signed-off-by: Cong Wang <>
Signed-off-by: Peter Zijlstra <>
Cc: Paul Mackerras <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Linus Torvalds <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
8 years agouwb: init beacon cache entry before registering uwb device
Thomas Pugliese [Thu, 7 Aug 2014 20:45:35 +0000 (15:45 -0500)]
uwb: init beacon cache entry before registering uwb device

commit 675f0ab2fe5a0f7325208e60b617a5f32b86d72c upstream.

Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in
uwbd_dev_onair so that usermode will only see the device after it is
properly initialized.  This fixes a kernel panic that can occur if
usermode tries to access the IEs sysfs attribute of a UWB device before
the driver has had a chance to set the beacon cache entry.

Signed-off-by: Thomas Pugliese <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoUSB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device
Taylor Braun-Jones [Thu, 7 Aug 2014 18:25:06 +0000 (14:25 -0400)]
USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device

commit 9c491c372d677b6420e0f8c6361fe422791662cc upstream.

Signed-off-by: Taylor Braun-Jones <>
Cc: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoInput: elantech - fix detection of touchpad on ASUS s301l
Hans de Goede [Mon, 8 Sep 2014 21:39:52 +0000 (14:39 -0700)]
Input: elantech - fix detection of touchpad on ASUS s301l

commit 271329b3c798b2102120f5df829071c211ef00ed upstream.

Adjust Elantech signature validation to account fo rnewer models of

Reported-and-tested-by: Màrius Monton <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
8 years agousb: host: xhci: fix compliance mode workaround
Felipe Balbi [Wed, 27 Aug 2014 21:38:04 +0000 (16:38 -0500)]
usb: host: xhci: fix compliance mode workaround

commit 96908589a8b2584b1185f834d365f5cc360e8226 upstream.

Commit 71c731a (usb: host: xhci: Fix Compliance Mode
on SN65LVP3502CP Hardware) implemented a workaround
for a known issue with Texas Instruments' USB 3.0
redriver IC but it left a condition where any xHCI
host would be taken out of reset if port was placed
in compliance mode and there was no device connected
to the port.

That condition would trigger a fake connection to a
non-existent device so that usbcore would trigger a
warm reset of the port, thus taking the link out of

This has the side-effect of preventing any xHCI host
connected to a Linux machine from starting and running
the USB 3.0 Electrical Compliance Suite because the
port will mysteriously taken out of compliance mode
and, thus, xHCI won't step through the necessary
compliance patterns for link validation.

This patch fixes the issue by just adding a missing
check for XHCI_COMP_MODE_QUIRK inside
xhci_hub_report_usb3_link_state() when PORT_CAS isn't

This patch should be backported to all kernels containing
commit 71c731a.

Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware)
Cc: Alexis R. Cortes <>
Signed-off-by: Felipe Balbi <>
Acked-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - s/xhci_hub_report_usb3_link_state/xhci_hub_report_link_state/
 - s/raw_port_status/temp/
 - Adjust indentation]
Signed-off-by: Ben Hutchings <>
8 years agodrm/radeon: add connector quirk for fujitsu board
Alex Deucher [Mon, 8 Sep 2014 17:55:51 +0000 (13:55 -0400)]
drm/radeon: add connector quirk for fujitsu board

commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream.

Vbios connector table lists non-existent VGA port.


Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
8 years agoahci: add pcid for Marvel 0x9182 controller
Murali Karicheri [Fri, 5 Sep 2014 17:21:00 +0000 (13:21 -0400)]
ahci: add pcid for Marvel 0x9182 controller

commit c5edfff9db6f4d2c35c802acb4abe0df178becee upstream.

Keystone K2E EVM uses Marvel 0x9182 controller. This requires support
for the ID in the ahci driver.

Signed-off-by: Murali Karicheri <>
Signed-off-by: Tejun Heo <>
Cc: Santosh Shilimkar <>
Signed-off-by: Ben Hutchings <>
8 years agousb: dwc3: core: fix order of PM runtime calls
Felipe Balbi [Tue, 2 Sep 2014 19:57:20 +0000 (14:57 -0500)]
usb: dwc3: core: fix order of PM runtime calls

commit fed33afce0eda44a46ae24d93aec1b5198c0bac4 upstream.

Currently, we disable pm_runtime before all register
accesses are done, this is dangerous and might lead
to abort exceptions due to the driver trying to access
a register which is clocked by a clock which was long

Fix that by moving pm_runtime_put_sync() and pm_runtime_disable()
as the last thing we do before returning from our ->remove()

Fixes: 72246da (usb: Introduce DesignWare USB3 DRD Driver)
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
8 years agousb: dwc3: core: use pm_runtime_put_sync() on remove
Felipe Balbi [Fri, 11 Oct 2013 13:34:28 +0000 (08:34 -0500)]
usb: dwc3: core: use pm_runtime_put_sync() on remove

commit 16b972a592ea2c9a3c2a3c12238de650fd4043a9 upstream.

We are going to disable runtime_pm and we're
removing the driver, we must disable the device

Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
8 years agoACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock
Jiri Kosina [Wed, 3 Sep 2014 13:04:28 +0000 (15:04 +0200)]
ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock

commit 6726655dfdd2dc60c035c690d9f10cb69d7ea075 upstream.

There is a following AB-BA dependency between cpu_hotplug.lock and

1) cpu_hotplug.lock -> cpuidle_lock

2) cpuidle_lock -> cpu_hotplug.lock
acpi_os_execute_deferred() workqueue

Fix this by reversing the order acpi_processor_cst_has_changed() does
thigs -- let it first execute the protection against CPU hotplug by
calling get_online_cpus() and obtain the cpuidle lock only after that (and
perform the symmentric change when allowing CPUs hotplug again and
dropping cpuidle lock).

Spotted by lockdep.

Signed-off-by: Jiri Kosina <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
8 years agoblock: Fix dev_t minor allocation lifetime
Keith Busch [Tue, 26 Aug 2014 15:05:36 +0000 (09:05 -0600)]
block: Fix dev_t minor allocation lifetime

commit 2da78092dda13f1efd26edbbf99a567776913750 upstream.

Releases the dev_t minor when all references are closed to prevent
another device from acquiring the same major/minor.

Since the partition's release may be invoked from call_rcu's soft-irq
context, the ext_dev_idr's mutex had to be replaced with a spinlock so
as not so sleep.

Signed-off-by: Keith Busch <>
Signed-off-by: Jens Axboe <>
[bwh: Backported to 3.2:
 - Adjust filename
 - idr insertion API is different, and blk_alloc_devt() is preallocating
   a node in a different way]
Signed-off-by: Ben Hutchings <>
8 years agoaio: add missing smp_rmb() in read_events_ring
Jeff Moyer [Tue, 2 Sep 2014 17:17:00 +0000 (13:17 -0400)]
aio: add missing smp_rmb() in read_events_ring

commit 2ff396be602f10b5eab8e73b24f20348fa2de159 upstream.

We ran into a case on ppc64 running mariadb where io_getevents would
return zeroed out I/O events.  After adding instrumentation, it became
clear that there was some missing synchronization between reading the
tail pointer and the events themselves.  This small patch fixes the
problem in testing.

Thanks to Zach for helping to look into this, and suggesting the fix.

Signed-off-by: Jeff Moyer <>
Signed-off-by: Benjamin LaHaise <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
8 years agoxen/manage: Always freeze/thaw processes when suspend/resuming
Ross Lagerwall [Mon, 18 Aug 2014 09:41:36 +0000 (10:41 +0100)]
xen/manage: Always freeze/thaw processes when suspend/resuming

commit 61a734d305e16944b42730ef582a7171dc733321 upstream.

Always freeze processes when suspending and thaw processes when resuming
to prevent a race noticeable with HVM guests.

This prevents a deadlock where the khubd kthread (which is designed to
be freezable) acquires a usb device lock and then tries to allocate
memory which requires the disk which hasn't been resumed yet.
Meanwhile, the xenwatch thread deadlocks waiting for the usb device

Freezing processes fixes this because the khubd thread is only thawed
after the xenwatch thread finishes resuming all the devices.

Signed-off-by: Ross Lagerwall <>
Signed-off-by: David Vrabel <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoALSA: hda - Fix COEF setups for ALC1150 codec
Takashi Iwai [Tue, 2 Sep 2014 05:21:56 +0000 (07:21 +0200)]
ALSA: hda - Fix COEF setups for ALC1150 codec

commit acf08081adb5e8fe0519eb97bb49797ef52614d6 upstream.

ALC1150 codec seems to need the COEF- and PLL-setups just like its
compatible ALC882 codec.  Some machines (e.g. SunMicro X10SAT) show
the problem like too low output volumes unless the COEF setup is

Reported-and-tested-by: Dana Goyette <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
8 years agodrm/vmwgfx: Fix a potential infinite spin waiting for fifo idle
Thomas Hellstrom [Thu, 28 Aug 2014 09:53:23 +0000 (11:53 +0200)]
drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle

commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream.

The code waiting for fifo idle was incorrect and could possibly spin
forever under certain circumstances.

Signed-off-by: Thomas Hellstrom <>
Reported-by: Mark Sheldon <>
Reviewed-by: Jakob Bornecrantz <>
Reivewed-by: Mark Sheldon <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: sierra: add 1199:68AA device ID
Bjørn Mork [Thu, 28 Aug 2014 13:08:16 +0000 (15:08 +0200)]
USB: sierra: add 1199:68AA device ID

commit 5b3da69285c143b7ea76b3b9f73099ff1093ab73 upstream.

This VID:PID is used for some Direct IP devices behaving
identical to the already supported 0F3D:68AA devices.

Reported-by: Lars Melin <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: sierra: avoid CDC class functions on "68A3" devices
Bjørn Mork [Thu, 28 Aug 2014 12:11:23 +0000 (14:11 +0200)]
USB: sierra: avoid CDC class functions on "68A3" devices

commit 049255f51644c1105775af228396d187402a5934 upstream.

Sierra Wireless Direct IP devices using the 68A3 product ID
can be configured for modes including a CDC ECM class function.
The known example uses interface numbers 12 and 13 for the ECM
control and data interfaces respectively, consistent with CDC
MBIM function interface numbering on other Sierra devices.

It seems cleaner to restrict this driver to the ff/ff/ff
vendor specific interfaces rather than increasing the already
long interface number blacklist.  This should be more future
proof if Sierra adds more class functions using interface
numbers not yet in the blacklist.

Signed-off-by: Bjørn Mork <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoUSB: ftdi_sio: add support for NOVITUS Bono E thermal printer
Johan Hovold [Mon, 18 Aug 2014 16:33:11 +0000 (18:33 +0200)]
USB: ftdi_sio: add support for NOVITUS Bono E thermal printer

commit ee444609dbae8afee420c3243ce4c5f442efb622 upstream.

Add device id for NOVITUS Bono E thermal printer.

Reported-by: Emanuel Koczwara <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
8 years agoRevert "iwlwifi: dvm: don't enable CTS to self"
Emmanuel Grumbach [Sun, 31 Aug 2014 19:11:11 +0000 (22:11 +0300)]
Revert "iwlwifi: dvm: don't enable CTS to self"

commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c upstream.

This reverts commit 43d826ca5979927131685cc2092c7ce862cb91cd.

This commit caused packet loss.

Signed-off-by: Emmanuel Grumbach <>
[bwh: Backported to 3.2:
 - Adjust filename
 - Condition for RXON_FLG_SELF_CTS_EN in iwlagn_commit_rxon() was different]
Signed-off-by: Ben Hutchings <>
8 years agoata_piix: Add Device IDs for Intel 9 Series PCH
James Ralston [Wed, 27 Aug 2014 21:31:58 +0000 (14:31 -0700)]
ata_piix: Add Device IDs for Intel 9 Series PCH

commit 6cad1376954e591c3c41500c4e586e183e7ffe6d upstream.

This patch adds the IDE mode SATA Device IDs for the Intel 9 Series PCH.

Signed-off-by: James Ralston <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
8 years agoahci: Add Device IDs for Intel 9 Series PCH
James Ralston [Wed, 27 Aug 2014 21:29:07 +0000 (14:29 -0700)]
ahci: Add Device IDs for Intel 9 Series PCH

commit 1b071a0947dbce5c184c12262e02540fbc493457 upstream.

This patch adds the AHCI mode SATA Device IDs for the Intel 9 Series PCH.

Signed-off-by: James Ralston <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
8 years agodrm/i915: Remove bogus __init annotation from DMI callbacks
Mathias Krause [Wed, 27 Aug 2014 16:41:19 +0000 (18:41 +0200)]
drm/i915: Remove bogus __init annotation from DMI callbacks

commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream.

The __init annotations for the DMI callback functions are wrong as this
code can be called even after the module has been initialized, e.g. like

  # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove
  # modprobe i915
  # echo 1 > /sys/bus/pci/rescan

The first command will remove the PCI device from the kernel's device
list so the second command won't see it right away. But as it registers
a PCI driver it'll see it on the third command. If the system happens to
match one of the DMI table entries we'll try to call a function in long
released memory and generate an Oops, at best.

Fix this by removing the bogus annotation.

Modpost should have caught that one but it ignores section reference
mismatches from the .rodata section. :/

Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT")
Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...")
Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...")
Signed-off-by: Mathias Krause <>
Cc: Daniel Vetter <>
Cc: Duncan Laurie <>
Cc: Jarod Wilson <>
Cc: Rusty Russell <> # Can modpost be fixed?
Signed-off-by: Jani Nikula <>
[bwh: Backported to 3.2: drop inapplicable change in intel_crt.c]
Signed-off-by: Ben Hutchings <>
8 years agoregmap: Fix handling of volatile registers for format_write() chips
Mark Brown [Tue, 26 Aug 2014 11:12:17 +0000 (12:12 +0100)]
regmap: Fix handling of volatile registers for format_write() chips

commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream.

A previous over-zealous factorisation of code means that we only treat
registers as volatile if they are readable. For most devices this is fine
since normally most registers can be read and volatility implies
readability but for format_write() devices where there is no readback from
the hardware and we use volatility to mean simply uncacheability this means
that we end up treating all registers as cacheble.

A bigger refactoring of the code to clarify this is in order but as a fix
make a minimal change and only check readability when checking volatility
if there is no format_write() operation defined for the device.

Signed-off-by: Mark Brown <>
Tested-by: Lars-Peter Clausen <>
Signed-off-by: Ben Hutchings <>
8 years agoregmap: if format_write is used, declare all registers as "unreadable"
Wolfram Sang [Mon, 30 Jan 2012 14:08:16 +0000 (15:08 +0100)]
regmap: if format_write is used, declare all registers as "unreadable"

commit 4191f19792bf91267835eb090d970e9cd6277a65 upstream.

Using .format_write means, we have a custom function to write to the
chip, but not to read back. Also, mark registers as "not precious" and
"not volatile" which is implicit because we cannot read them. Make those
functions use 'regmap_readable' to reuse the checks done there.

Signed-off-by: Wolfram Sang <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
8 years agoMIPS: ZBOOT: add missing <linux/string.h> include
Aurelien Jarno [Sun, 20 Jul 2014 17:58:23 +0000 (19:58 +0200)]
MIPS: ZBOOT: add missing <linux/string.h> include

commit 29593fd5a8149462ed6fad0d522234facdaee6c8 upstream.

Commit dc4d7b37 (MIPS: ZBOOT: gather string functions into string.c)
moved the string related functions into a separate file, which might
cause the following build error, depending on the configuration:

| CC      arch/mips/boot/compressed/decompress.o
| In file included from linux/arch/mips/boot/compressed/../../../../lib/decompress_unxz.c:234:0,
|                  from linux/arch/mips/boot/compressed/decompress.c:67:
| linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c: In function 'fill_temp':
| linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:2: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration]
| cc1: some warnings being treated as errors
| linux/scripts/ recipe for target 'arch/mips/boot/compressed/decompress.o' failed
| make[6]: *** [arch/mips/boot/compressed/decompress.o] Error 1
| linux/arch/mips/Makefile:308: recipe for target 'vmlinuz' failed

It does not fail with the standard configuration, as when
CONFIG_DYNAMIC_DEBUG is not enabled <linux/string.h> gets included in
include/linux/dynamic_debug.h. There might be other ways for it to
get indirectly included.

We can't add the include directly in xz_dec_stream.c as some
architectures might want to use a different version for the boot/
directory (see for example arch/x86/boot/string.h).

Signed-off-by: Aurelien Jarno <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
8 years agortlwifi: rtl8192cu: Add new ID
Larry Finger [Sun, 24 Aug 2014 22:49:43 +0000 (17:49 -0500)]
rtlwifi: rtl8192cu: Add new ID

commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream.

The Sitecom WLA-2102 adapter uses this driver.

Reported-by: Nico Baggus <>
Signed-off-by: Larry Finger <>
Cc: Nico Baggus <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
8 years agoKVM: s390: Fix user triggerable bug in dead code
Christian Borntraeger [Wed, 6 Aug 2014 14:17:58 +0000 (16:17 +0200)]
KVM: s390: Fix user triggerable bug in dead code

commit 614a80e474b227cace52fd6e3c790554db8a396e upstream.

In the early days, we had some special handling for the
KVM_EXIT_S390_SIEIC exit, but this was gone in 2009 with commit
d7b0b5eb3000 (KVM: s390: Make psw available on all exits, not
just a subset).

Now this switch statement is just a sanity check for userspace
not messing with the kvm_run structure. Unfortunately, this
allows userspace to trigger a kernel BUG. Let's just remove
this switch statement.

Signed-off-by: Christian Borntraeger <>
Reviewed-by: Cornelia Huck <>
Reviewed-by: David Hildenbrand <>
Signed-off-by: Ben Hutchings <>
8 years agocgroup: reject cgroup names with '
Alban Crequy [Mon, 18 Aug 2014 11:20:20 +0000 (12:20 +0100)]
cgroup: reject cgroup names with '

commit 71b1fb5c4473a5b1e601d41b109bdfe001ec82e0 upstream.

/proc/<pid>/cgroup contains one cgroup path on each line. If cgroup names are
allowed to contain "\n", applications cannot parse /proc/<pid>/cgroup safely.

Signed-off-by: Alban Crequy <>
Signed-off-by: Tejun Heo <>
[bwh: Backported to 3.2:
 - Adjust context
 - We have to get the name from the dentry pointer]
Signed-off-by: Ben Hutchings <>
8 years agopercpu: free percpu allocation info for uniprocessor system
Honggang Li [Tue, 12 Aug 2014 13:36:15 +0000 (21:36 +0800)]
percpu: free percpu allocation info for uniprocessor system

commit 3189eddbcafcc4d827f7f19facbeddec4424eba8 upstream.

Currently, only SMP system free the percpu allocation info.
Uniprocessor system should free it too. For example, one x86 UML
virtual machine with 256MB memory, UML kernel wastes one page memory.

Signed-off-by: Honggang Li <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
8 years agopercpu: perform tlb flush after pcpu_map_pages() failure
Tejun Heo [Fri, 15 Aug 2014 20:06:10 +0000 (16:06 -0400)]
percpu: perform tlb flush after pcpu_map_pages() failure

commit 849f5169097e1ba35b90ac9df76b5bb6f9c0aabd upstream.

If pcpu_map_pages() fails midway, it unmaps the already mapped pages.
Currently, it doesn't flush tlb after the partial unmapping.  This may
be okay in most cases as the established mapping hasn't been used at
that point but it can go wrong and when it goes wrong it'd be
extremely difficult to track down.

Flush tlb after the partial unmapping.

Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
8 years agopercpu: fix pcpu_alloc_pages() failure path
Tejun Heo [Fri, 15 Aug 2014 20:06:06 +0000 (16:06 -0400)]
percpu: fix pcpu_alloc_pages() failure path

commit f0d279654dea22b7a6ad34b9334aee80cda62cde upstream.

When pcpu_alloc_pages() fails midway, pcpu_free_pages() is invoked to
free what has already been allocated.  The invocation is across the
whole requested range and pcpu_free_pages() will try to free all
non-NULL pages; unfortunately, this is incorrect as
pcpu_get_pages_and_bitmap(), unlike what its comment suggests, doesn't
clear the pages array and thus the array may have entries from the
previous invocations making the partial failure path free incorrect

Fix it by open-coding the partial freeing of the already allocated

Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
8 years agoregulatory: add NUL to alpha2
Eliad Peller [Wed, 11 Jun 2014 07:23:35 +0000 (10:23 +0300)]
regulatory: add NUL to alpha2

commit a5fe8e7695dc3f547e955ad2b662e3e72969e506 upstream.

alpha2 is defined as 2-chars array, but is used in multiple
places as string (e.g. with nla_put_string calls), which
might leak kernel data.

Solve it by simply adding an extra char for the NULL
terminator, making such operations safe.

Signed-off-by: Eliad Peller <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoLinux 3.2.63
Ben Hutchings [Sat, 13 Sep 2014 22:41:52 +0000 (23:41 +0100)]
Linux 3.2.63

8 years agomicroblaze: Fix makefile to work with latest toolchain
Michal Simek [Mon, 5 Mar 2012 14:53:19 +0000 (15:53 +0100)]
microblaze: Fix makefile to work with latest toolchain

commit 00708d421a22a0f82de2dbb91ca6213b3dcc5267 upstream.

When building with latest binutils, vmlinux includes
some sections which need to be stripped out when building
the binary image.

Signed-off-by: Michal Simek <>
Signed-off-by: Ben Hutchings <>
8 years agox86/espfix/xen: Fix allocation of pages for paravirt page tables
Boris Ostrovsky [Wed, 9 Jul 2014 17:18:18 +0000 (13:18 -0400)]
x86/espfix/xen: Fix allocation of pages for paravirt page tables

commit 8762e5092828c4dc0f49da5a47a644c670df77f3 upstream.

init_espfix_ap() is currently off by one level when informing hypervisor
that allocated pages will be used for ministacks' page tables.

The most immediate effect of this on a PV guest is that if
'stack_page = __get_free_page()' returns a non-zeroed-out page the hypervisor
will refuse to use it for a page table (which it shouldn't be anyway). This will
result in warnings by both Xen and Linux.

More importantly, a subsequent write to that page (again, by a PV guest) is
likely to result in fatal page fault.

Signed-off-by: Boris Ostrovsky <>
Reviewed-by: Konrad Rzeszutek Wilk <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agox86_64/entry/xen: Do not invoke espfix64 on Xen
Andy Lutomirski [Wed, 23 Jul 2014 15:34:11 +0000 (08:34 -0700)]
x86_64/entry/xen: Do not invoke espfix64 on Xen

commit 7209a75d2009dbf7745e2fd354abf25c3deb3ca3 upstream.

This moves the espfix64 logic into native_iret.  To make this work,
it gets rid of the native patch for INTERRUPT_RETURN:
INTERRUPT_RETURN on native kernels is now 'jmp native_iret'.

This changes the 16-bit SS behavior on Xen from OOPSing to leaking
some bits of the Xen hypervisor's RSP (I think).

[ hpa: this is a nonzero cost on native, but probably not enough to
  measure. Xen needs to fix this in their own code, probably doing
  something equivalent to espfix64. ]

Signed-off-by: Andy Lutomirski <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agox86, espfix: Make it possible to disable 16-bit support
H. Peter Anvin [Sun, 4 May 2014 17:36:22 +0000 (10:36 -0700)]
x86, espfix: Make it possible to disable 16-bit support

commit 34273f41d57ee8d854dcd2a1d754cbb546cb548f upstream.

Embedded systems, which may be very memory-size-sensitive, are
extremely unlikely to ever encounter any 16-bit software, so make it
a CONFIG_EXPERT option to turn off support for any 16-bit software

Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agox86, espfix: Make espfix64 a Kconfig option, fix UML
H. Peter Anvin [Sun, 4 May 2014 17:00:49 +0000 (10:00 -0700)]
x86, espfix: Make espfix64 a Kconfig option, fix UML

commit 197725de65477bc8509b41388157c1a2283542bb upstream.

Make espfix64 a hidden Kconfig option.  This fixes the x86-64 UML
build which had broken due to the non-existence of init_espfix_bsp()
in UML: since UML uses its own Kconfig, this option does not appear in
the UML build.

This also makes it possible to make support for 16-bit segments a
configuration option, for the people who want to minimize the size of
the kernel.

Reported-by: Ingo Molnar <>
Signed-off-by: H. Peter Anvin <>
Cc: Richard Weinberger <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agox86, espfix: Fix broken header guard
H. Peter Anvin [Fri, 2 May 2014 18:33:51 +0000 (11:33 -0700)]
x86, espfix: Fix broken header guard

commit 20b68535cd27183ebd3651ff313afb2b97dac941 upstream.

Header guard is #ifndef, not #ifdef...

Reported-by: Fengguang Wu <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agox86, espfix: Move espfix definitions into a separate header file
H. Peter Anvin [Thu, 1 May 2014 21:12:23 +0000 (14:12 -0700)]
x86, espfix: Move espfix definitions into a separate header file

commit e1fe9ed8d2a4937510d0d60e20705035c2609aea upstream.

Sparse warns that the percpu variables aren't declared before they are
defined.  Rather than hacking around it, move espfix definitions into
a proper header file.

Reported-by: Fengguang Wu <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agox86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack
H. Peter Anvin [Tue, 29 Apr 2014 23:46:09 +0000 (16:46 -0700)]
x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack

commit 3891a04aafd668686239349ea58f3314ea2af86b upstream.

The IRET instruction, when returning to a 16-bit segment, only
restores the bottom 16 bits of the user space stack pointer.  This
causes some 16-bit software to break, but it also leaks kernel state
to user space.  We have a software workaround for that ("espfix") for
the 32-bit kernel, but it relies on a nonzero stack segment base which
is not available in 64-bit mode.

In checkin:

    b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

we "solved" this by forbidding 16-bit segments on 64-bit kernels, with
the logic that 16-bit support is crippled on 64-bit kernels anyway (no
V86 support), but it turns out that people are doing stuff like
running old Win16 binaries under Wine and expect it to work.

This works around this by creating percpu "ministacks", each of which
is mapped 2^16 times 64K apart.  When we detect that the return SS is
on the LDT, we copy the IRET frame to the ministack and use the
relevant alias to return to userspace.  The ministacks are mapped
readonly, so if IRET faults we promote #GP to #DF which is an IST
vector and thus has its own stack; we then do the fixup in the #DF

(Making #GP an IST exception would make the msr_safe functions unsafe
in NMI/MC context, and quite possibly have other effects.)

Special thanks to:

- Andy Lutomirski, for the suggestion of using very small stack slots
  and copy (as opposed to map) the IRET frame there, and for the
  suggestion to mark them readonly and let the fault promote to #DF.
- Konrad Wilk for paravirt fixup and testing.
- Borislav Petkov for testing help and useful comments.

Reported-by: Brian Gerst <>
Signed-off-by: H. Peter Anvin <>
Cc: Konrad Rzeszutek Wilk <>
Cc: Borislav Petkov <>
Cc: Andrew Lutomriski <>
Cc: Linus Torvalds <>
Cc: Dirk Hohndel <>
Cc: Arjan van de Ven <>
Cc: comex <>
Cc: Alexander van Heukelum <>
Cc: Boris Ostrovsky <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoRevert "x86-64, modify_ldt: Make support for 16-bit segments a runtime option"
H. Peter Anvin [Wed, 21 May 2014 17:22:59 +0000 (10:22 -0700)]
Revert "x86-64, modify_ldt: Make support for 16-bit segments a runtime option"

commit 7ed6fb9b5a5510e4ef78ab27419184741169978a upstream.

This reverts commit fa81511bb0bbb2b1aace3695ce869da9762624ff in
preparation of merging in the proper fix (espfix64).

Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>