1. 09 Apr, 2009 1 commit
  2. 06 Apr, 2009 1 commit
  3. 02 Apr, 2009 1 commit
  4. 30 Mar, 2009 1 commit
  5. 09 Feb, 2009 1 commit
  6. 11 Jan, 2009 1 commit
    • Yinghai Lu's avatar
      sparseirq: use kstat_irqs_cpu instead · dee4102a
      Yinghai Lu authored
      
      
      Impact: build fix
      
      Ingo Molnar wrote:
      
      > tip/arch/blackfin/kernel/irqchip.c: In function 'show_interrupts':
      > tip/arch/blackfin/kernel/irqchip.c:85: error: 'struct kernel_stat' has no member named 'irqs'
      > make[2]: *** [arch/blackfin/kernel/irqchip.o] Error 1
      > make[2]: *** Waiting for unfinished jobs....
      >
      
      So could move kstat_irqs array to irq_desc struct.
      
      (s390, m68k, sparc) are not touched yet, because they don't support genirq
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      dee4102a
  7. 08 Jan, 2009 1 commit
    • David Howells's avatar
      NOMMU: Make VMAs per MM as for MMU-mode linux · 8feae131
      David Howells authored
      
      
      Make VMAs per mm_struct as for MMU-mode linux.  This solves two problems:
      
       (1) In SYSV SHM where nattch for a segment does not reflect the number of
           shmat's (and forks) done.
      
       (2) In mmap() where the VMA's vm_mm is set to point to the parent mm by an
           exec'ing process when VM_EXECUTABLE is specified, regardless of the fact
           that a VMA might be shared and already have its vm_mm assigned to another
           process or a dead process.
      
      A new struct (vm_region) is introduced to track a mapped region and to remember
      the circumstances under which it may be shared and the vm_list_struct structure
      is discarded as it's no longer required.
      
      This patch makes the following additional changes:
      
       (1) Regions are now allocated with alloc_pages() rather than kmalloc() and
           with no recourse to __GFP_COMP, so the pages are not composite.  Instead,
           each page has a reference on it held by the region.  Anything else that is
           interested in such a page will have to get a reference on it to retain it.
           When the pages are released due to unmapping, each page is passed to
           put_page() and will be freed when the page usage count reaches zero.
      
       (2) Excess pages are trimmed after an allocation as the allocation must be
           made as a power-of-2 quantity of pages.
      
       (3) VMAs are added to the parent MM's R/B tree and mmap lists.  As an MM may
           end up with overlapping VMAs within the tree, the VMA struct address is
           appended to the sort key.
      
       (4) Non-anonymous VMAs are now added to the backing inode's prio list.
      
       (5) Holes may be punched in anonymous VMAs with munmap(), releasing parts of
           the backing region.  The VMA and region structs will be split if
           necessary.
      
       (6) sys_shmdt() only releases one attachment to a SYSV IPC shared memory
           segment instead of all the attachments at that addresss.  Multiple
           shmat()'s return the same address under NOMMU-mode instead of different
           virtual addresses as under MMU-mode.
      
       (7) Core dumping for ELF-FDPIC requires fewer exceptions for NOMMU-mode.
      
       (8) /proc/maps is now the global list of mapped regions, and may list bits
           that aren't actually mapped anywhere.
      
       (9) /proc/meminfo gains a line (tagged "MmapCopy") that indicates the amount
           of RAM currently allocated by mmap to hold mappable regions that can't be
           mapped directly.  These are copies of the backing device or file if not
           anonymous.
      
      These changes make NOMMU mode more similar to MMU mode.  The downside is that
      NOMMU mode requires some extra memory to track things over NOMMU without this
      patch (VMAs are no longer shared, and there are now region structs).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarMike Frysinger <vapier.adi@gmail.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      8feae131
  8. 31 Dec, 2008 1 commit
  9. 01 Dec, 2008 1 commit
  10. 20 Oct, 2008 1 commit
    • Matt Helsley's avatar
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley authored
      
      
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: default avatarCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  11. 16 Oct, 2008 4 commits
  12. 01 Aug, 2008 1 commit
  13. 26 Jul, 2008 2 commits
  14. 24 Jul, 2008 1 commit
  15. 27 Jun, 2008 1 commit
    • Adrian Bunk's avatar
      PCI: remove unused arch pcibios_update_resource() functions · 0aea5313
      Adrian Bunk authored
      
      
      Russell King did the following back in 2003:
      
      <--  snip  -->
      
          [PCI] pci-9: Kill per-architecture pcibios_update_resource()
      
          Kill pcibios_update_resource(), replacing it with pci_update_resource().
          pci_update_resource() uses pcibios_resource_to_bus() to convert a
          resource to a device BAR - the transformation should be exactly the
          same as the transformation used for the PCI bridges.
      
          pci_update_resource "knows" about 64-bit BARs, but doesn't attempt to
          set the high 32-bits to anything non-zero - currently no architecture
          attempts to do something different.  If anyone cares, please fix; I'm
          going to reflect current behaviour for the time being.
      
          Ivan pointed out the following architectures need to examine their
          pcibios_update_resource() implementation - they should make sure that
          this new implementation does the right thing.  #warning's have been
          added where appropriate.
      
              ia64
              mips
              mips64
      
          This cset also includes a fix for the problem reported by AKPM where
          64-bit arch compilers complain about the resource mask being placed
          in a u32.
      
      <--  snip  -->
      
      This patch removes the unused pcibios_update_resource() functions the
      kernel gained since, from FRV, m68k, mips & sh architectures.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      0aea5313
  16. 06 Jun, 2008 1 commit
  17. 24 May, 2008 1 commit
  18. 16 May, 2008 1 commit
  19. 03 May, 2008 1 commit
    • Ulrich Drepper's avatar
      unified (weak) sys_pipe implementation · d35c7b0e
      Ulrich Drepper authored
      
      
      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: default avatarUlrich Drepper <drepper@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d35c7b0e
  20. 01 May, 2008 1 commit
  21. 29 Apr, 2008 4 commits
  22. 28 Apr, 2008 1 commit
  23. 21 Apr, 2008 1 commit
  24. 20 Apr, 2008 2 commits
    • Greg Kroah-Hartman's avatar
      PCI: remove pcibios_fixup_ghosts() · 6355f3d1
      Greg Kroah-Hartman authored
      
      
      This function was obviously never being used since early 2.5 days as any
      device that it would try to remove would never really be removed from
      the system due to the PCI device list being held in the driver core, not
      the general list of PCI devices.
      
      As we have not had a single report of a problem here in 4 years, I think
      it's safe to remove now.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6355f3d1
    • Greg Kroah-Hartman's avatar
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      Greg Kroah-Hartman authored
      
      
      We currently keep 2 lists of PCI devices in the system, one in the
      driver core, and one all on its own.  This second list is sorted at boot
      time, in "BIOS" order, to try to remain compatible with older kernels
      (2.2 and earlier days).  There was also a "nosort" option to turn this
      sorting off, to remain compatible with even older kernel versions, but
      that just ends up being what we have been doing from 2.5 days...
      
      Unfortunately, the second list of devices is not really ever used to 
      determine the probing order of PCI devices or drivers[1].  That is done
      using the driver core list instead.  This change happened back in the
      early 2.5 days.
      
      Relying on BIOS ording for the binding of drivers to specific device
      names is problematic for many reasons, and userspace tools like udev
      exist to properly name devices in a persistant manner if that is needed,
      no reliance on the BIOS is needed.
      
      Matt Domsch and others at Dell noticed this back in 2006, and added a
      boot option to sort the PCI device lists (both of them) in a
      breadth-first manner to help remain compatible with the 2.4 order, if
      needed for any reason.  This option is not going away, as some systems
      rely on them.
      
      This patch removes the sorting of the internal PCI device list in "BIOS"
      mode, as it's not needed at all anymore, and hasn't for many years.
      I've also removed the PCI flags for this from some other arches that for
      some reason defined them, but never used them.
      
      This should not change the ordering of any drivers or device probing.
      
      [1] The old-style pci_get_device and pci_find_device() still used this
      sorting order, but there are very few drivers that use these functions,
      as they are deprecated for use in this manner.  If for some reason, a
      driver rely on the order and uses these functions, the breadth-first
      boot option will resolve any problem.
      
      Cc: Matt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
  25. 17 Apr, 2008 1 commit
  26. 15 Apr, 2008 1 commit
  27. 14 Apr, 2008 1 commit
  28. 10 Apr, 2008 2 commits
  29. 20 Feb, 2008 2 commits
  30. 13 Feb, 2008 1 commit
    • Peter Zijlstra's avatar
      xtime_lock vs update_process_times · aa02cd2d
      Peter Zijlstra authored
      Commit d3d74453
      
       ("hrtimer: fixup the
      HRTIMER_CB_IRQSAFE_NO_SOFTIRQ fallback") broke several archs, and since
      only Russell bothered to merge the fix, and Greg to ACK his arch, I'm
      sending this for merger.
      
      I have confirmation that the Alpha bit results in a booting kernel.
      That leaves: blackfin, frv, sh and sparc untested.
      
      The deadlock in question was found by Russell:
      
        IRQ handle
          -> timer_tick() - xtime seqlock held for write
            -> update_process_times()
              -> run_local_timers()
                -> hrtimer_run_queues()
                  -> hrtimer_get_softirq_time() - tries to get a read lock
      
      Now, Thomas assures me the fix is trivial, only do_timer() needs to be
      done under the xtime_lock, and update_process_times() can savely be
      removed from under it.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
      CC: Richard Henderson <rth@twiddle.net>
      CC: Bryan Wu <bryan.wu@analog.com>
      CC: David Howells <dhowells@redhat.com>
      CC: Paul Mundt <lethal@linux-sh.org>
      CC: William Irwin <wli@holomorphy.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      aa02cd2d