Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 165
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 29 3月, 2012 1 次提交
  3. 27 7月, 2011 1 次提交
  5. 29 8月, 2009 1 次提交
  7. 09 7月, 2009 1 次提交
  9. 31 3月, 2009 2 次提交
  11. 06 1月, 2009 2 次提交
    • K
      parisc: export length of os_hpmc vector · ae16489e
      由 Kyle McMartin 提交于 
      and use this instead of dealing with exporting start/end and
toying with function descriptors.
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      ae16489e
    • K
      parisc: fix kernel crash (protection id trap) when compiling ruby1.9 · c61c25eb
      由 Kyle McMartin 提交于 
      On Wed, Dec 17, 2008 at 11:46:05PM +0100, Helge Deller wrote:
>

Honestly, I can't decide whether to apply this. It really should never
happen in the kernel, since the kernel can guarantee it won't get the
access rights failure (highest privilege level, and can set %sr and
%protid to whatever it wants.)

It really genuinely is a bug that probably should panic the kernel. The
only precedent I can easily see is x86 fixing up a bad iret with a
general protection fault, which is more or less analogous to code 27
here.

On the other hand, taking the exception on a userspace access really
isn't all that critical, and there's fundamentally little reason for the
kernel not to SIGSEGV the process, and continue...

Argh.

(btw, I've instrumented my do_sys_poll with a pile of assertions that
 %cr8 << 1 == %sr3 == current->mm.context... let's see if where we're
 getting corrupted is deterministic, though, I would guess that it won't
 be.)
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      c61c25eb
  13. 27 11月, 2008 1 次提交
    • H
      parisc: fix kernel crash when unwinding a userspace process · 7a3f5134
      由 Helge Deller 提交于 
      Any user on existing parisc 32- and 64bit-kernels can easily crash
the kernel and as such enforce a DSO.
A simple testcase is available here:
        http://gsyprf10.external.hp.com/~deller/crash.tgz

The problem is introduced by the fact, that the handle_interruption()
crash handler calls the show_regs() function, which in turn tries to
unwind the stack by calling parisc_show_stack().  Since the stack contains
userspace addresses, a try to unwind the stack is dangerous and useless
and leads to the crash.

The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.

While touching this code, I converted print_symbol() to %pS
printk formats and made parisc_show_stack() static.

An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2

Compile and run-tested with a 64bit parisc kernel.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: Grant Grundler <grundler@parisc-linux.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, earlier...]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      7a3f5134
  15. 15 5月, 2008 1 次提交
  17. 16 3月, 2008 2 次提交
  19. 20 10月, 2007 1 次提交
  21. 18 7月, 2007 1 次提交
  23. 17 7月, 2007 1 次提交
    • H
      generic bug: use show_regs() instead of dump_stack() · 608e2619
      由 Heiko Carstens 提交于 
      The current generic bug implementation has a call to dump_stack() in case a
WARN_ON(whatever) gets hit.  Since report_bug(), which calls dump_stack(),
gets called from an exception handler we can do better: just pass the
pt_regs structure to report_bug() and pass it to show_regs() in case of a
warning.  This will give more debug informations like register contents,
etc...  In addition this avoids some pointless lines that dump_stack()
emits, since it includes a stack backtrace of the exception handler which
is of no interest in case of a warning.  E.g.  on s390 the following lines
are currently always present in a stack backtrace if dump_stack() gets
called from report_bug():

 [<000000000001517a>] show_trace+0x92/0xe8)
 [<0000000000015270>] show_stack+0xa0/0xd0
 [<00000000000152ce>] dump_stack+0x2e/0x3c
 [<0000000000195450>] report_bug+0x98/0xf8
 [<0000000000016cc8>] illegal_op+0x1fc/0x21c
 [<00000000000227d6>] sysc_return+0x0/0x10
Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Kyle McMartin <kyle@parisc-linux.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      608e2619
  25. 04 6月, 2007 1 次提交
  27. 23 5月, 2007 1 次提交
  29. 09 5月, 2007 1 次提交
  31. 17 2月, 2007 7 次提交
  33. 04 10月, 2006 1 次提交
  35. 01 7月, 2006 1 次提交
  37. 28 6月, 2006 1 次提交
  39. 23 1月, 2006 1 次提交
  41. 22 10月, 2005 1 次提交
  43. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4