Skip to content
  1. Nov 22, 2012
  3. Nov 10, 2012
  5. Nov 09, 2012
  7. Nov 07, 2012
  9. Nov 04, 2012
    • Jan Beulich's avatar
      xen/hypercall: fix hypercall fallback code for very old hypervisors · cf47a83f
      Jan Beulich authored 
      

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.

Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
[v3: Fix compile errors when modules use said hypercalls]
[v4: Add xen_ prefix to the HYPERCALL_..]
[v5: Alter the name and only EXPORT_SYMBOL_GPL one of them]
Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      cf47a83f
    • viresh kumar's avatar
      ARM: 7569/1: mm: uninitialized warning corrections · 6404f0b7
      viresh kumar authored 
      

The variables here are really not used uninitialized.

arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: warning: 'offset.un' may be used uninitialized in this function [-Wmaybe-uninitialized]
arch/arm/mm/alignment.c:748:21: note: 'offset.un' was declared here

Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      6404f0b7
  11. Nov 03, 2012
  13. Nov 02, 2012
    • David Howells's avatar
      FRV: Fix the new-style kernel_thread() stuff · e7aa51b2
      David Howells authored 
      

The kernel_thread() changes for FRV don't work, and FRV fails to boot,
starting with:

	commit 02ce496f
	Author: Al Viro <viro@zeniv.linux.org.uk>
	Date:   Tue Sep 18 22:18:51 2012 -0400
	Subject: frv: split ret_from_fork, simplify kernel_thread() a lot

The problem is that the userspace registers are completely cleared when a
kernel thread is created and all subsequent user threads are then copied from
that.  Unfortunately, however, the TBR and PSR registers are restored from the
pt_regs and the values they should be set to are clobbered by the memset.

Instead, copy across the old user registers as normal, and then merely alter
GR8 and GR9 in it if we're going to execute a kernel thread.

Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      e7aa51b2
    • David Howells's avatar
      FRV: Fix the preemption handling · 1ee6f566
      David Howells authored 
      

Fix the preemption handling in FRV code where the PREEMPT_ACTIVE value is
incorrectly loaded into the threadinfo flags rather than the threadinfo
preemption count.

Unfortunately, the code cannot be simply converted to use
preempt_schedule_irq() as is because FRV uses virtual interrupt disablement to
cut down on the cost of actually disabling interrupts and thus
local_irq_enable() doesn't actually enable interrupts.

Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
cc: Al Viro <viro@ZenIV.linux.org.uk>
      1ee6f566
    • David Howells's avatar
      FRV: Don't objcopy the GNU build_id note · 5f0231d9
      David Howells authored 
      

Don't let objcopy transfer the GNU build_id note into the loadable image as it
is located at address 0 and the image ends up >3G in size.

Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      5f0231d9
    • David Howells's avatar
      FRV: Add missing linux/export.h #inclusions · a5788caa
      David Howells authored 
      

Add missing linux/export.h #inclusions to the FRV arch.

Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      a5788caa
  15. Nov 01, 2012
    • Xiao Guangrong's avatar
      KVM: x86: fix vcpu->mmio_fragments overflow · 87da7e66
      Xiao Guangrong authored 
      

After commit b3356bf0 (KVM: emulator: optimize "rep ins" handling),
the pieces of io data can be collected and write them to the guest memory
or MMIO together

Unfortunately, kvm splits the mmio access into 8 bytes and store them to
vcpu->mmio_fragments. If the guest uses "rep ins" to move large data, it
will cause vcpu->mmio_fragments overflow

The bug can be exposed by isapc (-M isapc):

[23154.818733] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
[ ......]
[23154.858083] Call Trace:
[23154.859874]  [<ffffffffa04f0e17>] kvm_get_cr8+0x1d/0x28 [kvm]
[23154.861677]  [<ffffffffa04fa6d4>] kvm_arch_vcpu_ioctl_run+0xcda/0xe45 [kvm]
[23154.863604]  [<ffffffffa04f5a1a>] ? kvm_arch_vcpu_load+0x17b/0x180 [kvm]

Actually, we can use one mmio_fragment to store a large mmio access then
split it when we pass the mmio-exit-info to userspace. After that, we only
need two entries to store mmio info for the cross-mmio pages access

Signed-off-by: default avatarXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      87da7e66
    • Konrad Rzeszutek Wilk's avatar
      xen/mmu: Use Xen specific TLB flush instead of the generic one. · 95a7d768
      Konrad Rzeszutek Wilk authored 
      

As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the
hypervisor to do a TLB flush on all active vCPUs. If instead
we were using the generic one (which ends up being xen_flush_tlb)
we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But
before we make that hypercall the kernel will IPI all of the
vCPUs (even those that were asleep from the hypervisor
perspective). The end result is that we needlessly wake them
up and do a TLB flush when we can just let the hypervisor
do it correctly.

This patch gives around 50% speed improvement when migrating
idle guest's from one host to another.

Oracle-bug: 14630170

CC: stable@vger.kernel.org
Tested-by: default avatarJingjie Jiang <jingjie.jiang@oracle.com>
Suggested-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      95a7d768
  17. Oct 30, 2012
  19. Oct 29, 2012
    • Will Deacon's avatar
      ARM: 7567/1: io: avoid GCC's offsettable addressing modes for halfword accesses · 7629a9f6
      Will Deacon authored 
      Using the 'o' memory constraint in inline assembly can result in GCC
generating invalid immediate offsets for memory access instructions with
reduced addressing capabilities (i.e. smaller than 12-bit immediate
offsets):

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983



As there is no constraint to specify the exact addressing mode we need,
fallback to using 'Q' exclusively for halfword I/O accesses. This may
emit an additional add instruction (using an extra register) in order
to construct the address but it will always be accepted by GAS.

Reported-by: default avatarBastian Hecht <hechtb@googlemail.com>
Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7629a9f6
    • Paul Walmsley's avatar
      ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set · 39141ddf
      Paul Walmsley authored 
      After commit 846a1368 ("ARM: vfp: fix
saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
started crashing during boot with omap2plus_defconfig:

[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug
in commit 5aaf2544 ("ARM: 6203/1: Make
VFPv3 usable on ARMv6").  When CONFIG_VFPv3 is set, but the kernel is
booted on a pre-VFPv3 core, the code attempts to save and restore the
d16-d31 VFP registers.  These are only present on non-D16 VFPv3+, so
this results in an undefined instruction exception.  The code didn't
crash before commit 846a1368 because the save and restore code was
only touching d0-d15, present on all VFP.

Fix by implementing a request from Russell King to add a new HWCAP
flag that affirmatively indicates the presence of the d16-d31
registers:

   http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2



and some feedback from Måns to clarify the name of the HWCAP flag.

Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Måns Rullgård <mans.rullgard@linaro.org>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      39141ddf
    • Felipe Balbi 2's avatar
      ARM: 7565/1: sched: stop sched_clock() during suspend · 6a4dae5e
      Felipe Balbi 2 authored 
      

The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that any RT thread will be rescheduled in the future
which might cause any sort of problems.

This became an issue on OMAP when we converted omap-i2c.c
to use threaded IRQs, it turned out that depending on how
much time we spent on suspend, the I2C IRQ thread would
end up being rescheduled so far in the future that I2C
transfers would timeout and, because omap_hsmmc depends
on an I2C-connected device to detect if an MMC card is
inserted in the slot, our rootfs would just vanish.

arch/arm/kernel/sched_clock.c already had an optional
implementation (sched_clock_needs_suspend()) which would
handle scheduler's requirement properly, what this patch
does is simply to make that implementation non-optional.

Note that this has the side-effect that printk timings
won't reflect the actual time spent on suspend so other
methods to measure that will have to be used.

This has been tested with beagleboard XM (OMAP3630) and
pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
after this patch.

Thanks to Kevin Hilman for helping out with debugging.

Acked-by: default avatarKevin Hilman <khilman@ti.com>
Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      6a4dae5e
    • David S. Miller's avatar
      sparc: Wire up sys_kcmp. · 1df35f80
      David S. Miller authored 
      

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1df35f80
    • David S. Miller's avatar
      sparc64: Improvde documentation and readability of atomic backoff code. · 187818cd
      David S. Miller authored 
      

Document what's going on in asm/backoff.h with a large and descriptive
comment.  Refer to it above the cpu_relax() definition in
asm/processor_64.h

Rename the pause patching section to have "3insn" in it's name like
the other patching sections do.

Based upon feedback from Sam Ravnborg.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      187818cd
  21. Oct 28, 2012
    • David S. Miller's avatar
      sparc64: Use pause instruction when available. · e9b9eb59
      David S. Miller authored 
      

In atomic backoff and cpu_relax(), use the pause instruction
found on SPARC-T4 and later.

It makes the cpu strand unselectable for the given number of
cycles, unless an intervening disrupting trap occurs.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9b9eb59
    • David S. Miller's avatar
      sparc64: Fix cpu strand yielding. · 270c10e0
      David S. Miller authored 
      

For atomic backoff, we just loop over an exponentially backed off
counter.  This is extremely ineffective as it doesn't actually yield
the cpu strand so that other competing strands can use the cpu core.

In cpus previous to SPARC-T4 we have to do this in a slightly hackish
way, by doing an operation with no side effects that also happens to
mark the strand as unavailable.

The mechanism we choose for this is three reads of the %ccr
(condition-code) register into %g0 (the zero register).

SPARC-T4 has an explicit "pause" instruction, and we'll make use of
that in a subsequent commit.

Yield strands also in cpu_relax().  We really should have done this a
very long time ago.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      270c10e0
  23. Oct 27, 2012
    • Arnd Bergmann's avatar
      Revert "ARM i.MX25: Fix PWM per clock lookups" · 943bb487
      Arnd Bergmann authored 
      

This reverts commit 92063cee, it
was applied prematurely, causing this build error for
imx_v4_v5_defconfig:

arch/arm/mach-imx/clk-imx25.c: In function 'mx25_clocks_init':
arch/arm/mach-imx/clk-imx25.c:206:26: error: 'pwm_ipg_per' undeclared (first use in this function)
arch/arm/mach-imx/clk-imx25.c:206:26: note: each undeclared identifier is reported only once for each function it appears in

Sascha Hauer explains:
> There are several gates missing in clk-imx25.c. I have a patch which
> adds support for them and I seem to have missed that the above depends
> on it.

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      943bb487
    • Arnd Bergmann's avatar
      ARM: versatile: fix versatile_defconfig · 5b627ba0
      Arnd Bergmann authored 
      

With the introduction of CONFIG_ARCH_MULTIPLATFORM, versatile is
no longer the default platform, so we need to enable
CONFIG_ARCH_VERSATILE explicitly in order for that to be selected
rather than the multiplatform configuration.

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      5b627ba0
    • Thomas Petazzoni's avatar
      ARM: mvebu: update defconfig with 3.7 changes · e09348c7
      Thomas Petazzoni authored 
      

The split of 370 and XP into two Kconfig options and the multiplatform
kernel support has changed a few Kconfig symbols, so let's update the
mvebu_defconfig file with the latest changes.

Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      e09348c7
    • Arnd Bergmann's avatar
      ARM: at91: fix at91x40 build · 0654f4ab
      Arnd Bergmann authored 
      

patch 738a0fd7 "ARM: at91: fix external interrupts in non-DT case"
fixed a run-time error on some at91 platforms but did not apply
the same change to at91x40, which now doesn't build.

This changes at91x40 in the same way that the other platforms
were changed.

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Acked-by: default avatarJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      0654f4ab
    • David S. Miller's avatar
      sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads. · 517ffce4
      David S. Miller authored 
      

The Montgomery Multiply, Montgomery Square, and Multiple-Precision
Multiply instructions work by loading a combination of the floating
point and multiple register windows worth of integer registers
with the inputs.

These values are 64-bit.  But for 32-bit userland processes we only
save the low 32-bits of each integer register during a register spill.
This is because the register window save area is in the user stack and
has a fixed layout.

Therefore, the only way to use these instruction in 32-bit mode is to
perform the following sequence:

1) Load the top-32bits of a choosen integer register with a sentinel,
   say "-1".  This will be in the outer-most register window.

   The idea is that we're trying to see if the outer-most register
   window gets spilled, and thus the 64-bit values were truncated.

2) Load all the inputs for the montmul/montsqr/mpmul instruction,
   down to the inner-most register window.

3) Execute the opcode.

4) Traverse back up to the outer-most register window.

5) Check the sentinel, if it's still "-1" store the results.
   Otherwise retry the entire sequence.

This retry is extremely troublesome.  If you're just unlucky and an
interrupt or other trap happens, it'll push that outer-most window to
the stack and clear the sentinel when we restore it.

We could retry forever and never make forward progress if interrupts
arrive at a fast enough rate (consider perf events as one example).
So we have do limited retries and fallback to software which is
extremely non-deterministic.

Luckily it's very straightforward to provide a mechanism to let
32-bit applications use a 64-bit stack.  Stacks in 64-bit mode are
biased by 2047 bytes, which means that the lowest bit is set in the
actual %sp register value.

So if we see bit zero set in a 32-bit application's stack we treat
it like a 64-bit stack.

Runtime detection of such a facility is tricky, and cumbersome at
best.  For example, just trying to use a biased stack and seeing if it
works is hard to recover from (the signal handler will need to use an
alt stack, plus something along the lines of longjmp).  Therefore, we
add a system call to report a bitmask of arch specific features like
this in a cheap and less hairy way.

With help from Andy Polyakov.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      517ffce4
  25. Oct 26, 2012