1. 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
  2. 16 7月, 2008 1 次提交
  3. 14 7月, 2008 13 次提交
  4. 03 7月, 2008 1 次提交
  5. 26 6月, 2008 2 次提交
  6. 10 6月, 2008 1 次提交
  7. 30 5月, 2008 2 次提交
  8. 25 5月, 2008 1 次提交
  9. 17 5月, 2008 1 次提交
  10. 15 5月, 2008 3 次提交
  11. 07 5月, 2008 3 次提交
  12. 04 5月, 2008 1 次提交
    • U
      unified (weak) sys_pipe implementation · d35c7b0e
      Ulrich Drepper 提交于
      This replaces the duplicated arch-specific versions of "sys_pipe()" with
      one unified implementation.  This removes almost 250 lines of duplicated
      code.
      
      It's marked __weak, so that *if* an architecture wants to override the
      default implementation it can do so by simply having its own replacement
      version, since many architectures use alternate calling conventions for
      the 'pipe()' system call for legacy reasons (ie traditional UNIX
      implementations often return the two file descriptors in registers)
      
      I still haven't changed the cris version even though Linus says the BKL
      isn't needed.  The arch maintainer can easily do it if there are really
      no obstacles.
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d35c7b0e
  13. 30 4月, 2008 10 次提交
    • R
      signals: s390: renumber TIF_RESTORE_SIGMASK · 02a029b3
      Roland McGrath 提交于
      TIF_RESTORE_SIGMASK no longer needs to be in the _TIF_WORK_* masks.  Those low
      bits are scarce, and are all used up now.  Renumber TIF_RESTORE_SIGMASK to
      free one up.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      02a029b3
    • M
      [S390] use generic sys_ptrace · 941af343
      Martin Schwidefsky 提交于
      After the PT_IEEE_IP hack has been removed s390 can now use
      the common code sys_ptrace function.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      941af343
    • M
      [S390] Remove self ptrace IEEE_IP hack. · 613e1def
      Martin Schwidefsky 提交于
      The self referential PT_IEEE_IP ptrace peek & poke calls have been
      broken for that last 6 years. For peek the code always returns 0
      instead of the last ieee fault and for poke the code does nothing.
      Since nobody noticed the code seems to be superfluous. So lets
      remove it.
      
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      613e1def
    • G
      [S390] System z large page support. · 53492b1d
      Gerald Schaefer 提交于
      This adds hugetlbfs support on System z, using both hardware large page
      support if available and software large page emulation on older hardware.
      Shared (large) page tables are implemented in software emulation mode,
      by using page->index of the first tail page from a compound large page
      to store page table information.
      Signed-off-by: NGerald Schaefer <geraldsc@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      53492b1d
    • H
      [S390] Convert machine feature detection code to C. · 2e5061e4
      Heiko Carstens 提交于
      From: Heiko Carstens <heiko.carstens@de.ibm.com>
      From: Carsten Otte <cotte@de.ibm.com>
      
      This lets us use defines for the magic bits in machine flags instead
      of using plain numbers all over the place.
      In addition on newer machines features/facilities are indicated by the
      result of the stfl instruction. So we use these bits instead of trying
      to execute new instructions and check wether we get an exception or
      not.
      Also the mvpg instruction is always available when in zArch mode,
      whereas the idte instruction is only available in zArch mode. This
      results in some minor optimizations.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2e5061e4
    • H
    • H
      [S390] cpu topology: Fix possible deadlock. · fd781fa2
      Heiko Carstens 提交于
      When we get a notification that cpu topology changed, we schedule a
      work struct which just calls arch_reinit_sched_domains. This function
      in turn calls get_online_cpus() which results int the lockdep warning
      below.
      
      After all it turnded out that it's not legal to call get_online_cpus()
      from the context of a multi-threaded work queue.
      It could deadlock this way:
      
      process 0 (events/cpu-x):
      -> run_workqueue
      -> removes my work_struct from the work queue
      -> calls work_struct->fn
      -> get_online_cpus()
      -> locks on cpu_hotplug.lock since process 1 below is doing cpu hotplug
      
      process 1:
      -> cpu_down (for cpu-x)
      -> cpu_hotplug_begin (holds cpu_hotplug.lock now)
      -> cpu-x dead
      -> notifier_call_chain with CPU_DEAD
      -> cleanup_workqueue_thread
      -> flush_cpu_workqueue (succeeds)
      -> kthread_stop for events/cpu-x
        -> now kthread_stop waits for my work_struct to complete from within
           process 0. -> dead.
      
      A single threaded workqueue wouldn't have such problems, however there is
      no such common queue available and it's not worth to create one for the
      very rare calls to arch_reinit_sched_domains.
      
      So we just create a kernel thread from our work struct which calls
      arch_reinit_sched_domains and are done with it.
      
      Thanks to Oleg Nesterov and Peter Zijlstra for helping me figuring out
      that this isn't a false positive lockdep warning:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.25-03562-g3dc50637-dirty #12
      -------------------------------------------------------
      events/3/14 is trying to acquire lock:
       (&cpu_hotplug.lock){--..}, at: [<0000000000076094>] get_online_cpus+0x50/0x78
      
      but task is already holding lock:
       (topology_work){--..}, at: [<0000000000059cde>] run_workqueue+0x106/0x278
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (topology_work){--..}:
             [<000000000006fc74>] __lock_acquire+0x1010/0x111c
             [<000000000006fe40>] lock_acquire+0xc0/0xf8
             [<0000000000059d48>] run_workqueue+0x170/0x278
             [<0000000000059edc>] worker_thread+0x8c/0xf0
             [<000000000005f5bc>] kthread+0x68/0xa0
             [<000000000001a33e>] kernel_thread_starter+0x6/0xc
             [<000000000001a338>] kernel_thread_starter+0x0/0xc
      
      -> #1 (events){--..}:
             [<000000000006fc74>] __lock_acquire+0x1010/0x111c
             [<000000000006fe40>] lock_acquire+0xc0/0xf8
             [<000000000005a23c>] cleanup_workqueue_thread+0x60/0xa8
             [<00000000003b2ab8>] workqueue_cpu_callback+0xbc/0x170
             [<00000000003bba80>] notifier_call_chain+0x5c/0xa4
             [<00000000000655a2>] __raw_notifier_call_chain+0x26/0x38
             [<00000000000655e2>] raw_notifier_call_chain+0x2e/0x40
             [<0000000000075e00>] cpu_down+0x228/0x31c
             [<00000000003b1dd8>] store_online+0x64/0xb8
             [<00000000001e7128>] sysdev_store+0x48/0x58
             [<0000000000121cd2>] sysfs_write_file+0x126/0x1c0
             [<00000000000c1944>] vfs_write+0xb0/0x15c
             [<00000000000c20e6>] sys_write+0x56/0x88
             [<0000000000027a68>] sys32_write+0x34/0x4c
             [<0000000000023f70>] sysc_noemu+0x10/0x16
             [<0000000077f3f186>] 0x77f3f186
      
      -> #0 (&cpu_hotplug.lock){--..}:
             [<000000000006fa84>] __lock_acquire+0xe20/0x111c
             [<000000000006fe40>] lock_acquire+0xc0/0xf8
             [<00000000003b701c>] mutex_lock_nested+0xd0/0x364
             [<0000000000076094>] get_online_cpus+0x50/0x78
             [<000000000003a03e>] arch_reinit_sched_domains+0x26/0x58
             [<000000000002700e>] topology_work_fn+0x26/0x34
             [<0000000000059d4e>] run_workqueue+0x176/0x278
             [<0000000000059edc>] worker_thread+0x8c/0xf0
             [<000000000005f5bc>] kthread+0x68/0xa0
             [<000000000001a33e>] kernel_thread_starter+0x6/0xc
             [<000000000001a338>] kernel_thread_starter+0x0/0xc
      
      other info that might help us debug this:
      
      2 locks held by events/3/14:
       #0:  (events){--..}, at: [<0000000000059cde>] run_workqueue+0x106/0x278
       #1:  (topology_work){--..}, at: [<0000000000059cde>] run_workqueue+0x106/0x278
      
      stack backtrace:
      CPU: 3 Not tainted 2.6.25-03562-g3dc50637-dirty #12
      Process events/3 (pid: 14, task: 000000002fb04038, ksp: 000000002fb0bd70)
      0400000000000000 000000002fb0ba40 0000000000000002 0000000000000000
             000000002fb0bae0 000000002fb0ba58 000000002fb0ba58 0000000000016488
             0000000000000000 000000002fb0bd70 0000000000000000 0000000000000000
             000000002fb0ba40 000000000000000c 000000002fb0ba40 000000002fb0bab0
             00000000003c99e0 0000000000016488 000000002fb0ba40 000000002fb0ba90
      Call Trace:
      ([<00000000000163fc>] show_trace+0x138/0x158)
       [<00000000000164e2>] show_stack+0xc6/0xf8
       [<0000000000016624>] dump_stack+0xb0/0xc0
       [<000000000006cd36>] print_circular_bug_tail+0xa2/0xb4
       [<000000000006fa84>] __lock_acquire+0xe20/0x111c
       [<000000000006fe40>] lock_acquire+0xc0/0xf8
       [<00000000003b701c>] mutex_lock_nested+0xd0/0x364
       [<0000000000076094>] get_online_cpus+0x50/0x78
       [<000000000003a03e>] arch_reinit_sched_domains+0x26/0x58
       [<000000000002700e>] topology_work_fn+0x26/0x34
       [<0000000000059d4e>] run_workqueue+0x176/0x278
       [<0000000000059edc>] worker_thread+0x8c/0xf0
       [<000000000005f5bc>] kthread+0x68/0xa0
       [<000000000001a33e>] kernel_thread_starter+0x6/0xc
       [<000000000001a338>] kernel_thread_starter+0x0/0xc
      INFO: lockdep is turned off.
      
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      fd781fa2
    • H
      [S390] Add topology_core_siblings to topology.h · d00aa4e7
      Heiko Carstens 提交于
      This exposes the core siblings to user space via sysfs.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      d00aa4e7
    • M
      [S390] remove -traditional · 47494f6a
      Mathieu Desnoyers 提交于
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      47494f6a
    • H
      1e489518