Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 5月, 2015 4 次提交
  3. 30 4月, 2015 2 次提交
    • M
      s390/bpf: Fix gcov stack space problem · b9b4b1ce
      由 Michael Holzheu 提交于 
      When compiling the kernel for GCOV (CONFIG_GCOV_KERNEL,-fprofile-arcs),
gcc allocates a lot of stack space because of the large switch statement
in bpf_jit_insn().

This leads to the following compile warning:

 arch/s390/net/bpf_jit_comp.c: In function 'bpf_jit_prog':
 arch/s390/net/bpf_jit_comp.c:1144:1: warning: frame size of
  function 'bpf_jit_prog' is 12592 bytes which is more than
  half the stack size. The dynamic check would not be reliable.
  No check emitted for this function.

 arch/s390/net/bpf_jit_comp.c:1144:1: warning: the frame size of 12504
  bytes is larger than 1024 bytes [-Wframe-larger-than=]

And indead gcc allocates 12592 bytes of stack space:

 # objdump -d arch/s390/net/bpf_jit_comp.o
 ...
 0000000000000c60 <bpf_jit_prog>:
     c60:       eb 6f f0 48 00 24       stmg    %r6,%r15,72(%r15)
     c66:       b9 04 00 ef             lgr     %r14,%r15
     c6a:       e3 f0 fe d0 fc 71       lay     %r15,-12592(%r15)

As a workaround of that problem we now define bpf_jit_insn() as
noinline which then reduces the stack space.

 # objdump -d arch/s390/net/bpf_jit_comp.o
 ...
 0000000000000070 <bpf_jit_insn>:
      70:       eb 6f f0 48 00 24       stmg    %r6,%r15,72(%r15)
      76:       c0 d0 00 00 00 00       larl    %r13,76 <bpf_jit_insn+0x6>
      7c:       a7 f1 3f 80             tmll    %r15,16256
      80:       b9 04 00 ef             lgr     %r14,%r15
      84:       e3 f0 ff a0 ff 71       lay     %r15,-96(%r15)
Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      b9b4b1ce
    • M
      s390/bpf: Adjust ALU64_DIV/MOD to match interpreter change · 771aada9
      由 Michael Holzheu 提交于 
      The s390x ALU64_DIV/MOD has been implemented according to the eBPF
interpreter specification that used do_div(). This function does a 64-bit
by 32-bit divide. It turned out that this was wrong and now the interpreter
uses div64_u64_rem() for full 64-bit division.

So fix this and use full 64-bit division in the s390x eBPF backend code.
Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      771aada9
  5. 28 4月, 2015 1 次提交
  7. 27 4月, 2015 1 次提交
  9. 24 4月, 2015 6 次提交
    • L
      x86: fix special __probe_kernel_write() tail zeroing case · d869844b
      由 Linus Torvalds 提交于 
      Commit cae2a173 ("x86: clean up/fix 'copy_in_user()' tail zeroing")
fixed the failure case tail zeroing of one special case of the x86-64
generic user-copy routine, namely when used for the user-to-user case
("copy_in_user()").

But in the process it broke an even more unusual case: using the user
copy routine for kernel-to-kernel copying.

Now, normally kernel-kernel copies are obviously done using memcpy(),
but we have a couple of special cases when we use the user-copy
functions.  One is when we pass a kernel buffer to a regular user-buffer
routine, using set_fs(KERNEL_DS).  That's a "normal" case, and continued
to work fine, because it never takes any faults (with the possible
exception of a silent and successful vmalloc fault).

But Jan Beulich pointed out another, very unusual, special case: when we
use the user-copy routines not because it's a path that expects a user
pointer, but for a couple of ftrace/kgdb cases that want to do a kernel
copy, but do so using "unsafe" buffers, and use the user-copy routine to
gracefully handle faults.  IOW, for probe_kernel_write().

And that broke for the case of a faulting kernel destination, because we
saw the kernel destination and wanted to try to clear the tail of the
buffer.  Which doesn't work, since that's what faults.

This only triggers for things like kgdb and ftrace users (eg trying
setting a breakpoint on read-only memory), but it's definitely a bug.
The fix is to not compare against the kernel address start (TASK_SIZE),
but instead use the same limits "access_ok()" uses.
Reported-and-tested-by: NJan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org # 4.0
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d869844b
    • A
      crypto: x86/sha512_ssse3 - fixup for asm function prototype change · 00425bb1
      由 Ard Biesheuvel 提交于 
      Patch e68410eb ("crypto: x86/sha512_ssse3 - move SHA-384/512
SSSE3 implementation to base layer") changed the prototypes of the
core asm SHA-512 implementations so that they are compatible with
the prototype used by the base layer.

However, in one instance, the register that was used for passing the
input buffer was reused as a scratch register later on in the code,
and since the input buffer param changed places with the digest param
-which needs to be written back before the function returns- this
resulted in the scratch register to be dereferenced in a memory write
operation, causing a GPF.

Fix this by changing the scratch register to use the same register as
the input buffer param again.

Fixes: e68410eb ("crypto: x86/sha512_ssse3 - move SHA-384/512 SSSE3 implementation to base layer")
Reported-By: NBobby Powers <bobbypowers@gmail.com>
Tested-By: NBobby Powers <bobbypowers@gmail.com>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      00425bb1
    • L
      nios2: rework cache · 1a70db49
      由 Ley Foon Tan 提交于 
      - flush dcache before flush instruction cache
- remork update_mmu_cache and flush_dcache_page
- add shmparam.h
Signed-off-by: NLey Foon Tan <lftan@altera.com>
      1a70db49
    • E
      nios2: Add types.h header required for __u32 type · 2009337e
      由 Ezequiel Garcia 提交于 
      Reported by the header checker (CONFIG_HEADERS_CHECK=y):

  CHECK   usr/include/asm/ (31 files)
./usr/include/asm/ptrace.h:77: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Acked-by: NLey Foon Tan <lftan@altera.com>
      2009337e
    • S
      eth: bf609 eth clock: add pclk clock for stmmac driver probe · d91e14b3
      由 Steven Miao 提交于 
      Signed-off-by: NSteven Miao <realmz6@gmail.com>
      d91e14b3
    • C
      blackfin: Wire up missing syscalls · 4f650a59
      由 Chen Gang 提交于 
      The related syscalls are below which may cause samples/kdbus building
break in next-20150401 tree, the related information and error:

    CALL    scripts/checksyscalls.sh
  <stdin>:1223:2: warning: #warning syscall kcmp not implemented [-Wcpp]
  <stdin>:1226:2: warning: #warning syscall finit_module not implemented [-Wcpp]
  <stdin>:1229:2: warning: #warning syscall sched_setattr not implemented [-Wcpp]
  <stdin>:1232:2: warning: #warning syscall sched_getattr not implemented [-Wcpp]
  <stdin>:1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp]
  <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp]
  <stdin>:1241:2: warning: #warning syscall getrandom not implemented [-Wcpp]
  <stdin>:1244:2: warning: #warning syscall memfd_create not implemented [-Wcpp]
  <stdin>:1247:2: warning: #warning syscall bpf not implemented [-Wcpp]
  <stdin>:1250:2: warning: #warning syscall execveat not implemented [-Wcpp]
  [...]
    HOSTCC  samples/kdbus/kdbus-workers
  samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
  samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
    p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                    ^
  samples/kdbus/kdbus-workers.c:930:18: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
      4f650a59
  11. 23 4月, 2015 23 次提交
  13. 22 4月, 2015 3 次提交
    • A
      KVM: arm/arm64: check IRQ number on userland injection · fd1d0ddf
      由 Andre Przywara 提交于 
      When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently
only check it against a fixed limit, which historically is set
to 127. With the new dynamic IRQ allocation the effective limit may
actually be smaller (64).
So when now a malicious or buggy userland injects a SPI in that
range, we spill over on our VGIC bitmaps and bytemaps memory.
I could trigger a host kernel NULL pointer dereference with current
mainline by injecting some bogus IRQ number from a hacked kvmtool:
-----------------
....
DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1)
DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1)
DEBUG: IRQ #114 still in the game, writing to bytemap now...
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc07652e000
[00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027
Hardware name: FVP Base (DT)
task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000
PC is at kvm_vgic_inject_irq+0x234/0x310
LR is at kvm_vgic_inject_irq+0x30c/0x310
pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145
.....

So this patch fixes this by checking the SPI number against the
actual limit. Also we remove the former legacy hard limit of
127 in the ioctl code.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18
[maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__,
as suggested by Christopher Covington]
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      fd1d0ddf
    • M
      ARM: qcom: add description of KPSS WDT for IPQ8064 · 4ba1c98b
      由 Mathieu Olivari 提交于 
      Add the watchdog related entries to the Krait Processor Sub-system
(KPSS) timer IPQ8064 devicetree section. Also, add a fixed-clock
description of SLEEP_CLK, which will do for now.
Signed-off-by: NJosh Cartwright <joshc@codeaurora.org>
Signed-off-by: NMathieu Olivari <mathieu@codeaurora.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      4ba1c98b
    • B
      ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows · 9fbbda5c
      由 Bjorn Helgaas 提交于 
      Prior to c770cb4c ("PCI: Mark invalid BARs as unassigned"), if we tried
to claim a PCI BAR but could not find an upstream bridge window that
matched it, we complained but still allowed the device to be enabled.

c770cb4c broke devices that previously worked (mptsas and igb in the
case Tony reported, but it could be any devices) because it marks those
BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and
return failure:

  igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned
  igb: probe of 0000:81:00.0 failed with error -22

The underlying cause is an ACPI Address Space Descriptor for a PCI host
bridge window that is marked as "consumer".  This is a firmware defect:
resources that are produced on the downstream side of a bridge should be
marked "producer".  But rejecting these BARs that we previously allowed is
a functionality regression, and firmware has not used the producer/consumer
bit consistently, so we can't rely on it anyway.

Stop checking the producer/consumer bit, and assume all bridge Address
Space Descriptors are for bridge windows.

Note that this change does not affect I/O Port or Fixed Location I/O Port
Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config
access range.  That range is a "consumer" range and should not be treated
as a window.

Fixes: c770cb4c ("PCI: Mark invalid BARs as unassigned")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96961Reported-and-tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9fbbda5c