1. 01 5月, 2008 1 次提交
  2. 28 4月, 2008 1 次提交
  3. 19 4月, 2008 1 次提交
  4. 08 2月, 2008 2 次提交
  5. 09 1月, 2008 1 次提交
  6. 20 10月, 2007 2 次提交
    • B
      Extended crashkernel command line · cba63c30
      Bernhard Walle 提交于
      This patch adds a extended crashkernel syntax that makes the value of reserved
      system RAM dependent on the system RAM itself:
      
          crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
          range=start-[end]
      
      For example:
      
          crashkernel=512M-2G:64M,2G-:128M
      
      The motivation comes from distributors that configure their crashkernel
      command line automatically with some configuration tool (YaST, you know ;)).
      Of course that tool knows the value of System RAM, but if the user removes
      RAM, then the system becomes unbootable or at least unusable and error
      handling is very difficult.
      
      This series implements this change for i386, x86_64, ia64, ppc64 and sh.  That
      should be all platforms that support kdump in current mainline.  I tested all
      platforms except sh due to the lack of a sh processor.
      
      This patch:
      
      This is the generic part of the patch.  It adds a parse_crashkernel() function
      in kernel/kexec.c that is called by the architecture specific code that
      actually reserves the memory.  That function takes the whole command line and
      looks itself for "crashkernel=" in it.
      
      If there are multiple occurrences, then the last one is taken.  The advantage
      is that if you have a bootloader like lilo or elilo which allows you to append
      a command line parameter but not to remove one (like in GRUB), then you can
      add another crashkernel value for testing at the boot command line and this
      one overwrites the command line in the configuration then.
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cba63c30
    • S
      pid namespaces: define is_global_init() and is_container_init() · b460cbc5
      Serge E. Hallyn 提交于
      is_init() is an ambiguous name for the pid==1 check.  Split it into
      is_global_init() and is_container_init().
      
      A cgroup init has it's tsk->pid == 1.
      
      A global init also has it's tsk->pid == 1 and it's active pid namespace
      is the init_pid_ns.  But rather than check the active pid namespace,
      compare the task structure with 'init_pid_ns.child_reaper', which is
      initialized during boot to the /sbin/init process and never changes.
      
      Changelog:
      
      	2.6.22-rc4-mm2-pidns1:
      	- Use 'init_pid_ns.child_reaper' to determine if a given task is the
      	  global init (/sbin/init) process. This would improve performance
      	  and remove dependence on the task_pid().
      
      	2.6.21-mm2-pidns2:
      
      	- [Sukadev Bhattiprolu] Changed is_container_init() calls in {powerpc,
      	  ppc,avr32}/traps.c for the _exception() call to is_global_init().
      	  This way, we kill only the cgroup if the cgroup's init has a
      	  bug rather than force a kernel panic.
      
      [akpm@linux-foundation.org: fix comment]
      [sukadev@us.ibm.com: Use is_global_init() in arch/m32r/mm/fault.c]
      [bunk@stusta.de: kernel/pid.c: remove unused exports]
      [sukadev@us.ibm.com: Fix capability.c to work with threaded init]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: NSukadev Bhattiprolu <sukadev@us.ibm.com>
      Acked-by: NPavel Emelianov <xemul@openvz.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Herbert Poetzel <herbert@13thfloor.at>
      Cc: Kirill Korotaev <dev@sw.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b460cbc5
  7. 19 10月, 2007 1 次提交
  8. 17 10月, 2007 5 次提交
  9. 09 5月, 2007 1 次提交
    • S
      kdump/kexec: calculate note size at compile time · 6672f76a
      Simon Horman 提交于
      Currently the size of the per-cpu region reserved to save crash notes is
      set by the per-architecture value MAX_NOTE_BYTES.  Which in turn is
      currently set to 1024 on all supported architectures.
      
      While testing ia64 I recently discovered that this value is in fact too
      small.  The particular setup I was using actually needs 1172 bytes.  This
      lead to very tedious failure mode where the tail of one elf note would
      overwrite the head of another if they ended up being alocated sequentially
      by kmalloc, which was often the case.
      
      It seems to me that a far better approach is to caclculate the size that
      the area needs to be.  This patch does just that.
      
      If a simpler stop-gap patch for ia64 to be squeezed into 2.6.21(.X) is
      needed then this should be as easy as making MAX_NOTE_BYTES larger in
      arch/asm-ia64/kexec.h.  Perhaps 2048 would be a good choice.  However, I
      think that the approach in this patch is a much more robust idea.
      Acked-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6672f76a
  10. 08 12月, 2006 3 次提交
  11. 30 9月, 2006 2 次提交
  12. 28 6月, 2006 1 次提交
    • D
      [POWERPC] Add the use of the firmware soft-reset-nmi to kdump. · c0ce7d08
      David Wilder 提交于
      With this patch, kdump uses the firmware soft-reset NMI for two purposes:
      1) Initiate the kdump (take a crash dump) by issuing a soft-reset.
      2) Break a CPU out of a deadlock condition that is detected during kdump
      processing.
      
      When a soft-reset is initiated each CPU will enter
      system_reset_exception() and set its corresponding bit in the global
      bit-array cpus_in_sr then call die(). When die() finds the CPU's bit set
      in cpu_in_sr crash_kexec() is called to initiate a crash dump. The first
      CPU to enter crash_kexec() is called the "crashing CPU". All other CPUs
      are "secondary CPUs". The secondary CPU's pass through to
      crash_kexec_secondary() and sleep. The crashing CPU waits for all CPUs
      to enter via soft-reset then boots the kdump kernel (see
      crash_soft_reset_check())
      
      When the system crashes due to a panic or exception, crash_kexec() is
      called by panic() or die(). The crashing CPU sends an IPI to all other
      CPUs to notify them of the pending shutdown. If a CPU is in a deadlock
      or hung state with interrupts disabled, the IPI will not be delivered.
      The result being, that the kdump kernel is not booted. This problem is
      solved with the use of a firmware generated soft-reset. After the
      crashing_cpu has issued the IPI, it waits for 10 sec for all CPUs to
      enter crash_ipi_callback(). A CPU signifies its entry to
      crash_ipi_callback() by setting its corresponding bit in the
      cpus_in_crash bit array. After 10 sec, if one or more CPUs have not set
      their bit in cpus_in_crash we assume that the CPU(s) is deadlocked. The
      operator is then prompted to generate a soft-reset to break the
      deadlock. Each CPU enters the soft reset handler as described above.
      
      Two conditions must be handled at this point:
      1) The system crashed because the operator generated a soft-reset. See
      2) The system had crashed before the soft-reset was generated ( in the
      case of a Panic or oops).
      
      The first CPU to enter crash_kexec() uses the state of the kexec_lock to
      determine this state. If kexec_lock is already held then condition 2 is
      true and crash_kexec_secondary() is called, else; this CPU is flagged as
      the crashing CPU, the kexec_lock is acquired and crash_kexec() proceeds
      as described above.
      
      Each additional CPUs responding to the soft-reset will pass through
      crash_kexec() to kexec_secondary(). All secondary CPUs call
      crash_ipi_callback() readying them self's for the shutdown. When ready
      they clear their bit in cpus_in_sr. The crashing CPU waits in
      kexec_secondary() until all other CPUs have cleared their bits in
      cpus_in_sr. The kexec kernel boot is then started.
      Signed-off-by: NHaren Myneni <haren@us.ibm.com>
      Signed-off-by: NDavid Wilder <dwilder@us.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c0ce7d08
  13. 23 6月, 2006 1 次提交
  14. 12 1月, 2006 1 次提交
  15. 11 1月, 2006 2 次提交
    • V
      [PATCH] kdump: save registers early (inline functions) · e996e581
      Vivek Goyal 提交于
      - If system panics then cpu register states are captured through funciton
        crash_get_current_regs().  This is not a inline function hence a stack frame
        is pushed on to the stack and then cpu register state is captured.  Later
        this frame is popped and new frames are pushed (machine_kexec).
      
      - In theory this is not very right as we are capturing register states for a
        frame and that frame is no more valid.  This seems to have created back
        trace problems for ppc64.
      
      - This patch fixes it up.  The very first thing it does after entering
        crash_kexec() is to capture the register states.  Anyway we don't want the
        back trace beyond crash_kexec().  crash_get_current_regs() has been made
        inline
      
      - crash_setup_regs() is the top architecture dependent function which should
        be responsible for capturing the register states as well as to do some
        architecture dependent tricks.  For ex.  fixing up ss and esp for i386.
        crash_setup_regs() has also been made inline to ensure no new call frame is
        pushed onto stack.
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e996e581
    • V
      [PATCH] kdump: dynamic per cpu allocation of memory for saving cpu registers · cc571658
      Vivek Goyal 提交于
      - In case of system crash, current state of cpu registers is saved in memory
        in elf note format.  So far memory for storing elf notes was being allocated
        statically for NR_CPUS.
      
      - This patch introduces dynamic allocation of memory for storing elf notes.
        It uses alloc_percpu() interface.  This should lead to better memory usage.
      
      - Introduced based on Andi Kleen's and Eric W. Biederman's suggestions.
      
      - This patch also moves memory allocation for elf notes from architecture
        dependent portion to architecture independent portion.  Now crash_notes is
        architecture independent.  The whole idea is that size of memory to be
        allocated per cpu (MAX_NOTE_BYTES) can be architecture dependent and
        allocation of this memory can be architecture independent.
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cc571658
  16. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: split page table lock · 4c21e2f2
      Hugh Dickins 提交于
      Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with
      a many-threaded application which concurrently initializes different parts of
      a large anonymous area.
      
      This patch corrects that, by using a separate spinlock per page table page, to
      guard the page table entries in that page, instead of using the mm's single
      page_table_lock.  (But even then, page_table_lock is still used to guard page
      table allocation, and anon_vma allocation.)
      
      In this implementation, the spinlock is tucked inside the struct page of the
      page table page: with a BUILD_BUG_ON in case it overflows - which it would in
      the case of 32-bit PA-RISC with spinlock debugging enabled.
      
      Splitting the lock is not quite for free: another cacheline access.  Ideally,
      I suppose we would use split ptlock only for multi-threaded processes on
      multi-cpu machines; but deciding that dynamically would have its own costs.
      So for now enable it by config, at some number of cpus - since the Kconfig
      language doesn't support inequalities, let preprocessor compare that with
      NR_CPUS.  But I don't think it's worth being user-configurable: for good
      testing of both split and unsplit configs, split now at 4 cpus, and perhaps
      change that to 8 later.
      
      There is a benefit even for singly threaded processes: kswapd can be attacking
      one part of the mm while another part is busy faulting.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4c21e2f2
  17. 28 10月, 2005 1 次提交
  18. 29 6月, 2005 1 次提交
  19. 26 6月, 2005 4 次提交