1. 07 5月, 2008 1 次提交
  2. 06 5月, 2008 2 次提交
  3. 05 5月, 2008 1 次提交
    • L
      Make forced module loading optional · 826e4506
      Linus Torvalds 提交于
      The kernel module loader used to be much too happy to allow loading of
      modules for the wrong kernel version by default.  For example, if you
      had MODVERSIONS enabled, but tried to load a module with no version
      info, it would happily load it and taint the kernel - whether it was
      likely to actually work or not!
      
      Generally, such forced module loading should be considered a really
      really bad idea, so make it conditional on a new config option
      (MODULE_FORCE_LOAD), and make it default to off.
      
      If somebody really wants to force module loads, that's their problem,
      but we should not encourage it.  Especially as it happened to me by
      mistake (ie regular unversioned Fedora modules getting loaded) causing
      lots of strange behavior.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      826e4506
  4. 02 5月, 2008 1 次提交
  5. 29 4月, 2008 6 次提交
    • H
      sysctl: allow embedded targets to disable sysctl_check.c · 88f458e4
      Holger Schurig 提交于
      Disable sysctl_check.c for embedded targets. This saves about about 11 kB
      in .text and another 11 kB in .data on a PXA255 embedded platform.
      Signed-off-by: NHolger Schurig <hs4233@mail.mn-solutions.de>
      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>
      88f458e4
    • B
      cgroups: add an owner to the mm_struct · cf475ad2
      Balbir Singh 提交于
      Remove the mem_cgroup member from mm_struct and instead adds an owner.
      
      This approach was suggested by Paul Menage.  The advantage of this approach
      is that, once the mm->owner is known, using the subsystem id, the cgroup
      can be determined.  It also allows several control groups that are
      virtually grouped by mm_struct, to exist independent of the memory
      controller i.e., without adding mem_cgroup's for each controller, to
      mm_struct.
      
      A new config option CONFIG_MM_OWNER is added and the memory resource
      controller selects this config option.
      
      This patch also adds cgroup callbacks to notify subsystems when mm->owner
      changes.  The mm_cgroup_changed callback is called with the task_lock() of
      the new task held and is called just prior to changing the mm->owner.
      
      I am indebted to Paul Menage for the several reviews of this patchset and
      helping me make it lighter and simpler.
      
      This patch was tested on a powerpc box, it was compiled with both the
      MM_OWNER config turned on and off.
      
      After the thread group leader exits, it's moved to init_css_state by
      cgroup_exit(), thus all future charges from runnings threads would be
      redirected to the init_css_set's subsystem.
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Pavel Emelianov <xemul@openvz.org>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Cc: Hirokazu Takahashi <taka@valinux.co.jp>
      Cc: David Rientjes <rientjes@google.com>,
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Acked-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Reviewed-by: NPaul Menage <menage@google.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cf475ad2
    • S
      cgroups: implement device whitelist · 08ce5f16
      Serge E. Hallyn 提交于
      Implement a cgroup to track and enforce open and mknod restrictions on device
      files.  A device cgroup associates a device access whitelist with each cgroup.
       A whitelist entry has 4 fields.  'type' is a (all), c (char), or b (block).
      'all' means it applies to all types and all major and minor numbers.  Major
      and minor are either an integer or * for all.  Access is a composition of r
      (read), w (write), and m (mknod).
      
      The root device cgroup starts with rwm to 'all'.  A child devcg gets a copy of
      the parent.  Admins can then remove devices from the whitelist or add new
      entries.  A child cgroup can never receive a device access which is denied its
      parent.  However when a device access is removed from a parent it will not
      also be removed from the child(ren).
      
      An entry is added using devices.allow, and removed using
      devices.deny.  For instance
      
      	echo 'c 1:3 mr' > /cgroups/1/devices.allow
      
      allows cgroup 1 to read and mknod the device usually known as
      /dev/null.  Doing
      
      	echo a > /cgroups/1/devices.deny
      
      will remove the default 'a *:* mrw' entry.
      
      CAP_SYS_ADMIN is needed to change permissions or move another task to a new
      cgroup.  A cgroup may not be granted more permissions than the cgroup's parent
      has.  Any task can move itself between cgroups.  This won't be sufficient, but
      we can decide the best way to adequately restrict movement later.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix may-be-used-uninitialized warning]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Looks-good-to: Pavel Emelyanov <xemul@openvz.org>
      Cc: Daniel Hokka Zakrisson <daniel@hozac.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08ce5f16
    • P
      CGroup API files: make CGROUP_DEBUG default to off · 418d7d87
      Paul Menage 提交于
      The cgroup debug subsystem isn't generally useful for users.  It should
      default to "n".
      Signed-off-by: NPaul Menage <menage@google.com>
      Cc: "Li Zefan" <lizf@cn.fujitsu.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: "YAMAMOTO Takashi" <yamamoto@valinux.co.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      418d7d87
    • A
      let LOG_BUF_SHIFT default to 17 · f17a32e9
      Adrian Bunk 提交于
      16 kB is often no longer enough for a normal boot of an UP system.
      
      And even less when people e.g. use suspend.
      
      17 seems to be a more reasonable default for current kernels on current
      hardware (it's just the default, anyone who is memory limited can still lower
      it).
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f17a32e9
    • I
      make CC_OPTIMIZE_FOR_SIZE non-experimental · 96fffeb4
      Ingo Molnar 提交于
      this option has been the default on a wide range of distributions
      for a long time - time to make it non-experimental.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96fffeb4
  6. 27 4月, 2008 1 次提交
  7. 20 4月, 2008 1 次提交
  8. 14 4月, 2008 1 次提交
    • C
      slub: No need for per node slab counters if !SLUB_DEBUG · 0f389ec6
      Christoph Lameter 提交于
      The per node counters are used mainly for showing data through the sysfs API.
      If that API is not compiled in then there is no point in keeping track of this
      data. Disable counters for the number of slabs and the number of total slabs
      if !SLUB_DEBUG. Incrementing the per node counters is also accessing a
      potentially contended cacheline so this could actually be a performance
      benefit to embedded systems.
      
      SLABINFO support is also affected. It now must depends on SLUB_DEBUG (which
      is on by default).
      
      Patch also avoids a check for a NULL kmem_cache_node pointer in new_slab()
      if the system is not compiled with NUMA support.
      
      [penberg@cs.helsinki.fi: fix oops and move ->nr_slabs into CONFIG_SLUB_DEBUG]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      0f389ec6
  9. 11 3月, 2008 1 次提交
    • P
      rcu: move PREEMPT_RCU config option back under PREEMPT · 21bbb39c
      Paul E. McKenney 提交于
      The original preemptible-RCU patch put the choice between classic and
      preemptible RCU into kernel/Kconfig.preempt, which resulted in build failures
      on machines not supporting CONFIG_PREEMPT.  This choice was therefore moved to
      init/Kconfig, which worked, but placed the choice between classic and
      preemptible RCU at the top level, a very obtuse choice indeed.
      
      This patch changes from the Kconfig "choice" mechanism to a pair of booleans,
      only one of which (CONFIG_PREEMPT_RCU) is user-visible, and is located in
      kernel/Kconfig.preempt, where one would expect it to be.  The other
      (CONFIG_CLASSIC_RCU) is in init/Kconfig so that it is available to all
      architectures, hopefully avoiding build breakage.  Thanks to Roman Zippel for
      suggesting this approach.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: Josh Triplett <josh@freedesktop.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      21bbb39c
  10. 05 3月, 2008 3 次提交
  11. 24 2月, 2008 1 次提交
  12. 13 2月, 2008 1 次提交
  13. 10 2月, 2008 1 次提交
  14. 09 2月, 2008 5 次提交
  15. 08 2月, 2008 2 次提交
  16. 07 2月, 2008 1 次提交
  17. 06 2月, 2008 3 次提交
  18. 03 2月, 2008 2 次提交
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      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: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Create arch/Kconfig · fb32e03f
      Mathieu Desnoyers 提交于
      Puts the content of arch/Kconfig in the "General setup" menu.
      
      Linus:
      
      > Should it come with a re-duplication of it's content into each
      > architecture, which was the case previously ? The oprofile and kprobes
      > menu entries were litteraly cut and pasted from one architecture to
      > another. Should we put its content in init/Kconfig then ?
      
      I don't think it's a good idea to go back to making it per-architecture,
      although that extensive "depends on <list-of-archiectures-here>" might
      indicate that there certainly is room for cleanup there.
      
      And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I
      just think it's wrong to (a) lump the code together when it really doesn't
      necessarily need to and (b) show it to users as some kind of choice that
      is tied together (whether it then has common code or not).
      
      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...
      
      Sam Ravnborg:
      
      Stuff it into a new file: arch/Kconfig
      We can then extend this file to include all the 'trailing'
      Kconfig things that are anyway equal for all ARCHs.
      
      But it should be kept clean - so if we introduce such a file
      then we should use ARCH_HAS_whatever in the arch specific Kconfig
      files to enable stuff that is not shared.
      
      [...]
      
      The above suggestion is actually not exactly the best way to do it...
      First the naming..
      A quick grep shows following usage today (in Kconfig files)
      ARCH_HAS        51
      ARCH_SUPPORTS   4
      HAVE_ARCH       7
      
      ARCH_HAS is the clear winner.
      
      In the common Kconfig file do:
      
      config FOO
              depends on ARCH_HAS_FOO
              bool "bla bla"
      
      config ARCH_HAS_FOO
              def_bool n
      
      In the arch specific Kconfig file in a suitable place do:
      
      config SUITABLE_OPTION
              select ARCH_HAS_FOO
      
      The naming of ARCH_HAS_ is fixed and shall be:
      ARCH_HAS_<config option it will enable>
      
      Only a single line added pr. architecture.
      And we will end up with a (maybe even commented) list of trivial selects.
      
      - Yet another update :
      
      Moving to HAVE_* now.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      fb32e03f
  19. 01 2月, 2008 1 次提交
  20. 29 1月, 2008 1 次提交
  21. 28 1月, 2008 1 次提交
  22. 26 1月, 2008 1 次提交
  23. 25 1月, 2008 1 次提交
  24. 03 1月, 2008 1 次提交