- 13 11月, 2012 2 次提交
-
-
由 Ralf Baechle 提交于
The CBUS UART's interrupt number was wrong conflicting with the interrupt being tied to the Intel PIIX4. Since the PIIX4's interrupt is registered before the CBUS UART which is not being used on most systems this would not be noticed. Attempts to open the ttyS2 CBUS UART would result in: genirq: Flags mismatch irq 18. 00000000 (serial) vs. 00010000 (XT-PIC cascade) serial_link_irq_chain: request failed: -16 for irq: 18 Qemu was written to match the kernel so will need to be fixed also. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Petr Matousek 提交于
On hosts without the XSAVE support unprivileged local user can trigger oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN ioctl. invalid opcode: 0000 [#2] SMP Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables ... Pid: 24935, comm: zoog_kvm_monito Tainted: G D 3.2.0-3-686-pae EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0 EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0 task.ti=d7c62000) Stack: 00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000 ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0 c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80 Call Trace: [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm] ... [<c12bfb44>] ? syscall_call+0x7/0xb Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74 1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01 d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89 EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP 0068:d7c63e70 QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID and then sets them later. So guest's X86_FEATURE_XSAVE should be masked out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with X86_FEATURE_XSAVE even on hosts that do not support it, might be susceptible to this attack from inside the guest as well. Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support. Signed-off-by: NPetr Matousek <pmatouse@redhat.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
- 10 11月, 2012 4 次提交
-
-
由 David S. Miller 提交于
We tried linking in a single built object to hold the device table, but only works if all of the sparc64 crypto modules get built the same way (modular vs. non-modular). Just include the device ID stub into each driver source file so that the table gets compiled into the correct result in all cases. Reported-by: NMeelis Roos <mroos@linux.ee> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Sparc32 already supported it, as a consequence of using the generic atomic64 implementation. And the sparc64 implementation is rather trivial. This allows us to set ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE for all of sparc, and avoid the annoying warning from lib/atomic64_test.c Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andreas Larsson 提交于
This bug-fix makes sure that of_address_to_resource is defined extern for sparc so that the sparc-specific implementation of of_address_to_resource() is once again used when including include/linux/of_address.h in a sparc context. A number of drivers in mainline relies on this function working for sparc. The bug was introduced in a850a755, "of/address: add empty static inlines for !CONFIG_OF". Contrary to that commit title, the static inlines are added for !CONFIG_OF_ADDRESS, and CONFIG_OF_ADDRESS is never defined for sparc. This is good behavior for the other functions in include/linux/of_address.h, as the extern functions defined in drivers/of/address.c only gets linked when OF_ADDRESS is configured. However, for of_address_to_resource there exists a sparc-specific implementation in arch/sparc/arch/sparc/kernel/of_device_common.c Solution suggested by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: NAndreas Larsson <andreas@gaisler.com> Acked-by: NRob Herring <rob.herring@calxeda.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andreas Larsson 提交于
If an irq is being unlinked concurrently with leon_handle_ext_irq, irq_map[eirq] might be null in leon_handle_ext_irq. Make sure that this is not dereferenced. Signed-off-by: NAndreas Larsson <andreas@gaisler.com> Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 11月, 2012 13 次提交
-
-
由 Stefano Stabellini 提交于
The commit 911dec0d "xen/arm: Fix compile errors when drivers are compiled as modules." exports the neccessary functions. But to guard ourselves against out-of-tree modules and future drivers hitting this, lets export all of the relevant hypercalls. Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Jim Quinlan 提交于
For non MIPSr2 processors, such as the BMIPS 5000, calls to arch_local_irq_disable() and others may be preempted, and in doing so a stale value may be restored to c0_status. This fix disables preemption for such processors prior to the call and enables it after the call. Those functions that needed this fix have been "outlined" to mips-atomic.c, as they are no longer good candidates for inlining. This bug was observed in a BMIPS 5000, occuring once every few hours in a continuous reboot test. It was traced to the write_lock_irq() function which was being invoked in release_task() in exit.c. By placing a number of "nops" inbetween the mfc0/mtc0 pair in arch_local_irq_disable(), which is called by write_lock_irq(), we were able to greatly increase the occurance of this bug. Similarly, the application of this commit silenced the bug. Signed-off-by: NJim Quinlan <jim2101024@gmail.com> Cc: linux-mips@linux-mips.org Cc: David Daney <ddaney.cavm@gmail.com> Cc: Kevin Cernekee cernekee@gmail.com Cc: Jim Quinlan <jim2101024@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/4321/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Jim Quinlan 提交于
The "else clause" of most functions in bitops.h invoked raw_local_irq_{save,restore}() and in doing so had a dependency on irqflags.h. This fix moves said code to bitops.c, removing the dependency. Signed-off-by: NJim Quinlan <jim2101024@gmail.com> Cc: linux-mips@linux-mips.org Cc: David Daney <ddaney.cavm@gmail.com> Cc: Kevin Cernekee cernekee@gmail.com Cc: Jim Quinlan <jim2101024@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/4320/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Jim Quinlan 提交于
[ralf@linux-mips.org: No functional change but it's consistent with how use types elsewhere in the code.] Signed-off-by: NJim Quinlan <jim2101024@gmail.com> Cc: linux-mips@linux-mips.org Cc: David Daney <ddaney.cavm@gmail.com> Cc: Kevin Cernekee cernekee@gmail.com Cc: Jim Quinlan <jim2101024@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/4319/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
So far is_compat_task() was testing for 32-bit registers if O32 support was enabled and if O32 support was disabled but N32 enabled it was testing for 32-bit address space. So if both O32 and N32 were enabled a N32 task was not considered a compat task, whops. This still leaves potential cases where O32 and N32 need different treatment unsolved. But that's another commit. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Fengguang Wu 提交于
Fix the build error lib/atomic64.c: In function 'lock_addr': lib/atomic64.c:40:11: error: 'L1_CACHE_SHIFT' undeclared (first use in this function) lib/atomic64.c:40:11: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Will Deacon 提交于
Booting on a system with all of its memory above the 4GB boundary breaks for two reasons: (1) We still try to create a non-empty DMA32 zone (2) no-bootmem limits allocations to 0xffffffff This patch fixes these issues for ARM64. Tested-by: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Will Deacon 提交于
Commit 149c2415 ("ARM: SMP: use a timing out completion for cpu hotplug") modified arm's CPU up path to use completions. It seems that we only got half of this patch for arm64, so add the missing call to complete. Reported-by: NJon Brawn <jon.brawn@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Will Deacon 提交于
Commit c1d7e01d ("ipc: use Kconfig options for __ARCH_WANT_[COMPAT_]IPC_PARSE_VERSION") replaced the __ARCH_WANT_COMPAT_IPC_PARSE_VERSION token with a corresponding Kconfig option instead. This patch updates arm64 to use the latter, rather than #define an unused token. Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Will Deacon 提交于
struct user_fp does not exist for arm64, so use struct user_fpsimd_state instead for the ELF core dumping definitions. Furthermore, since we use regset-based core dumping, we do not need definitions for dump_task_regs and dump_fpu. Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Will Deacon 提交于
We currently use a fake event encoding (0xFF) to indicate CPU cycles so that we don't waste an event counter and can target the hardware cycle counter instead. The problem with this approach is that the event space defined by the architecture permits an implementation to allocate 0xFF for some other event. This patch uses the architected cycle counter encoding (0x11) so that we avoid potentially clashing with event encodings on future CPU implementations. Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
- 07 11月, 2012 3 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
We end up with: ERROR: "HYPERVISOR_event_channel_op" [drivers/xen/xen-gntdev.ko] undefined! ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined! ERROR: "HYPERVISOR_grant_table_op" [drivers/net/xen-netback/xen-netback.ko] undefined! and this patch exports said function (which is implemented in hypercall.S). Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: NIan Campbell <ian.campbell@citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Heiko Carstens 提交于
The early mini sclp driver may be called in zArch mode either in 31 or 64 bit addressing mode. If called in 31 bit addressing mode the new external interrupt psw however would switch to 64 bit addressing mode. This would cause an addressing exception within the interrupt handler, since the code didn't expect the zArch/31 bit addressing mode combination. Fix this by setting the new psw addressing mode bits so they fit the current addressing mode. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Cornelia Huck 提交于
There's no need to keep __MAX_SUBCHANNEL and __MAX_SSID private to the common I/O layer when __MAX_CSSID is usable by everybody. Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 04 11月, 2012 2 次提交
-
-
由 Jan Beulich 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJan 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: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 viresh kumar 提交于
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: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 03 11月, 2012 2 次提交
-
-
由 Al Viro 提交于
Just get %icc2 into the state we would have after local_irq_disable() and physical IRQ having happened since then. Then we can simply use preempt_schedule_irq() and be done with the whole mess. Acked-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 02 11月, 2012 4 次提交
-
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com>
-
由 David Howells 提交于
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: NAl Viro <viro@ZenIV.linux.org.uk> Signed-off-by: NDavid Howells <dhowells@redhat.com> cc: Al Viro <viro@ZenIV.linux.org.uk>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com>
-
由 David Howells 提交于
Add missing linux/export.h #inclusions to the FRV arch. Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
- 01 11月, 2012 2 次提交
-
-
由 Xiao Guangrong 提交于
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: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
由 Konrad Rzeszutek Wilk 提交于
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: NJingjie Jiang <jingjie.jiang@oracle.com> Suggested-by: NMukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 30 10月, 2012 2 次提交
-
-
由 Stefano Stabellini 提交于
Use the new __HVC macro in hypercall.S. Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Olaf Hering 提交于
Signed-off-by: NOlaf Hering <olaf@aepfle.de> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 29 10月, 2012 5 次提交
-
-
由 Will Deacon 提交于
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: NBastian Hecht <hechtb@googlemail.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Paul Walmsley 提交于
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-g759e00b8 #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: NPaul 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: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Felipe Balbi 2 提交于
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: NKevin Hilman <khilman@ti.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
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: NDavid S. Miller <davem@davemloft.net>
-
- 28 10月, 2012 1 次提交
-
-
由 David S. Miller 提交于
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: NDavid S. Miller <davem@davemloft.net>
-