Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 15 8月, 2009 1 次提交
    • M
      ARM: 5677/1: ARM support for TIF_RESTORE_SIGMASK/pselect6/ppoll/epoll_pwait · 36984265
      由 Mikael Pettersson 提交于 
      This patch adds support for TIF_RESTORE_SIGMASK to ARM's
signal handling, which allows to hook up the pselect6, ppoll,
and epoll_pwait syscalls on ARM.

Tested here with eabi userspace and a test program with a
deliberate race between a child's exit and the parent's
sigprocmask/select sequence. Using sys_pselect6() instead
of sigprocmask/select reliably prevents the race.

The other arch's support for TIF_RESTORE_SIGMASK has evolved
over time:

In 2.6.16:
- add TIF_RESTORE_SIGMASK which parallels TIF_SIGPENDING
- test both when checking for pending signal [changed later]
- reimplement sys_sigsuspend() to use current->saved_sigmask,
  TIF_RESTORE_SIGMASK [changed later], and -ERESTARTNOHAND;
  ditto for sys_rt_sigsuspend(), but drop private code and
  use common code via __ARCH_WANT_SYS_RT_SIGSUSPEND;
- there are now no "extra" calls to do_signal() so its oldset
  parameter is always &current->blocked so need not be passed,
  also its return value is changed to void
- change handle_signal() to return 0/-errno
- change do_signal() to honor TIF_RESTORE_SIGMASK:
  + get oldset from current->saved_sigmask if TIF_RESTORE_SIGMASK
    is set
  + if handle_signal() was successful then clear TIF_RESTORE_SIGMASK
  + if no signal was delivered and TIF_RESTORE_SIGMASK is set then
    clear it and restore the sigmask
- hook up sys_pselect6() and sys_ppoll()

In 2.6.19:
- hook up sys_epoll_pwait()

In 2.6.26:
- allow archs to override how TIF_RESTORE_SIGMASK is implemented;
  default set_restore_sigmask() sets both TIF_RESTORE_SIGMASK and
  TIF_SIGPENDING; archs need now just test TIF_SIGPENDING again
  when checking for pending signal work; some archs now implement
  TIF_RESTORE_SIGMASK as a secondary/non-atomic thread flag bit
- call set_restore_sigmask() in sys_sigsuspend() instead of setting
  TIF_RESTORE_SIGMASK

In 2.6.29-rc:
- kill sys_pselect7() which no arch wanted

So for 2.6.31-rc6/ARM this patch does the following:
- Add TIF_RESTORE_SIGMASK. Use the generic set_restore_sigmask()
  which sets both TIF_SIGPENDING and TIF_RESTORE_SIGMASK, so
  TIF_RESTORE_SIGMASK need not claim one of the scarce low thread
  flags, and existing TIF_SIGPENDING and _TIF_WORK_MASK tests need
  not be extended for TIF_RESTORE_SIGMASK.
- sys_sigsuspend() is reimplemented to use current->saved_sigmask
  and set_restore_sigmask(), making it identical to most other archs
- The private code for sys_rt_sigsuspend() is removed, instead
  generic code supplies it via __ARCH_WANT_SYS_RT_SIGSUSPEND.
- sys_sigsuspend() and sys_rt_sigsuspend() no longer need a pt_regs
  parameter, so their assembly code wrappers are removed.
- handle_signal() is changed to return 0 on success or -errno.
- The oldset parameter to do_signal() is now redundant and removed,
  and the return value is now also redundant and changed to void.
- do_signal() is changed to honor TIF_RESTORE_SIGMASK:
  + get oldset from current->saved_sigmask if TIF_RESTORE_SIGMASK
    is set
  + if handle_signal() was successful then clear TIF_RESTORE_SIGMASK
  + if no signal was delivered and TIF_RESTORE_SIGMASK is set then
    clear it and restore the sigmask
- Hook up sys_pselect6, sys_ppoll, and sys_epoll_pwait.
Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      36984265
  3. 22 7月, 2009 1 次提交
    • U
      [ARM] 5613/1: implement CALLER_ADDRESSx · 4bf1fa5a
      由 Uwe Kleine-König 提交于 
      From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

As __builtin_return_address(n) doesn't work for ARM with n > 0, the
kernel needs its own implementation.

This fixes many warnings saying:

	warning: unsupported argument to '__builtin_return_address'

The new methods and walk_stackframe must not be instrumented because
CALLER_ADDRESSx is used in the various tracers and tracing the tracer is
a bad idea.

What's currently missing is an implementation using unwind tables.  This
is not fatal though, it's just that the tracers don't get enough
information to be really useful.

Note that if both ARM_UNWIND and FRAME_POINTER are enabled,
walk_stackframe uses unwind information.  So in this case the same
implementation is used as when FRAME_POINTER is disabled.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4bf1fa5a
  5. 11 7月, 2009 5 次提交
  7. 10 7月, 2009 2 次提交
  9. 09 7月, 2009 2 次提交
  11. 08 7月, 2009 12 次提交
  13. 07 7月, 2009 9 次提交
    • M
      [S390] define KTIME_SCALAR for 32-bit s390 · 07606309
      由 Martin Schwidefsky 提交于 
      32-bit s390 has efficient support for 64/32-bit conversions, define
KTIME_SCALAR to enable the use of the plain scalar nanosecond based
representation of ktime.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      07606309
    • H
      [S390] add generic atomic64 support for 31 bit · 25ca1251
      由 Heiko Carstens 提交于 
      Performance counters need 64 bit atomic operations.
To keep the patch small we use the simple generic atomic64_t implementation.
The native implementation follows with the next kernel.

Fixes this build bug:

In file included from kernel/sched.c:42:
include/linux/perf_counter.h:427: error: expected specifier-qualifier-list before 'atomic64_t'
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      25ca1251
    • M
      [S390] set SCHED_OMIT_FRAME_POINTER for s390 · fca3e357
      由 Martin Schwidefsky 提交于 
      The frame pointer is useless for s390 in the sched.c code.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      fca3e357
    • H
      [S390] add __ucmpdi2() helper function · 5075baca
      由 Heiko Carstens 提交于 
      Provide __ucmpdi2() helper function on 31 bit so we don't run
again and again in compile errors like this one:

kernel/built-in.o: In function `T.689':
perf_counter.c:(.text+0x56c86): undefined reference to `__ucmpdi2'
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      5075baca
    • H
      [S390] perf_counter build fix · 2651fa2b
      由 Heiko Carstens 提交于 
      Add PERF_COUNTER_INDEX_OFFSET define to fix this build bug:

kernel/perf_counter.c: In function 'perf_counter_index':
kernel/perf_counter.c:1889: error: 'PERF_COUNTER_INDEX_OFFSET' undeclared

Same fix as for FRV since s390 doesn't support hw counters.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2651fa2b
    • F
      [S390] shutdown actions: save/return rc from init function · 81088819
      由 Frank Munzert 提交于 
      We always returned -EINVAL when setting of a shutdown action failed. This was
misleading, if for example the hardware did not support the shutdown action.
Now we save each shutdown action's init return code and return it when the
action is being set.
Signed-off-by: NFrank Munzert <munzert@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      81088819
    • H
      [S390] udelay: disable lockdep to avoid false positives · bb8c29ca
      由 Heiko Carstens 提交于 
      Our udelay implementation enables interrupts to receive a special timer
interrupt regardless of the context it is called from.
This might lead to false positive lockdep reports. Since lockdep isn't
aware of the fact that only a single interrupt source is enabled it
warns about possible deadlocks that in reality won't happen, like
the one below.
To fix this disable lockdep before enabling interrupts.

[ 254.040888] =================================
[ 254.040904] [ INFO: inconsistent lock state ]
[ 254.040910] 2.6.30 #9
[ 254.040914] ---------------------------------
[ 254.040920] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 254.040927] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 254.040934] (sch->lock){?.-...}, at: [<00000000002e4778>] ccw_device_timeout+0x48/0x2f0
[ 254.040961] {IN-HARDIRQ-W} state was registered at:
[ 254.040969] [<0000000000096f74>] __lock_acquire+0x9d4/0x188c
[ 254.040985] [<0000000000097f68>] lock_acquire+0x13c/0x16c
[ 254.040998] [<00000000004527e0>] _spin_lock+0x74/0xb8
[ 254.041016] [<0000000000457eb2>] do_IRQ+0xde/0x208
[ 254.041031] [<000000000002d190>] io_return+0x0/0x8
[ 254.041049] [<0000000000029faa>] vtime_stop_cpu+0xbe/0x114
[ 254.041066] irq event stamp: 259629
[ 254.041076] hardirqs last enabled at (259628): [<000000000045238e>] _spin_unlock_irq+0x5e/0x9c
[ 254.041095] hardirqs last disabled at (259629): [<000000000045292e>] _spin_lock_irq+0x4a/0xc4
[ 254.041126] softirqs last enabled at (259614): [<000000000006500e>] __do_softirq+0x296/0x2b0
[ 254.041137] softirqs last disabled at (259619): [<0000000000024cf6>] do_softirq+0x102/0x108
[ 254.041147]
[ 254.041148] other info that might help us debug this:
[ 254.041153] 2 locks held by swapper/0:
[ 254.041157] #0: (&priv->timer){+.-...}, at: [<000000000006bf9a>] run_timer_softirq+0x19a/0x340
[ 254.041170] #1: (sch->lock){?.-...}, at: [<00000000002e4778>] ccw_device_timeout+0x48/0x2f0
[ 254.041182]
[ 254.041310] Call Trace:
[ 254.041313] ([<00000000000174fc>] show_trace+0x16c/0x170)
[ 254.041321] [<0000000000017578>] show_stack+0x78/0x104
[ 254.041327] [<000000000044d0ca>] dump_stack+0xc6/0xd4
[ 254.041342] [<00000000000949b4>] print_usage_bug+0x1c8/0x1fc
[ 254.041353] [<0000000000094e8a>] mark_lock+0x4a2/0x670
[ 254.041364] [<00000000000950e2>] mark_held_locks+0x8a/0xb4
[ 254.041375] [<0000000000095398>] trace_hardirqs_on_caller+0x74/0x1ac
[ 254.041388] [<00000000000954fa>] trace_hardirqs_on+0x2a/0x38
[ 254.041402] [<000000000025f1ec>] __udelay_disabled+0xac/0xfc
[ 254.041419] [<000000000025f432>] __udelay+0x12a/0x148
[ 254.041433] [<00000000002d64d8>] cio_commit_config+0x170/0x290
[ 254.041451] [<00000000002d6978>] cio_disable_subchannel+0x120/0x1cc
[ 254.041468] [<00000000002e32a4>] ccw_device_recog_done+0x54/0x2f4
[ 254.041485] [<00000000002e3638>] ccw_device_sense_id_done+0x50/0x90
[ 254.041508] [<00000000002e615a>] snsid_callback+0xfa/0x3a8
[ 254.041515] [<00000000002dd96c>] ccwreq_stop+0x80/0x90
[ 254.041523] [<00000000002dda8e>] ccw_request_timeout+0xc2/0xd0
[ 254.041530] [<00000000002e2f70>] ccw_device_request_event+0x58/0x90
[ 254.041537] [<00000000002e47ae>] ccw_device_timeout+0x7e/0x2f0
[ 254.041555] [<000000000006c02a>] run_timer_softirq+0x22a/0x340
[ 254.041566] [<0000000000064eb0>] __do_softirq+0x138/0x2b0
[ 254.041578] [<0000000000024cf6>] do_softirq+0x102/0x108
[ 254.041590] [<00000000000647ce>] irq_exit+0xee/0x114
[ 254.041603] [<0000000000457d88>] do_extint+0x130/0x17c
[ 254.041617] [<000000000002d41e>] ext_no_vtime+0x1e/0x22
[ 254.041631] [<0000000000029faa>] vtime_stop_cpu+0xbe/0x114
[ 254.041646] ([<0000000000029f58>] vtime_stop_cpu+0x6c/0x114)
[ 254.041662] [<000000000001d842>] cpu_idle+0x122/0x1c0
[ 254.041679] [<00000000004482c6>] start_secondary+0xce/0xe0
[ 254.041696] [<0000000000000000>] 0x0
[ 254.041715] [<0000000000000000>] 0x0
[ 254.041745] INFO: lockdep is turned off.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      bb8c29ca
    • M
      [CPUFREQ] Powernow-k8: support family 0xf with 2 low p-states · a2e1b4c3
      由 Mark Langsdorf 提交于 
      Provide support for family 0xf processors with 2 P-states
below the elevator voltage.  Remove the checks that prevent
this configuration from being supported and increase the
transition voltage to prevent errors during the transition.
Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: NDave Jones <davej@redhat.com>
      a2e1b4c3
    • P
      gcov: exclude code operating in userspace from profiling · f386c61f
      由 Peter Oberparleiter 提交于 
      Fix for this issue on x86_64:

rostedt@goodmis.org wrote:
> On bootup of the latest kernel my init segfaults. Debugging it,
> I found  that vread_tsc (a vsyscall) increments some strange
> kernel memory:
>
> 0000000000000000 <vread_tsc>:
>    0:   55                      push   %rbp
>    1:   48 ff 05 00 00 00 00    incq   0(%rip)
>                         # 8 <vread_tsc+0x8>
>                         4: R_X86_64_PC32        .bss+0x3c
>    8:   48 89 e5                mov    %rsp,%rbp
>    b:   66 66 90                xchg   %ax,%ax
>    e:   48 ff 05 00 00 00 00    incq   0(%rip)
>                         # 15 <vread_tsc+0x15>
>                         11: R_X86_64_PC32       .bss+0x44
>   15:   66 66 90                xchg   %ax,%ax
>   18:   48 ff 05 00 00 00 00    incq   0(%rip)
>                         # 1f <vread_tsc+0x1f>
>                         1b: R_X86_64_PC32       .bss+0x4c
>   1f:   0f 31                   rdtsc
>
>
> Those "incq" is very bad to happen in vsyscall memory, since
> userspace can not modify it. You need to make something prevent
> profiling of vsyscall  memory (like I do with ftrace).
Signed-off-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Reported-by: NSteven Rostedt <rostedt@goodmis.org>
Tested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f386c61f
  15. 06 7月, 2009 7 次提交
  17. 05 7月, 2009 1 次提交