Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 7月, 2009 5 次提交
    • F
      [S390] zcrypt: fix scheduling of hrtimer ap_poll_timer · 8d406c6d
      由 Felix Beck 提交于 
      Every time a request is enqueued or there is some work outstanding
from the ap_tasklet, the ap_poll_timer is scheduled again.
Unfortunately it was permanently called. It looked as if it was
started in the past and thus imediately expired.
This has been changed. First it is checked if the hrtimer is already
expired. Then the expiring time is forwarded and the timer restarted.
Signed-off-by: NFelix Beck <felix.beck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8d406c6d
    • M
      [S390] vdso: clock_gettime of CLOCK_THREAD_CPUTIME_ID with noexec=on · 1277580f
      由 Martin Schwidefsky 提交于 
      The combination of noexec=on and a clock_gettime call with clock id
CLOCK_THREAD_CPUTIME_ID is broken. The vdso code switches to the
access register mode to get access to the per-cpu data structure to
execute the magic ectg instruction. After the ectg instruction the
code always switches back to the primary mode but for noexec=on the
correct mode is the secondary mode. The effect of the bug is that the
user space program looses the access to all mappings without PROT_EXEC,
e.g. the stack. The problem is fixed by restoring the mode that has
been active before the switch to the access register mode.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1277580f
    • H
      [S390] vdso: fix per cpu area allocation · 3a6ba460
      由 Heiko Carstens 提交于 
      vdso per cpu area allocation in smp_prepare_cpus() happens with GFP_KERNEL
but irqs disabled. Triggers this one:

Badness at kernel/lockdep.c:2280
Modules linked in:
CPU: 0 Not tainted 2.6.30 #2
Process swapper (pid: 1, task: 000000003fe88000, ksp: 000000003fe87eb8)
Krnl PSW : 0400c00180000000 0000000000083360 (lockdep_trace_alloc+0xec/0xf8)
[...]
Call Trace:
([<00000000000832b6>] lockdep_trace_alloc+0x42/0xf8)
 [<00000000000b1880>] __alloc_pages_internal+0x3e8/0x5c4
 [<00000000000b1b4a>] __get_free_pages+0x3a/0xb0
 [<0000000000026546>] vdso_alloc_per_cpu+0x6a/0x18c
 [<00000000005eff82>] smp_prepare_cpus+0x322/0x594
 [<00000000005e8232>] kernel_init+0x76/0x398
 [<000000000001bb1e>] kernel_thread_starter+0x6/0xc
 [<000000000001bb18>] kernel_thread_starter+0x0/0xc

Fix this by moving the allocation out of the irqs disabled section.
Reported-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3a6ba460
    • H
      [S390] hibernation: fix register corruption on machine checks · c63b196a
      由 Heiko Carstens 提交于 
      swsusp_arch_suspend() actually saves all cpu register contents on
hibernation.
Machine checks must be disabled since swsusp_arch_suspend() stores
register contents to their lowcore save areas. That's the same
place where register contents on machine checks would be saved.
To avoid register corruption disable machine checks.
We must also disable machine checks in the new psw mask for
program checks, since swsusp_arch_suspend() may generate program
checks.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c63b196a
    • H
      [S390] hibernation: fix lowcore handling · 5f954c34
      由 Heiko Carstens 提交于 
      Our swsusp_arch_suspend() backend implementation disables prefixing
by setting the contents of the prefix register to 0.
However afterwards common code functions are called which might
access percpu data structures.
Since the lowcore contains e.g. the percpu base pointer this isn't
a good idea. So fix this by copying the hibernating cpu's lowcore to
absolute address zero.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      5f954c34
  3. 23 7月, 2009 33 次提交
  5. 22 7月, 2009 2 次提交
    • L
      fbmon: work around compiler bug in gcc-2.4.2 · 3730793d
      由 Linus Torvalds 提交于 
      There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent
he loop counter is of type 'unsigned char' and it should count to 128.

The compiler will incorrectly decide that a trivial loop like this:

	unsigned char i, ...

	for (i = 0; i < 128; i++) {
		..

is endless, and will compile it to a single instruction that just
branches to itself.

This was triggered by the addition of '-fno-strict-overflow', and we
could play games with compiler versions and go back to '-fwrapv'
instead, but the trivial way to avoid it is to just make the loop
induction variable be an 'int' instead.

Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure
for digging through assembler differences and finding it.
Reported-and-tested-by: NKrzysztof Oledzki <olel@ans.pl>
Found-by: NTroy Moure <twmoure@szypr.net>
Gcc-bug-acked-by: NIan Lance Taylor <iant@google.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3730793d
    • P
      softirq: introduce tasklet_hrtimer infrastructure · 9ba5f005
      由 Peter Zijlstra 提交于 
      commit ca109491 (hrtimer: removing all ur callback modes) moved all
hrtimer callbacks into hard interrupt context when high resolution
timers are active. That breaks code which relied on the assumption
that the callback happens in softirq context.

Provide a generic infrastructure which combines tasklets and hrtimers
together to provide an in-softirq hrtimer experience.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: torvalds@linux-foundation.org
Cc: kaber@trash.net
Cc: David Miller <davem@davemloft.net>
LKML-Reference: <1248265724.27058.1366.camel@twins>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9ba5f005