1. 09 Oct, 2012 1 commit
  2. 30 Jul, 2012 1 commit
  3. 21 May, 2012 1 commit
  4. 05 May, 2012 2 commits
  5. 31 Oct, 2011 1 commit
  6. 17 Oct, 2011 1 commit
  7. 05 Jul, 2011 1 commit
    • Frederic Weisbecker's avatar
      m32r: Use generic PREEMPT config · dab16ae1
      Frederic Weisbecker authored
      Use the generic preempt config definition in m32r instead of
      using a custom one.
      This also makes it handle the new CONFIG_PREEMPT_COUNT that
      need to be selected by CONFIG_PREEMPT.
      Without that it breaks
        kernel/sched.c: In function 'preempt_schedule':
        kernel/sched.c:4364: error: implicit declaration of function 'add_preempt_count_notrace'
        kernel/sched.c:4366: error: implicit declaration of function 'sub_preempt_count_notrace'
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
  8. 26 May, 2011 1 commit
  9. 30 Mar, 2011 1 commit
  10. 24 Mar, 2011 1 commit
  11. 23 Mar, 2011 1 commit
  12. 21 Jan, 2011 1 commit
  13. 18 Oct, 2010 1 commit
  14. 19 Sep, 2010 1 commit
  15. 27 Jul, 2010 1 commit
  16. 03 Nov, 2009 1 commit
  17. 22 Sep, 2009 1 commit
  18. 13 Dec, 2008 1 commit
    • Rusty Russell's avatar
      cpumask: centralize cpu_online_map and cpu_possible_map · 98a79d6a
      Rusty Russell authored
      Impact: cleanup
      Each SMP arch defines these themselves.  Move them to a central
      1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
         CONFIG_INIT_ALL_POSSIBLE for this rather than break them.
      2) mips and sparc32 '#define cpu_possible_map phys_cpu_present_map'.
         Those archs simply have phys_cpu_present_map replaced everywhere.
      3) Alpha defined cpu_possible_map to cpu_present_map; this is tricky
         so I just manipulate them both in sync.
      4) IA64, cris and m32r have gratuitous 'extern cpumask_t cpu_possible_map'
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: default avatarGrant Grundler <grundler@parisc-linux.org>
      Tested-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Mike Travis <travis@sgi.com>
      Cc: ink@jurassic.park.msu.ru
      Cc: rmk@arm.linux.org.uk
      Cc: starvik@axis.com
      Cc: tony.luck@intel.com
      Cc: takata@linux-m32r.org
      Cc: ralf@linux-mips.org
      Cc: grundler@parisc-linux.org
      Cc: paulus@samba.org
      Cc: schwidefsky@de.ibm.com
      Cc: lethal@linux-sh.org
      Cc: wli@holomorphy.com
      Cc: davem@davemloft.net
      Cc: jdike@addtoit.com
      Cc: mingo@redhat.com
  19. 11 Nov, 2008 1 commit
  20. 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
      to freeze all tasks in the container :
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         # cat /containers/0/freezer.state
      to unfreeze all tasks in the container :
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
      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>
  21. 27 Sep, 2008 2 commits
  22. 06 Sep, 2008 1 commit
  23. 26 Jun, 2008 1 commit
  24. 09 Feb, 2008 1 commit
  25. 08 Feb, 2008 2 commits
    • H. Peter Anvin's avatar
      avoid overflows in kernel/time.c · bdc80787
      H. Peter Anvin authored
      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
      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: default avatarH. 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • David Howells's avatar
      aout: mark arches that support A.OUT format · b0b933c0
      David Howells authored
      Mark arches that support A.OUT format by including the following in their
      master Kconfig files:
      	config ARCH_SUPPORTS_AOUT
      		def_bool y
      This should also be set if the arch provides compatibility A.OUT support for
      an older arch, for instance x86_64 for i386 or sparc64 for sparc.
      I've guessed at which arches don't, based on comments in the code, however I'm
      sure that some of the ones I've marked as 'yes' actually should be 'no'.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  26. 03 Feb, 2008 3 commits
    • Adrian Bunk's avatar
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk authored
      After seeing the filename I'd have expected something about the
      implementation of SMP in the Linux kernel - not some notes on kernel
      configuration and building trivialities noone would search at this
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
    • Mathieu Desnoyers's avatar
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers authored
      Move the instrumentation Kconfig to
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      init/Kconfig for architecture independent options
        - profiling
        - markers
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
    • Mathieu Desnoyers's avatar
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers authored
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      It would be much better to do
              depends on ARCH_SUPPORTS_KPROBES
      in that generic file, and then architectures that do support it would just
      have a
              bool ARCH_SUPPORTS_KPROBES
                      default y
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      instead, which is a bit denser.
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      Changelog :
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
  27. 01 Feb, 2008 1 commit
  28. 30 Jan, 2008 1 commit
    • Nick Piggin's avatar
      spinlock: lockbreak cleanup · 95c354fe
      Nick Piggin authored
      The break_lock data structure and code for spinlocks is quite nasty.
      Not only does it double the size of a spinlock but it changes locking to
      a potentially less optimal trylock.
      Put all of that under CONFIG_GENERIC_LOCKBREAK, and introduce a
      __raw_spin_is_contended that uses the lock data itself to determine whether
      there are waiters on the lock, to be used if CONFIG_GENERIC_LOCKBREAK is
      not set.
      Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
      decouple it from the spinlock implementation, and make it typesafe (rwlocks
      do not have any need_lockbreak sites -- why do they even get bloated up
      with that break_lock then?).
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  29. 19 Oct, 2007 1 commit
  30. 02 Sep, 2007 1 commit
  31. 16 Jul, 2007 1 commit
    • Dan Williams's avatar
      dma-mapping: prevent dma dependent code from linking on !HAS_DMA archs · 1b0fac45
      Dan Williams authored
      Continuing the work started in 411f0f3e
      This enables code with a dma path, that compiles away, to build without
      requiring additional code factoring.  It also prevents code that calls
      dma_alloc_coherent and dma_free_coherent from linking whereas previously
      the code would hit a BUG() at run time.  Finally, it allows archs that set
      !HAS_DMA to delete their asm/dma-mapping.h file.
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Kyle McMartin <kyle@parisc-linux.org>
      Cc: James Bottomley <James.Bottomley@SteelEye.com>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: <geert@linux-m68k.org>
      Cc: <zippel@linux-m68k.org>
      Cc: <spyro@f2s.com>
      Cc: <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  32. 11 May, 2007 1 commit
    • Hirokazu Takata's avatar
      m32r: fix switch_to macro to push/pop frame pointer if needed · 43c09ce7
      Hirokazu Takata authored
      This patch fixes a rarely-happened but severe scheduling problem of
      the recent m32r kernel of 2.6.17-rc3 or later.
      In the following previous m32r patch, the switch_to macro was
      modified not to do unnecessary push/pop operations for tuning.
      > [PATCH] m32r: update switch_to macro for tuning
      > 4127272c
      In this modification, only 'lr' and 'sp' registers are push/pop'ed,
      assuming that the m32r kernel is always compiled with
      -fomit-frame-pointer option.
      However, in 2.6 kernel, kernel/sched.c is irregularly compiled
      with -fno-omit-frame-pointer if CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER
      is not defined.
       -- kernel/Makefile --
       # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
       # needed for x86 only.  Why this used to be enabled for all architectures is beyond
       # me.  I suspect most platforms don't need this, but until we know that for sure
       # I turn this off for IA-64 only.  Andreas Schwab says it's also needed on m68k
       # to get a correct value for the wait-channel (WCHAN in ps). --davidm
       CFLAGS_sched.o := $(PROFILING) -fno-omit-frame-pointer
      Therefore, for the recent m32r kernel, we have to push/pop 'fp'
      (frame pointer) if CONFIG_FRAME_POINTER is defined or
      Signed-off-by: default avatarHitoshi Yamamoto <hitoshiy@linux-m32r.org>
      Signed-off-by: default avatarHirokazu Takata <takata@linux-m32r.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  33. 11 Feb, 2007 2 commits
    • Al Viro's avatar
      [PATCH] sort the devres mess out · 5ea81769
      Al Viro authored
      * Split the implementation-agnostic stuff in separate files.
      * Make sure that targets using non-default request_irq() pull
      * Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive;
        allow architectures to turn them off (we needed these symbols anyway for
        dependencies of quite a few drivers).
      * protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Christoph Lameter's avatar
      [PATCH] Set CONFIG_ZONE_DMA for arches with GENERIC_ISA_DMA · 5ac6da66
      Christoph Lameter authored
      As Andi pointed out: CONFIG_GENERIC_ISA_DMA only disables the ISA DMA
      channel management.  Other functionality may still expect GFP_DMA to
      provide memory below 16M.  So we need to make sure that CONFIG_ZONE_DMA is
      set independent of CONFIG_GENERIC_ISA_DMA.  Undo the modifications to
      mm/Kconfig where we made ZONE_DMA dependent on GENERIC_ISA_DMA and set
      theses explicitly in each arches Kconfig.
      Reviews must occur for each arch in order to determine if ZONE_DMA can be
      switched off.  It can only be switched off if we know that all devices
      supported by a platform are capable of performing DMA transfers to all of
      memory (Some arches already support this: uml, avr32, sh sh64, parisc and
      In order to switch ZONE_DMA off conditionally, one would have to establish
      a scheme by which one can assure that no drivers are enabled that are only
      capable of doing I/O to a part of memory, or one needs to provide an
      alternate means of performing an allocation from a specific range of memory
      (like provided by alloc_pages_range()) and insure that all drivers use that
      call.  In that case the arches alloc_dma_coherent() may need to be modified
      to call alloc_pages_range() instead of relying on GFP_DMA.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  34. 08 Dec, 2006 1 commit
    • David Howells's avatar
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells authored
      This facility provides three entry points:
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      These facilities can either be used inside functions on dynamic data:
      	int do_something(long q)
      		y = ilog2(x)
      Or can be used to statically initialise global variables with constant values:
      	unsigned n = ilog2(27);
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      [akpm@osdl.org: MMC fix]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>