1. 20 10月, 2008 1 次提交
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley 提交于
      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: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  2. 17 10月, 2008 4 次提交
  3. 02 8月, 2008 1 次提交
  4. 27 7月, 2008 2 次提交
  5. 25 7月, 2008 1 次提交
  6. 28 6月, 2008 1 次提交
    • A
      PCI: remove unused arch pcibios_update_resource() functions · 0aea5313
      Adrian Bunk 提交于
      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: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NGreg Ungerer <gerg@uclinux.org>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0aea5313
  7. 07 6月, 2008 1 次提交
  8. 25 5月, 2008 1 次提交
  9. 17 5月, 2008 1 次提交
  10. 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
  11. 01 5月, 2008 1 次提交
  12. 29 4月, 2008 5 次提交
  13. 22 4月, 2008 1 次提交
  14. 21 4月, 2008 2 次提交
    • G
      PCI: remove pcibios_fixup_ghosts() · 6355f3d1
      Greg Kroah-Hartman 提交于
      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: NGreg Kroah-Hartman <gregkh@suse.de>
      6355f3d1
    • G
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      Greg Kroah-Hartman 提交于
      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: NGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
  15. 17 4月, 2008 1 次提交
  16. 15 4月, 2008 1 次提交
  17. 14 4月, 2008 1 次提交
  18. 11 4月, 2008 2 次提交
  19. 21 2月, 2008 2 次提交
  20. 14 2月, 2008 2 次提交
  21. 09 2月, 2008 4 次提交
    • S
      ide: introduce HAVE_IDE · ec7748b5
      Sam Ravnborg 提交于
      To allow flexible configuration of IDE introduce HAVE_IDE.
      All archs except arm, um and s390 unconditionally select it.
      For arm the actual configuration determine if IDE is supported.
      
      This is a step towards introducing drivers/Kconfig for arm.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Acked-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
      Acked-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      ec7748b5
    • M
      CONFIG_HIGHPTE vs. sub-page page tables. · 2f569afd
      Martin Schwidefsky 提交于
      Background: I've implemented 1K/2K page tables for s390.  These sub-page
      page tables are required to properly support the s390 virtualization
      instruction with KVM.  The SIE instruction requires that the page tables
      have 256 page table entries (pte) followed by 256 page status table entries
      (pgste).  The pgstes are only required if the process is using the SIE
      instruction.  The pgstes are updated by the hardware and by the hypervisor
      for a number of reasons, one of them is dirty and reference bit tracking.
      To avoid wasting memory the standard pte table allocation should return
      1K/2K (31/64 bit) and 2K/4K if the process is using SIE.
      
      Problem: Page size on s390 is 4K, page table size is 1K or 2K.  That means
      the s390 version for pte_alloc_one cannot return a pointer to a struct
      page.  Trouble is that with the CONFIG_HIGHPTE feature on x86 pte_alloc_one
      cannot return a pointer to a pte either, since that would require more than
      32 bit for the return value of pte_alloc_one (and the pte * would not be
      accessible since its not kmapped).
      
      Solution: The only solution I found to this dilemma is a new typedef: a
      pgtable_t.  For s390 pgtable_t will be a (pte *) - to be introduced with a
      later patch.  For everybody else it will be a (struct page *).  The
      additional problem with the initialization of the ptl lock and the
      NR_PAGETABLE accounting is solved with a constructor pgtable_page_ctor and
      a destructor pgtable_page_dtor.  The page table allocation and free
      functions need to call these two whenever a page table page is allocated or
      freed.  pmd_populate will get a pgtable_t instead of a struct page pointer.
       To get the pgtable_t back from a pmd entry that has been installed with
      pmd_populate a new function pmd_pgtable is added.  It replaces the pmd_page
      call in free_pte_range and apply_to_pte_range.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f569afd
    • H
      avoid overflows in kernel/time.c · bdc80787
      H. Peter Anvin 提交于
      When the conversion factor between jiffies and milli- or microseconds is
      not a single multiply or divide, as for the case of HZ == 300, we currently
      do a multiply followed by a divide.  The intervening result, however, is
      subject to overflows, especially since the fraction is not simplified (for
      HZ == 300, we multiply by 300 and divide by 1000).
      
      This is exposed to the user when passing a large timeout to poll(), for
      example.
      
      This patch replaces the multiply-divide with a reciprocal multiplication on
      32-bit platforms.  When the input is an unsigned long, there is no portable
      way to do this on 64-bit platforms there is no portable way to do this
      since it requires a 128-bit intermediate result (which gcc does support on
      64-bit platforms but may generate libgcc calls, e.g.  on 64-bit s390), but
      since the output is a 32-bit integer in the cases affected, just simplify
      the multiply-divide (*3/10 instead of *300/1000).
      
      The reciprocal multiply used can have off-by-one errors in the upper half
      of the valid output range.  This could be avoided at the expense of having
      to deal with a potential 65-bit intermediate result.  Since the intent is
      to avoid overflow problems and most of the other time conversions are only
      semiexact, the off-by-one errors were considered an acceptable tradeoff.
      
      At Ralf Baechle's suggestion, this version uses a Perl script to compute
      the necessary constants.  We already have dependencies on Perl for kernel
      compiles.  This does, however, require the Perl module Math::BigInt, which
      is included in the standard Perl distribution starting with version 5.8.0.
      In order to support older versions of Perl, include a table of canned
      constants in the script itself, and structure the script so that
      Math::BigInt isn't required if pulling values from said table.
      
      Running the script requires that the HZ value is available from the
      Makefile.  Thus, this patch also adds the Kconfig variable CONFIG_HZ to the
      architectures which didn't already have it (alpha, cris, frv, h8300, m32r,
      m68k, m68knommu, sparc, v850, and xtensa.) It does *not* touch the sh or
      sh64 architectures, since Paul Mundt has dealt with those separately in the
      sh tree.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>,
      Cc: Sam Ravnborg <sam@ravnborg.org>,
      Cc: Paul Mundt <lethal@linux-sh.org>,
      Cc: Richard Henderson <rth@twiddle.net>,
      Cc: Michael Starvik <starvik@axis.com>,
      Cc: David Howells <dhowells@redhat.com>,
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>,
      Cc: Hirokazu Takata <takata@linux-m32r.org>,
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
      Cc: Roman Zippel <zippel@linux-m68k.org>,
      Cc: William L. Irwin <sparclinux@vger.kernel.org>,
      Cc: Chris Zankel <chris@zankel.net>,
      Cc: H. Peter Anvin <hpa@zytor.com>,
      Cc: Jan Engelhardt <jengelh@computergmbh.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bdc80787
    • J
  22. 08 2月, 2008 1 次提交
    • B
      Introduce flags for reserve_bootmem() · 72a7fe39
      Bernhard Walle 提交于
      This patchset adds a flags variable to reserve_bootmem() and uses the
      BOOTMEM_EXCLUSIVE flag in crashkernel reservation code to detect collisions
      between crashkernel area and already used memory.
      
      This patch:
      
      Change the reserve_bootmem() function to accept a new flag BOOTMEM_EXCLUSIVE.
      If that flag is set, the function returns with -EBUSY if the memory already
      has been reserved in the past.  This is to avoid conflicts.
      
      Because that code runs before SMP initialisation, there's no race condition
      inside reserve_bootmem_core().
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix powerpc build]
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72a7fe39
  23. 07 2月, 2008 1 次提交
    • A
      calibrate_delay() must be __cpuinit · 6c81c32f
      Adrian Bunk 提交于
      calibrate_delay() must be __cpuinit, not __{dev,}init.
      
      I've verified that this is correct for all users.
      
      While doing the latter, I also did the following cleanups:
      - remove pointless additional prototypes in C files
      - ensure all users #include <linux/delay.h>
      
      This fixes the following section mismatches with CONFIG_HOTPLUG=n,
      CONFIG_HOTPLUG_CPU=y:
      
      WARNING: vmlinux.o(.text+0x1128d): Section mismatch: reference to .init.text.1:calibrate_delay (between 'check_cx686_slop' and 'set_cx86_reorder')
      WARNING: vmlinux.o(.text+0x25102): Section mismatch: reference to .init.text.1:calibrate_delay (between 'smp_callin' and 'cpu_coregroup_map')
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Christian Zankel <chris@zankel.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6c81c32f
  24. 06 2月, 2008 2 次提交
反馈
建议
客服 返回
顶部