linux-toradex.git/arch, branch v3.12.40

x86/irq: Check for valid irq descriptor in check_irq_vectors_for_cpu_disable()

2015-04-09T12:13:48+00:00

commit d97eb8966c91f2c9d05f0a22eb89ed5b76d966d1 upstream.

When an interrupt is migrated away from a cpu it will stay
in its vector_irq array until smp_irq_move_cleanup_interrupt
succeeded. The cfg->move_in_progress flag is cleared already
when the IPI was sent.

When the interrupt is destroyed after migration its 'struct
irq_desc' is freed and the vector_irq arrays are cleaned up.
But since cfg->move_in_progress is already 0 the references
at cpus before the last migration will not be cleared. So
this would leave a reference to an already destroyed irq
alive.

When the cpu is taken down at this point, the
check_irq_vectors_for_cpu_disable() function finds a valid irq
number in the vector_irq array, but gets NULL for its
descriptor and dereferences it, causing a kernel panic.

This has been observed on real systems at shutdown. Add a
check to check_irq_vectors_for_cpu_disable() for a valid
'struct irq_desc' to prevent this issue.

Signed-off-by: Joerg Roedel 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Jiang Liu 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: K. Y. Srinivasan 
Cc: Linus Torvalds 
Cc: Prarit Bhargava 
Cc: Rasmus Villemoes 
Cc: Yinghai Lu 
Cc: alnovak@suse.com
Cc: joro@8bytes.org
Link: http://lkml.kernel.org/r/20150204132754.GA10078@suse.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby

powerpc: Fix sys_call_table declaration to enable syscall tracing

2015-04-09T12:13:46+00:00

commit 1028ccf560b97adbf272381a61a67e17d44d1054 upstream.

Declaring sys_call_table as a pointer causes the compiler to generate
the wrong lookup code in arch_syscall_addr().

     :
        lis     r9,-16384
        rlwinm  r3,r3,2,0,29
  -     lwz     r11,30640(r9)
  -     lwzx    r3,r11,r3
  +     addi    r9,r9,30640
  +     lwzx    r3,r9,r3
        blr

The actual sys_call_table symbol, declared in assembler, is an
array. If we lie about that to the compiler we get the wrong code
generated, as above.

This definition seems only to be used by the syscall tracing code in
kernel/trace/trace_syscalls.c. With this patch I can successfully use
the syscall tracepoints:

  bash-3815  [002] ....   333.239082: sys_write -> 0x2
  bash-3815  [002] ....   333.239087: sys_dup2(oldfd: a, newfd: 1)
  bash-3815  [002] ....   333.239088: sys_dup2 -> 0x1
  bash-3815  [002] ....   333.239092: sys_fcntl(fd: a, cmd: 1, arg: 0)
  bash-3815  [002] ....   333.239093: sys_fcntl -> 0x1
  bash-3815  [002] ....   333.239094: sys_close(fd: a)
  bash-3815  [002] ....   333.239094: sys_close -> 0x0

Signed-off-by: Romeo Cane 
Signed-off-by: Michael Ellerman 
Signed-off-by: Jiri Slaby

x86/microcode/intel: Guard against stack overflow in the loader

2015-04-09T12:13:45+00:00

commit f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4 upstream.

mc_saved_tmp is a static array allocated on the stack, we need to make
sure mc_saved_count stays within its bounds, otherwise we're overflowing
the stack in _save_mc(). A specially crafted microcode header could lead
to a kernel crash or potentially kernel execution.

Signed-off-by: Quentin Casasnovas 
Cc: "H. Peter Anvin" 
Cc: Fenghua Yu 
Link: http://lkml.kernel.org/r/1422964824-22056-1-git-send-email-quentin.casasnovas@oracle.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Jiri Slaby

powerpc/smp: Wait until secondaries are active & online

2015-04-09T12:13:43+00:00

commit 875ebe940d77a41682c367ad799b4f39f128d3fa upstream.

Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
"kernel BUG at kernel/smpboot.c:134!" issue during boot:

  BUG_ON(td->cpu != smp_processor_id());

Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output confirms it:

  CPU: 0
  Comm: watchdog/130

The problem is that we aren't ensuring the CPU active bit is set for the
secondary before allowing the master to continue on. The master unparks
the secondary CPU's kthreads and the scheduler looks for a CPU to run
on. It calls select_task_rq() and realises the suggested CPU is not in
the cpus_allowed mask. It then ends up in select_fallback_rq(), and
since the active bit isnt't set we choose some other CPU to run on.

This seems to have been introduced by 6acbfb96976f "sched: Fix hotplug
vs. set_cpus_allowed_ptr()", which changed from setting active before
online to setting active after online. However that was in turn fixing a
bug where other code assumed an active CPU was also online, so we can't
just revert that fix.

The simplest fix is just to spin waiting for both active & online to be
set. We already have a barrier prior to set_cpu_online() (which also
sets active), to ensure all other setup is completed before online &
active are set.

Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
Signed-off-by: Michael Ellerman 
Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Jiri Slaby

ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE

2015-04-09T12:13:43+00:00

commit ded9477984690d026e46dd75e8157392cea3f13f upstream.

For LPAE, we have the following means for encoding writable or dirty
ptes:
                              L_PTE_DIRTY       L_PTE_RDONLY
    !pte_dirty && !pte_write        0               1
    !pte_dirty && pte_write         0               1
    pte_dirty && !pte_write         1               1
    pte_dirty && pte_write          1               0

So we can't distinguish between writeable clean ptes and read only
ptes. This can cause problems with ptes being incorrectly flagged as
read only when they are writeable but not dirty.

This patch renumbers L_PTE_RDONLY from AP[2] to a software bit #58,
and adds additional logic to set AP[2] whenever the pte is read only
or not dirty. That way we can distinguish between clean writeable ptes
and read only ptes.

HugeTLB pages will use this new logic automatically.

We need to add some logic to Transparent HugePages to ensure that they
correctly interpret the revised pgprot permissions (L_PTE_RDONLY has
moved and no longer matches PMD_SECT_AP2). In the process of revising
THP, the names of the PMD software bits have been prefixed with L_ to
make them easier to distinguish from their hardware bit counterparts.

Signed-off-by: Steve Capper 
Reviewed-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby  [dump.c is not in 3.12]

ARM: 8108/1: mm: Introduce {pte,pmd}_isset and {pte,pmd}_isclear

2015-04-09T12:13:42+00:00

commit f2950706871c4b6e8c0f0d7c3f62d35930b8de63 upstream.

Long descriptors on ARM are 64 bits, and some pte functions such as
pte_dirty return a bitwise-and of a flag with the pte value. If the
flag to be tested resides in the upper 32 bits of the pte, then we run
into the danger of the result being dropped if downcast.

For example:
	gather_stats(page, md, pte_dirty(*pte), 1);
where pte_dirty(*pte) is downcast to an int.

This patch introduces a new macro pte_isset which performs the bitwise
and, then performs a double logical invert (where needed) to ensure
predictable downcasting. The logical inverse pte_isclear is also
introduced.

Equivalent pmd functions for Transparent HugePages have also been
added.

Signed-off-by: Steve Capper 
Reviewed-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARM: 7931/1: Correct virt_addr_valid

2015-04-09T12:13:41+00:00

commit efea3403d4b7c6d1dd5d5ac3234c161e8b314d66 upstream.

The definition of virt_addr_valid is that virt_addr_valid should
return true if and only if virt_to_page returns a valid pointer.
The current definition of virt_addr_valid only checks against the
virtual address range. There's no guarantee that just because a
virtual address falls bewteen PAGE_OFFSET and high_memory the
associated physical memory has a valid backing struct page. Follow
the example of other architectures and convert to pfn_valid to
verify that the virtual address is actually valid. The check for
an address between PAGE_OFFSET and high_memory is still necessary
as vmalloc/highmem addresses are not valid with virt_to_page.

Cc: Will Deacon 
Cc: Nicolas Pitre 
Acked-by: Will Deacon 
Signed-off-by: Laura Abbott 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARM: 7867/1: include: asm: use 'int' instead of 'unsigned long' for 'oldval' in atomic_cmpxchg().

2015-04-09T12:13:41+00:00

commit 4dcc1cf7316a26e112f5c9fcca531ff98ef44700 upstream.

For atomic_cmpxchg(), the type of 'oldval' need be 'int' to match the
type of "*ptr" (used by 'ldrex' instruction) and 'old' (used by 'teq'
instruction).

Reviewed-by: Will Deacon 
Signed-off-by: Chen Gang 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARM: 7866/1: include: asm: use 'long long' instead of 'u64' within atomic.h

2015-04-09T12:13:40+00:00

commit 237f12337cfa2175474e4dd015bc07a25eb9080d upstream.

atomic* value is signed value, and atomic* functions need also process
signed value (parameter value, and return value), so 32-bit arm need
use 'long long' instead of 'u64'.

After replacement, it will also fix a bug for atomic64_add_negative():
"u64 is never less than 0".

The modifications are:

  in vim, use "1,% s/\/long long/g" command.
  remove '__aligned(8)' which is useless for 64-bit.
  be sure of 80 column limitation after replacement.

Acked-by: Will Deacon 
Signed-off-by: Chen Gang 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARC: [nsimosci] move peripherals to match model to FPGA

2015-04-09T12:13:39+00:00

commit e8ef060b37c2d3cc5fd0c0edbe4e42ec1cb9768b upstream.

This allows the sdplite/Zebu images to run on OSCI simulation platform

Signed-off-by: Vineet Gupta 
Cc:  #3.10, 3.12, 3.14, 3.16
Signed-off-by: Jiri Slaby