Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 6月, 2013 17 次提交
  3. 31 5月, 2013 4 次提交
    • M
      arm64: don't kill the kernel on a bad esr from el0 · 9955ac47
      由 Mark Rutland 提交于 
      Rather than completely killing the kernel if we receive an esr value we
can't deal with in the el0 handlers, send the process a SIGILL and log
the esr value in the hope that we can debug it. If we receive a bad esr
from el1, we'll die() as before.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: stable@vger.kernel.org
      9955ac47
    • M
      arm64: treat unhandled compat el0 traps as undef · 381cc2b9
      由 Mark Rutland 提交于 
      Currently, if a compat process reads or writes from/to a disabled
cp15/cp14 register, the trap is not handled by the el0_sync_compat
handler, and the kernel will head to bad_mode, where it will die(), and
oops(). For 64 bit processes, disabled system register accesses are
currently treated as unhandled instructions.

This patch modifies entry.S to treat these unhandled traps as undefined
instructions, sending a SIGILL to userspace. This gives processes a
chance to handle this and stop using inaccessible registers, and
prevents further issues in the kernel as a result of the die().
Reported-by: NJohannes Jensen <Johannes.Jensen@arm.com>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      381cc2b9
    • P
      x86: Allow FPU to be used at interrupt time even with eagerfpu · 5187b28f
      由 Pekka Riikonen 提交于 
      With the addition of eagerfpu the irq_fpu_usable() now returns false
negatives especially in the case of ksoftirqd and interrupted idle task,
two common cases for FPU use for example in networking/crypto.  With
eagerfpu=off FPU use is possible in those contexts.  This is because of
the eagerfpu check in interrupted_kernel_fpu_idle():

...
  * For now, with eagerfpu we will return interrupted kernel FPU
  * state as not-idle. TBD: Ideally we can change the return value
  * to something like __thread_has_fpu(current). But we need to
  * be careful of doing __thread_clear_has_fpu() before saving
  * the FPU etc for supporting nested uses etc. For now, take
  * the simple route!
...
 	if (use_eager_fpu())
 		return 0;

As eagerfpu is automatically "on" on those CPUs that also have the
features like AES-NI this patch changes the eagerfpu check to return 1 in
case the kernel_fpu_begin() has not been said yet.  Once it has been the
__thread_has_fpu() will start returning 0.

Notice that with eagerfpu the __thread_has_fpu is always true initially.
FPU use is thus always possible no matter what task is under us, unless
the state has already been saved with kernel_fpu_begin().

[ hpa: this is a performance regression, not a correctness regression,
  but since it can be quite serious on CPUs which need encryption at
  interrupt time I am marking this for urgent/stable. ]
Signed-off-by: NPekka Riikonen <priikone@iki.fi>
Link: http://lkml.kernel.org/r/alpine.GSO.2.00.1305131356320.18@git.silcnet.org
Cc: <stable@vger.kernel.org> v3.7+
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      5187b28f
    • J
      x86, crc32-pclmul: Fix build with older binutils · 2baad612
      由 Jan Beulich 提交于 
      binutils prior to 2.18 (e.g. the ones found on SLE10) don't support
assembling PEXTRD, so a macro based approach like the one for PCLMULQDQ
in the same file should be used.

This requires making the helper macros capable of recognizing 32-bit
general purpose register operands.

[ hpa: tagging for stable as it is a low risk build fix ]
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Link: http://lkml.kernel.org/r/51A6142A02000078000D99D8@nat28.tlf.novell.com
Cc: Alexander Boyko <alexander_boyko@xyratex.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Huang Ying <ying.huang@intel.com>
Cc: <stable@vger.kernel.org> v3.9
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      2baad612
  5. 30 5月, 2013 4 次提交
  7. 29 5月, 2013 3 次提交
    • S
      xen: Clean up apic ipi interface · 1db01b49
      由 Stefan Bader 提交于 
      Commit f447d56d introduced the
implementation of the PV apic ipi interface. But there were some
odd things (it seems none of which cause really any issue but
maybe they should be cleaned up anyway):
 - xen_send_IPI_mask_allbutself (and by that xen_send_IPI_allbutself)
   ignore the passed in vector and only use the CALL_FUNCTION_SINGLE
   vector. While xen_send_IPI_all and xen_send_IPI_mask use the vector.
 - physflat_send_IPI_allbutself is declared unnecessarily. It is never
   used.

This patch tries to clean up those things.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      1db01b49
    • O
      ARM: exynos: defconfig update · da9d0fbf
      由 Olof Johansson 提交于 
      This turns on a number of configs that are useful on the Chromebook, but also
good to have on in general:

* USB host and MMC drivers(!)
* I2C GPIO arbitration driver
* CYAPA trackpad driver
* simplefb
* CROS EC and keyboard drivers
* S5M8767 driver
* MAX77686 drivers
* MAX8997 driver
* DEVTMPFS + mount
* DM_CRYPT (as module)
* CRYPTOLOOP
* HIGHMEM
* PRINTK timestamps

This also turns off DEBUG_LL, and switches the hardcoded Samsung lowlevel
uart to uart 3 (which is only used to show the "uncompressing kernel"
message at boot, it seems).
Signed-off-by: NOlof Johansson <olof@lixom.net>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NTushar Behera <tushar.behera@linaro.org>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
      da9d0fbf
    • Z
      x86-64, init: Fix a possible wraparound bug in switchover in head_64.S · e9d0626e
      由 Zhang Yanfei 提交于 
      In head_64.S, a switchover has been used to handle kernel crossing
1G, 512G boundaries.

And commit 8170e6be
    x86, 64bit: Use a #PF handler to materialize early mappings on demand
said:
    During the switchover in head_64.S, before #PF handler is available,
    we use three pages to handle kernel crossing 1G, 512G boundaries with
    sharing page by playing games with page aliasing: the same page is
    mapped twice in the higher-level tables with appropriate wraparound.

But from the switchover code, when we set up the PUD table:
114         addq    $4096, %rdx
115         movq    %rdi, %rax
116         shrq    $PUD_SHIFT, %rax
117         andl    $(PTRS_PER_PUD-1), %eax
118         movq    %rdx, (4096+0)(%rbx,%rax,8)
119         movq    %rdx, (4096+8)(%rbx,%rax,8)

It seems line 119 has a potential bug there. For example,
if the kernel is loaded at physical address 511G+1008M, that is
    000000000 111111111 111111000 000000000000000000000
and the kernel _end is 512G+2M, that is
    000000001 000000000 000000001 000000000000000000000
So in this example, when using the 2nd page to setup PUD (line 114~119),
rax is 511.
In line 118, we put rdx which is the address of the PMD page (the 3rd page)
into entry 511 of the PUD table. But in line 119, the entry we calculate from
(4096+8)(%rbx,%rax,8) has exceeded the PUD page. IMO, the entry in line
119 should be wraparound into entry 0 of the PUD table.

The patch fixes the bug.
Signed-off-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
Link: http://lkml.kernel.org/r/5191DE5A.3020302@cn.fujitsu.comSigned-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: <stable@vger.kernel.org> v3.9
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      e9d0626e
  9. 28 5月, 2013 2 次提交
  11. 27 5月, 2013 2 次提交
  13. 26 5月, 2013 1 次提交
  15. 25 5月, 2013 7 次提交
    • V
      ARC: lazy dcache flush broke gdb in non-aliasing configs · 7bb66f6e
      由 Vineet Gupta 提交于 
      gdbserver inserting a breakpoint ends up calling copy_user_page() for a
code page. The generic version of which (non-aliasing config) didn't set
the PG_arch_1 bit hence update_mmu_cache() didn't sync dcache/icache for
corresponding dynamic loader code page - causing garbade to be executed.

So now aliasing versions of copy_user_highpage()/clear_page() are made
default. There is no significant overhead since all of special alias
handling code is compiled out for non-aliasing build
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      7bb66f6e
    • T
      ARM: SAMSUNG: Add names to fimd0 IRQ resources · 15f504f0
      由 Tomasz Figa 提交于 
      Since commit 1977e6d8 (drm/exynos: change the method for getting the
interrupt) the Exynos DRM FIMD driver requires IRQ resources to be
named. This patch fixes probe failure in non-DT cases by adding
appropriate resource names to fimd0 platform device.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      15f504f0
    • J
      ARM: EXYNOS: fix software reset logic for EXYNOS5440 SOC · 1ba830c9
      由 Jungseok Lee 提交于 
      This patch fixes software reset logic. Software reset applies only to
powered-on domains in SOC because software reset to all domains causes
reboot failure.
Signed-off-by: NJungseok Lee <jays.lee@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      1ba830c9
    • H
      parisc: fix irq stack on UP and SMP · d96b51ec
      由 Helge Deller 提交于 
      The logic to detect if the irq stack was already in use with
raw_spin_trylock() is wrong, because it will generate a "trylock failure
on UP" error message with CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y.

arch_spin_trylock() can't be used either since in the CONFIG_SMP=n case
no atomic protection is given and we are reentrant here. A mutex didn't
worked either and brings more overhead by turning off interrupts.

So, let's use the fastest path for parisc which is the ldcw instruction.

Counting how often the irq stack was used is pretty useless, so just
drop this piece of code.
Signed-off-by: NHelge Deller <deller@gmx.de>
      d96b51ec
    • T
      ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC · 68a433f1
      由 Tomasz Figa 提交于 
      This patch extends exynos_init_time() function to handle Exynos4210
rev0 SoC, which differs in availability of system timers and needs
different clocksource initialization.

This makes it possible to use exynos_init_time() function as init_time
callback for all Exynos-based boards, including Universal_C210, which
originally had to use samsung_timer_init().
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      68a433f1
    • J
      parisc: make interrupt and interruption stack allocation reentrant · b63a2bbc
      由 John David Anglin 提交于 
      The get_stack_use_cr30 and get_stack_use_r30 macros allocate a stack
frame for external interrupts and interruptions requiring a stack frame.
They are currently not reentrant in that they save register context
before the stack is set or adjusted.

I have observed a number of system crashes where there was clear
evidence of stack corruption during interrupt processing, and as a
result register corruption. Some interruptions can still occur during
interruption processing, however external interrupts are disabled and
data TLB misses don't occur for absolute accesses. So, it's not entirely
clear what triggers this issue. Also, if an interruption occurs when
Q=0, it is generally not possible to recover as the shadowed registers
are not copied.

The attached patch reworks the get_stack_use_cr30 and get_stack_use_r30
macros to allocate stack before doing register saves. The new code is a
couple of instructions shorter than the old implementation. Thus, it's
an improvement even if it doesn't fully resolve the stack corruption
issue. Based on limited testing, it improves SMP system stability.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Signed-off-by: NHelge Deller <deller@gmx.de>
      b63a2bbc
    • H
      parisc: show number of FPE and unaligned access handler calls in /proc/interrupts · d0c3be80
      由 Helge Deller 提交于 
      Show number of floating point assistant and unaligned access fixup
handler in /proc/interrupts file.
Signed-off-by: NHelge Deller <deller@gmx.de>
      d0c3be80