1. 10 2月, 2016 1 次提交
    • H
      s390/stacktrace: fix save_stack_trace_tsk() for current task · 665ca918
      Heiko Carstens 提交于
      The function save_stack_trace_tsk() did not consider that it can be
      used for tsk == current, for which the current stack pointer obviously
      cannot be found in the thread structure.
      
      Fix this and get the stack pointer with an inline assembly.
      
      This fixes e.g. the output of "cat /proc/self/stack".
      
      Before:
      [<0000000000000000>]           (null)
      [<ffffffffffffffff>] 0xffffffffffffffff
      
      After:
      [<000000000011b3ee>] save_stack_trace_tsk+0x56/0x98
      [<0000000000366cde>] proc_pid_stack+0xae/0x108
      [<00000000003636f0>] proc_single_show+0x70/0xc0
      [<0000000000311fbc>] seq_read+0xcc/0x448
      [<00000000002e7716>] __vfs_read+0x36/0x100
      [<00000000002e872e>] vfs_read+0x76/0x130
      [<00000000002e975e>] SyS_read+0x66/0xd8
      [<000000000089490e>] system_call+0xd6/0x264
      [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Tested-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      665ca918
  2. 19 1月, 2016 1 次提交
  3. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  4. 17 7月, 2008 1 次提交
    • H
      [S390] Fix stacktrace compile bug. · 8de2ce86
      Heiko Carstens 提交于
      Add missing module.h include to fix this:
      
        CC      arch/s390/kernel/stacktrace.o
      arch/s390/kernel/stacktrace.c:84: warning: data definition has no type or storage class
      arch/s390/kernel/stacktrace.c:84: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/s390/kernel/stacktrace.c:84: warning: parameter names (without types) in function declaration
      arch/s390/kernel/stacktrace.c:97: warning: data definition has no type or storage class
      arch/s390/kernel/stacktrace.c:97: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/s390/kernel/stacktrace.c:97: warning: parameter names (without types) in function declaration
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      8de2ce86
  5. 03 7月, 2008 1 次提交
  6. 05 2月, 2008 1 次提交
  7. 17 7月, 2007 1 次提交
  8. 09 5月, 2007 1 次提交
  9. 06 2月, 2007 1 次提交
  10. 11 10月, 2006 1 次提交
    • C
      [S390] stacktrace bug. · 75e9de18
      Christian Borntraeger 提交于
      The latest kernel 2.6.19-rc1 triggers a bug in the s390 specific stack
      trace code when compiled with gcc 3.4.
      This patch fixes the latest lock dependency validator code (2.6.19-rc1)
      on s390 gcc 3.4. The variable sp was fixed to r15 (which is the stack
      pointer in the s390 abi) and assigned new values to r15. Therefore,
      gcc 3.4 assigns a new value to r15 and does not restore it on exit (r15
      is supposed to be call save) - the kernel stack is broken. Avoid trouble
      by not assigning any new value to sp (r15).
      Signed-off-by: NChristian Borntraeger <cborntra@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      75e9de18
  11. 26 9月, 2006 1 次提交
  12. 04 7月, 2006 1 次提交