Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 4月, 2008 1 次提交
    • R
      x86: ptrace vs -ENOSYS · a31f8dd7
      由 Roland McGrath 提交于 
      When we're stopped at syscall entry tracing, ptrace can change the %rax
value from -ENOSYS to something else.  If no system call is actually made
because the syscall number (now in orig_rax) is bad, then we now always
reset %rax to -ENOSYS again.

This changes it to leave the return value alone after entry tracing.
That way, the %rax value set by ptrace is there to be seen in user mode
(or in syscall exit tracing).  This is consistent with what the 32-bit
kernel does.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a31f8dd7
  3. 26 2月, 2008 1 次提交
    • I
      x86: fix execve with -fstack-protect · 5d119b2c
      由 Ingo Molnar 提交于 
      pointed out by pageexec@freemail.hu:

> what happens here is that gcc treats the argument area as owned by the
> callee, not the caller and is allowed to do certain tricks. for ssp it
> will make a copy of the struct passed by value into the local variable
> area and pass *its* address down, and it won't copy it back into the
> original instance stored in the argument area.
>
> so once sys_execve returns, the pt_regs passed by value hasn't at all
> changed and its default content will cause a nice double fault (FWIW,
> this part took me the longest to debug, being down with cold didn't
> help it either ;).

To fix this we pass in pt_regs by pointer.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5d119b2c
  5. 19 2月, 2008 1 次提交
  7. 10 2月, 2008 1 次提交
  9. 07 2月, 2008 2 次提交
  11. 30 1月, 2008 1 次提交
  13. 26 1月, 2008 1 次提交
    • P
      sched: high-res preemption tick · 8f4d37ec
      由 Peter Zijlstra 提交于 
      Use HR-timers (when available) to deliver an accurate preemption tick.

The regular scheduler tick that runs at 1/HZ can be too coarse when nice
level are used. The fairness system will still keep the cpu utilisation 'fair'
by then delaying the task that got an excessive amount of CPU time but try to
minimize this by delivering preemption points spot-on.

The average frequency of this extra interrupt is sched_latency / nr_latency.
Which need not be higher than 1/HZ, its just that the distribution within the
sched_latency period is important.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8f4d37ec
  15. 18 10月, 2007 1 次提交
  17. 12 10月, 2007 1 次提交
  19. 11 10月, 2007 2 次提交
  21. 01 8月, 2007 1 次提交
  23. 22 7月, 2007 1 次提交
    • T
      x86_64: support poll() on /dev/mcelog · e02e68d3
      由 Tim Hockin 提交于 
      Background:
 /dev/mcelog is typically polled manually.  This is less than optimal for
 situations where accurate accounting of MCEs is important.  Calling
 poll() on /dev/mcelog does not work.

Description:
 This patch adds support for poll() to /dev/mcelog.  This results in
 immediate wakeup of user apps whenever the poller finds MCEs.  Because
 the exception handler can not take any locks, it can not call the wakeup
 itself.  Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
 caught at the next return from interrupt or exit from idle, calling the
 mce_user_notify() routine.  This patch also disables the "fake panic"
 path of the mce_panic(), because it results in printk()s in the exception
 handler and crashy systems.

 This patch also does some small cleanup for essentially unused variables,
 and moves the user notification into the body of the poller, so it is
 only called once per poll, rather than once per CPU.

Result:
 Applications can now poll() on /dev/mcelog.  When an error is logged
 (whether through the poller or through an exception) the applications are
 woken up promptly.  This should not affect any previous behaviors.  If no
 MCEs are being logged, there is no overhead.

Alternatives:
 I considered simply supporting poll() through the poller and not using
 TIF_MCE_NOTIFY at all.  However, the time between an uncorrectable error
 happening and the user application being notified is *the*most* critical
 window for us.  Many uncorrectable errors can be logged to the network if
 given a chance.

 I also considered doing the MCE poll directly from the idle notifier, but
 decided that was overkill.

Testing:
 I used an error-injecting DIMM to create lots of correctable DRAM errors
 and verified that my user app is woken up in sync with the polling interval.
 I also used the northbridge to inject uncorrectable ECC errors, and
 verified (printk() to the rescue) that the notify routine is called and the
 user app does wake up.  I built with PREEMPT on and off, and verified
 that my machine survives MCEs.

[wli@holomorphy.com: build fix]
Signed-off-by: NTim Hockin <thockin@google.com>
Signed-off-by: NWilliam Irwin <bill.irwin@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e02e68d3
  25. 23 6月, 2007 1 次提交
  27. 03 5月, 2007 1 次提交
  29. 27 2月, 2007 1 次提交
    • E
      [PATCH] x86_64 irq: Safely cleanup an irq after moving it. · 61014292
      由 Eric W. Biederman 提交于 
      The problem:  After moving an interrupt when is it safe to teardown
the data structures for receiving the interrupt at the old location?

With a normal pci device it is possible to issue a read to a device
to flush all posted writes.  This does not work for the oldest ioapics
because they are on a 3-wire apic bus which is a completely different
data path.  For some more modern ioapics when everything is using
front side bus delivery you can flush interrupts by simply issuing a
read to the ioapic.  For other modern ioapics emperical testing has
shown that this does not work.

So it appears the only reliable way to know the last of the irqs from an
ioapic have been received from before the ioapic was reprogrammed is to
received the first irq from the ioapic from after it was reprogrammed.

Once we know the last irq message has been received from an ioapic
into a local apic we then need to know that irq message has been
processed through the local apics.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      61014292
  31. 16 12月, 2006 1 次提交
    • L
      Remove stack unwinder for now · d1526e2c
      由 Linus Torvalds 提交于 
      It has caused more problems than it ever really solved, and is
apparently not getting cleaned up and fixed.  We can put it back when
it's stable and isn't likely to make warning or bug events worse.

In the meantime, enable frame pointers for more readable stack traces.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1526e2c
  33. 07 12月, 2006 1 次提交
    • J
      [PATCH] x86-64: miscellaneous entry.S adjustments · bcddc015
      由 Jan Beulich 提交于 
      This patch:
- makes ret_from_sys_call no longer global (all external users were
  previously switched to use int_ret_from_sys_call)
- adjusts placement of a CFI_{REMEMBER,RESTORE}_STATE pair to better
  fit logic flow
- eliminates an unnecessary pair of CFI_{REMEMBER,RESTORE}_STATE
- glues together function- and unwinder-wise the previously separate
  system_call and int_ret_from_sys_call function fragments
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      bcddc015
  35. 22 10月, 2006 3 次提交
  37. 06 10月, 2006 2 次提交
  39. 02 10月, 2006 1 次提交
    • A
      [PATCH] rename the provided execve functions to kernel_execve · 3db03b4a
      由 Arnd Bergmann 提交于 
      Some architectures provide an execve function that does not set errno, but
instead returns the result code directly.  Rename these to kernel_execve to
get the right semantics there.  Moreover, there is no reasone for any of these
architectures to still provide __KERNEL_SYSCALLS__ or _syscallN macros, so
remove these right away.

[akpm@osdl.org: build fix]
[bunk@stusta.de: build fix]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Andi Kleen <ak@muc.de>
Acked-by: NPaul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Hirokazu Takata <takata.hirokazu@renesas.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
Cc: Richard Curnow <rc@rc0.org.uk>
Cc: William Lee Irwin III <wli@holomorphy.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
Cc: Chris Zankel <chris@zankel.net>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3db03b4a
  41. 26 9月, 2006 10 次提交
    • A
      [PATCH] Don't leak NT bit into next task · 658fdbef
      由 Andi Kleen 提交于 
      SYSENTER can cause a NT to be set which might cause crashes on the IRET
in the next task.

Following similar i386 patch from Linus.
Signed-off-by: NAndi Kleen <ak@suse.de>
      658fdbef
    • J
      [PATCH] i386/x86-64: Work around gcc bug with noreturn functions in unwinder · adf14236
      由 Jan Beulich 提交于 
      Current gcc generates calls not jumps to noreturn functions. When that happens the
return address can point to the next function, which confuses the unwinder.

This patch works around it by marking asynchronous exception
frames in contrast normal call frames in the unwind information.  Then teach
the unwinder to decode this.

For normal call frames the unwinder now subtracts one from the address which avoids
this problem.  The standard libgcc unwinder uses the same trick.

It doesn't include adjustment of the printed address (i.e. for the original
example, it'd still be kernel_math_error+0 that gets displayed, but the
unwinder wouldn't get confused anymore.

This only works with binutils 2.6.17+ and some versions of H.J.Lu's 2.6.16
unfortunately because earlier binutils don't support .cfi_signal_frame

[AK: added automatic detection of the new binutils and wrote description]
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      adf14236
    • A
      [PATCH] Fix a irqcount comment in entry.S · 96e54049
      由 Andi Kleen 提交于 
      Signed-off-by: NAndi Kleen <ak@suse.de>
      96e54049
    • A
      [PATCH] Add a missing check for irq flags tracing in NMI · 7a0a2dff
      由 Andi Kleen 提交于 
      NMIs are not supposed to track the irq flags, but TRACE_IRQS_IRETQ
did it anyways. Add a check.

Cc: mingo@elte.hu
Signed-off-by: NAndi Kleen <ak@suse.de>
      7a0a2dff
    • P
      [PATCH] x86: error_code is not safe for kprobes · d28c4393
      由 Prasanna S.P 提交于 
      This patch moves the entry.S:error_entry to .kprobes.text section,
since code marked unsafe for kprobes jumps directly to entry.S::error_entry,
that must be marked unsafe as well.
This patch also moves all the ".previous.text" asm directives to ".previous"
for kprobes section.

AK: Following a similar i386 patch from Chuck Ebbert
AK: Also merged Jeremy's fix in.

+From: Jeremy Fitzhardinge <jeremy@goop.org>

KPROBE_ENTRY does a .section .kprobes.text, and expects its users to
do a .previous at the end of the function.

Unfortunately, if any code within the function switches sections, for
example .fixup, then the .previous ends up putting all subsequent code
into .fixup.  Worse, any subsequent .fixup code gets intermingled with
the code its supposed to be fixing (which is also in .fixup).  It's
surprising this didn't cause more havok.

The fix is to use .pushsection/.popsection, so this stuff nests
properly.  A further cleanup would be to get rid of all
.section/.previous pairs, since they're inherently fragile.

+From: Chuck Ebbert <76306.1226@compuserve.com>

Because code marked unsafe for kprobes jumps directly to
entry.S::error_code, that must be marked unsafe as well.
The easiest way to do that is to move the page fault entry
point to just before error_code and let it inherit the same
section.

Also moved all the ".previous" asm directives for kprobes
sections to column 1 and removed ".text" from them.
Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
      d28c4393
    • A
      [PATCH] Remove obsolete CVS $Id$ from assembler files in arch/x86_64/kernel/* · 44cc4526
      由 Andi Kleen 提交于 
      CVS hasn't been used for a long time for them.
Signed-off-by: NAndi Kleen <ak@suse.de>
      44cc4526
    • A
      [PATCH] Add some comments to entry.S · 2e91a17b
      由 Andi Kleen 提交于 
      And remove some old obsolete ones.
Signed-off-by: NAndi Kleen <ak@suse.de>
      2e91a17b
    • A
      [PATCH] Remove all ifdefs for local/io apic · 7f11d8a5
      由 Andi Kleen 提交于 
      IO-APIC or local APIC can only be disabled at runtime anyways and
Kconfig has forced these options on for a long time now.

The Kconfigs are kept only now for the benefit of the shared acpi
boot.c code.
Signed-off-by: NAndi Kleen <ak@suse.de>
      7f11d8a5
    • A
      [PATCH] Add proper alignment to ENTRY · b06babac
      由 Andi Kleen 提交于 
      Previously it didn't align. Use the same one as the C compiler
in blended mode, which is good for K8 and Core2 and doesn't hurt
on P4.
Signed-off-by: NAndi Kleen <ak@suse.de>
      b06babac
    • A
      [PATCH] Clean up asm/smp.h includes · 2f766d16
      由 Andi Kleen 提交于 
      No need to include it from entry.S
Drop all the #ifdef __ASSEMBLY__
Signed-off-by: NAndi Kleen <ak@suse.de>
      2f766d16
  43. 31 8月, 2006 1 次提交
  45. 03 8月, 2006 1 次提交
  47. 04 7月, 2006 1 次提交
  49. 01 7月, 2006 1 次提交
  51. 28 6月, 2006 1 次提交