1. 11 1月, 2007 2 次提交
  2. 06 1月, 2007 1 次提交
  3. 21 12月, 2006 1 次提交
  4. 12 12月, 2006 2 次提交
    • L
      Make sure we populate the initroot filesystem late enough · 8d610dd5
      Linus Torvalds 提交于
      We should not initialize rootfs before all the core initializers have
      run.  So do it as a separate stage just before starting the regular
      driver initializers.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d610dd5
    • L
      Make SLES9 "get_kernel_version" work on the kernel binary again · 8993780a
      Linus Torvalds 提交于
      As reported by Andy Whitcroft, at least the SLES9 initrd build process
      depends on getting the kernel version from the kernel binary.  It does
      that by simply trawling the binary and looking for the signature of the
      "linux_banner" string (the string "Linux version " to be exact. Which
      is really broken in itself, but whatever..)
      
      That got broken when the string was changed to allow /proc/version to
      change the UTS release information dynamically, and "get_kernel_version"
      thus returned "%s" (see commit a2ee8649:
      "[PATCH] Fix linux banner utsname information").
      
      This just restores "linux_banner" as a static string, which should fix
      the version finding.  And /proc/version simply uses a different string.
      
      To avoid wasting even that miniscule amount of memory, the early boot
      string should really be marked __initdata, but that just causes the same
      bug in SLES9 to re-appear, since it will then find other occurrences of
      "Linux version " first.
      
      Cc: Andy Whitcroft <apw@shadowen.org>
      Acked-by: NHerbert Poetzl <herbert@13thfloor.at>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Steve Fox <drfickle@us.ibm.com>
      Acked-by: NOlaf Hering <olaf@aepfle.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8993780a
  5. 09 12月, 2006 2 次提交
  6. 08 12月, 2006 1 次提交
    • A
      [PATCH] gcc-4.1.0 is bust · f1a60dbf
      Andrew Morton 提交于
      Keith says
      
      Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux), wait_hpet_tick is
      optimized away to a never ending loop and the kernel hangs on boot in timer
      setup.
      
      0000001a <wait_hpet_tick>:
        1a:   55                      push   %ebp
        1b:   89 e5                   mov    %esp,%ebp
        1d:   eb fe                   jmp    1d <wait_hpet_tick+0x3>
      
      This is not a problem with gcc 3.3.5.  Adding barrier() calls to
      wait_hpet_tick does not help, making the variables volatile does.
      
      And the consensus is that gcc-4.1.0 is busted.  Suse went and shipped
      gcc-4.1.0 so we cannot ban it.  Add a warning.
      
      Cc: Keith Owens <kaos@ocs.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f1a60dbf
  7. 07 12月, 2006 1 次提交
  8. 22 10月, 2006 1 次提交
    • J
      [PATCH] x86-64: Speed up dwarf2 unwinder · 690a973f
      Jan Beulich 提交于
      This changes the dwarf2 unwinder to do a binary search for CIEs
      instead of a linear work. The linker is unfortunately not
      able to build a proper lookup table at link time, instead it creates
      one at runtime as soon as the bootmem allocator is usable (so you'll continue
      using the linear lookup for the first [hopefully] few calls).
      The code should be ready to utilize a build-time created table once
      a fixed linker becomes available.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      690a973f
  9. 02 10月, 2006 2 次提交
    • C
      [PATCH] replace cad_pid by a struct pid · 9ec52099
      Cedric Le Goater 提交于
      There are a few places in the kernel where the init task is signaled.  The
      ctrl+alt+del sequence is one them.  It kills a task, usually init, using a
      cached pid (cad_pid).
      
      This patch replaces the pid_t by a struct pid to avoid pid wrap around
      problem.  The struct pid is initialized at boot time in init() and can be
      modified through systctl with
      
      	/proc/sys/kernel/cad_pid
      
      [ I haven't found any distro using it ? ]
      
      It also introduces a small helper routine kill_cad_pid() which is used
      where it seemed ok to use cad_pid instead of pid 1.
      
      [akpm@osdl.org: cleanups, build fix]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9ec52099
    • A
      [PATCH] introduce kernel_execve · 67608567
      Arnd Bergmann 提交于
      The use of execve() in the kernel is dubious, since it relies on the
      __KERNEL_SYSCALLS__ mechanism that stores the result in a global errno
      variable.  As a first step of getting rid of this, change all users to a
      global kernel_execve function that returns a proper error code.
      
      This function is a terrible hack, and a later patch removes it again after the
      kernel syscalls are gone.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Paul 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      67608567
  10. 27 9月, 2006 1 次提交
  11. 26 9月, 2006 2 次提交
  12. 15 7月, 2006 2 次提交
    • S
      [PATCH] per-task-delay-accounting: taskstats interface · c757249a
      Shailabh Nagar 提交于
      Create a "taskstats" interface based on generic netlink (NETLINK_GENERIC
      family), for getting statistics of tasks and thread groups during their
      lifetime and when they exit.  The interface is intended for use by multiple
      accounting packages though it is being created in the context of delay
      accounting.
      
      This patch creates the interface without populating the fields of the data
      that is sent to the user in response to a command or upon the exit of a task.
      Each accounting package interested in using taskstats has to provide an
      additional patch to add its stats to the common structure.
      
      [akpm@osdl.org: cleanups, Kconfig fix]
      Signed-off-by: NShailabh Nagar <nagar@us.ibm.com>
      Signed-off-by: NBalbir Singh <balbir@in.ibm.com>
      Cc: Jes Sorensen <jes@sgi.com>
      Cc: Peter Chubb <peterc@gelato.unsw.edu.au>
      Cc: Erich Focht <efocht@ess.nec.de>
      Cc: Levent Serinol <lserinol@gmail.com>
      Cc: Jay Lan <jlan@engr.sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c757249a
    • S
      [PATCH] per-task-delay-accounting: setup · ca74e92b
      Shailabh Nagar 提交于
      Initialization code related to collection of per-task "delay" statistics which
      measure how long it had to wait for cpu, sync block io, swapping etc.  The
      collection of statistics and the interface are in other patches.  This patch
      sets up the data structures and allows the statistics collection to be
      disabled through a kernel boot parameter.
      Signed-off-by: NShailabh Nagar <nagar@watson.ibm.com>
      Signed-off-by: NBalbir Singh <balbir@in.ibm.com>
      Cc: Jes Sorensen <jes@sgi.com>
      Cc: Peter Chubb <peterc@gelato.unsw.edu.au>
      Cc: Erich Focht <efocht@ess.nec.de>
      Cc: Levent Serinol <lserinol@gmail.com>
      Cc: Jay Lan <jlan@engr.sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ca74e92b
  13. 04 7月, 2006 5 次提交
    • I
      [PATCH] lockdep: annotate genirq · 243c7621
      Ingo Molnar 提交于
      Teach special (recursive) locking code to the lock validator.  Has no effect
      on non-lockdep kernels.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      243c7621
    • I
      [PATCH] lockdep: core · fbb9ce95
      Ingo Molnar 提交于
      Do 'make oldconfig' and accept all the defaults for new config options -
      reboot into the kernel and if everything goes well it should boot up fine and
      you should have /proc/lockdep and /proc/lockdep_stats files.
      
      Typically if the lock validator finds some problem it will print out
      voluminous debug output that begins with "BUG: ..." and which syslog output
      can be used by kernel developers to figure out the precise locking scenario.
      
      What does the lock validator do?  It "observes" and maps all locking rules as
      they occur dynamically (as triggered by the kernel's natural use of spinlocks,
      rwlocks, mutexes and rwsems).  Whenever the lock validator subsystem detects a
      new locking scenario, it validates this new rule against the existing set of
      rules.  If this new rule is consistent with the existing set of rules then the
      new rule is added transparently and the kernel continues as normal.  If the
      new rule could create a deadlock scenario then this condition is printed out.
      
      When determining validity of locking, all possible "deadlock scenarios" are
      considered: assuming arbitrary number of CPUs, arbitrary irq context and task
      context constellations, running arbitrary combinations of all the existing
      locking scenarios.  In a typical system this means millions of separate
      scenarios.  This is why we call it a "locking correctness" validator - for all
      rules that are observed the lock validator proves it with mathematical
      certainty that a deadlock could not occur (assuming that the lock validator
      implementation itself is correct and its internal data structures are not
      corrupted by some other kernel subsystem).  [see more details and conditionals
      of this statement in include/linux/lockdep.h and
      Documentation/lockdep-design.txt]
      
      Furthermore, this "all possible scenarios" property of the validator also
      enables the finding of complex, highly unlikely multi-CPU multi-context races
      via single single-context rules, increasing the likelyhood of finding bugs
      drastically.  In practical terms: the lock validator already found a bug in
      the upstream kernel that could only occur on systems with 3 or more CPUs, and
      which needed 3 very unlikely code sequences to occur at once on the 3 CPUs.
      That bug was found and reported on a single-CPU system (!).  So in essence a
      race will be found "piecemail-wise", triggering all the necessary components
      for the race, without having to reproduce the race scenario itself!  In its
      short existence the lock validator found and reported many bugs before they
      actually caused a real deadlock.
      
      To further increase the efficiency of the validator, the mapping is not per
      "lock instance", but per "lock-class".  For example, all struct inode objects
      in the kernel have inode->inotify_mutex.  If there are 10,000 inodes cached,
      then there are 10,000 lock objects.  But ->inotify_mutex is a single "lock
      type", and all locking activities that occur against ->inotify_mutex are
      "unified" into this single lock-class.  The advantage of the lock-class
      approach is that all historical ->inotify_mutex uses are mapped into a single
      (and as narrow as possible) set of locking rules - regardless of how many
      different tasks or inode structures it took to build this set of rules.  The
      set of rules persist during the lifetime of the kernel.
      
      To see the rough magnitude of checking that the lock validator does, here's a
      portion of /proc/lockdep_stats, fresh after bootup:
      
       lock-classes:                            694 [max: 2048]
       direct dependencies:                  1598 [max: 8192]
       indirect dependencies:               17896
       all direct dependencies:             16206
       dependency chains:                    1910 [max: 8192]
       in-hardirq chains:                      17
       in-softirq chains:                     105
       in-process chains:                    1065
       stack-trace entries:                 38761 [max: 131072]
       combined max dependencies:         2033928
       hardirq-safe locks:                     24
       hardirq-unsafe locks:                  176
       softirq-safe locks:                     53
       softirq-unsafe locks:                  137
       irq-safe locks:                         59
       irq-unsafe locks:                      176
      
      The lock validator has observed 1598 actual single-thread locking patterns,
      and has validated all possible 2033928 distinct locking scenarios.
      
      More details about the design of the lock validator can be found in
      Documentation/lockdep-design.txt, which can also found at:
      
         http://redhat.com/~mingo/lockdep-patches/lockdep-design.txt
      
      [bunk@stusta.de: cleanups]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fbb9ce95
    • I
      [PATCH] lockdep: better lock debugging · 9a11b49a
      Ingo Molnar 提交于
      Generic lock debugging:
      
       - generalized lock debugging framework. For example, a bug in one lock
         subsystem turns off debugging in all lock subsystems.
      
       - got rid of the caller address passing (__IP__/__IP_DECL__/etc.) from
         the mutex/rtmutex debugging code: it caused way too much prototype
         hackery, and lockdep will give the same information anyway.
      
       - ability to do silent tests
      
       - check lock freeing in vfree too.
      
       - more finegrained debugging options, to allow distributions to
         turn off more expensive debugging features.
      
      There's no separate 'held mutexes' list anymore - but there's a 'held locks'
      stack within lockdep, which unifies deadlock detection across all lock
      classes.  (this is independent of the lockdep validation stuff - lockdep first
      checks whether we are holding a lock already)
      
      Here are the current debugging options:
      
      CONFIG_DEBUG_MUTEXES=y
      CONFIG_DEBUG_LOCK_ALLOC=y
      
      which do:
      
       config DEBUG_MUTEXES
                bool "Mutex debugging, basic checks"
      
       config DEBUG_LOCK_ALLOC
               bool "Detect incorrect freeing of live mutexes"
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9a11b49a
    • H
      [PATCH] lockdep: console_init after local_irq_enable() · 93e02814
      Heiko Carstens 提交于
      s390's console_init must enable interrupts, but early_boot_irqs_on() gets
      called later.  To avoid problems move console_init() after local_irq_enable().
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      93e02814
    • J
      [PATCH] time initialisation fix · 88fecaa2
      john stultz 提交于
      We're not reay to take a timer interrupt until timekeeping_init() has run.
      But time_init() will start the time interrupt and if it is called with
      local interrupts enabled we'll immediately take an interrupt and die.
      
      Fix that by running timekeeping_init() prior to time_init().
      
      We don't know _why_ local interrupts got enabled on Jesse Brandeburg's
      machine.  That's a separate as-yet-unsolved problem.  THe patch adds a little
      bit of debugging to detect that.
      
      This whole requirement that local interrupts be held off during early boot
      keeps on biting us.
      Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      88fecaa2
  14. 01 7月, 2006 2 次提交
  15. 28 6月, 2006 1 次提交
  16. 27 6月, 2006 3 次提交
  17. 02 5月, 2006 1 次提交
  18. 29 3月, 2006 1 次提交
  19. 27 3月, 2006 1 次提交
    • A
      [PATCH] remove fixup_cpu_present_map() · 9a98e2f7
      Andrew Morton 提交于
      Since the addition of boot_cpu_init(), fixup_cpu_present_map() has been a
      no-op.  That's because fixup_cpu_present_map() won't touch cpu_present_map if
      it has any bits set, and boot_cpu_init() sets a bit.
      
      So remove fixup_cpu_present_map().
      
      A consequence of this (actually of the boot_cpu_init() change) is that the
      architecture _must_ populate cpu_present_map itself (probably in
      smp_prepare_cpus()).  fixup_cpu_present_map() won't do it any more.
      
      If the architecture doesn't do this, it'll only bring up a single CPU.
      
      The other side effect (though less serious) is that smp_prepare_boot_cpu() no
      longer needs to mark the boot cpu in the online and present maps -
      boot_cpu_init() does that for everyone (to make early printks work).
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9a98e2f7
  20. 26 3月, 2006 2 次提交
  21. 23 3月, 2006 3 次提交
  22. 11 2月, 2006 1 次提交
  23. 15 1月, 2006 1 次提交
  24. 11 1月, 2006 1 次提交