1. 10 Mar, 2009 1 commit
  2. 02 Mar, 2009 2 commits
  3. 25 Feb, 2009 1 commit
    • Paul E. McKenney's avatar
      rcu: Teach RCU that idle task is not quiscent state at boot · a6826048
      Paul E. McKenney authored
      This patch fixes a bug located by Vegard Nossum with the aid of
      kmemcheck, updated based on review comments from Nick Piggin,
      Ingo Molnar, and Andrew Morton.  And cleans up the variable-name
      and function-name language.  ;-)
      The boot CPU runs in the context of its idle thread during boot-up.
      During this time, idle_cpu(0) will always return nonzero, which will
      fool Classic and Hierarchical RCU into deciding that a large chunk of
      the boot-up sequence is a big long quiescent state.  This in turn causes
      RCU to prematurely end grace periods during this time.
      This patch changes the rcutree.c and rcuclassic.c rcu_check_callbacks()
      function to ignore the idle task as a quiescent state until the
      system has started up the scheduler in rest_init(), introducing a
      new non-API function rcu_idle_now_means_idle() to inform RCU of this
      transition.  RCU maintains an internal rcu_idle_cpu_truthful variable
      to track this state, which is then used by rcu_check_callback() to
      determine if it should believe idle_cpu().
      Because this patch has the effect of disallowing RCU grace periods
      during long stretches of the boot-up sequence, this patch also introduces
      Josh Triplett's UP-only optimization that makes synchronize_rcu() be a
      no-op if num_online_cpus() returns 1.  This allows boot-time code that
      calls synchronize_rcu() to proceed normally.  Note, however, that RCU
      callbacks registered by call_rcu() will likely queue up until later in
      the boot sequence.  Although rcuclassic and rcutree can also use this
      same optimization after boot completes, rcupreempt must restrict its
      use of this optimization to the portion of the boot sequence before the
      scheduler starts up, given that an rcupreempt RCU read-side critical
      section may be preeempted.
      In addition, this patch takes Nick Piggin's suggestion to make the
      system_state global variable be __read_mostly.
      Changes since v4:
      o	Changes the name of the introduced function and variable to
      	be less emotional.  ;-)
      Changes since v3:
      o	WARN_ON(nr_context_switches() > 0) to verify that RCU
      	switches out of boot-time mode before the first context
      	switch, as suggested by Nick Piggin.
      Changes since v2:
      o	Created rcu_blocking_is_gp() internal-to-RCU API that
      	determines whether a call to synchronize_rcu() is itself
      	a grace period.
      o	The definition of rcu_blocking_is_gp() for rcuclassic and
      	rcutree checks to see if but a single CPU is online.
      o	The definition of rcu_blocking_is_gp() for rcupreempt
      	checks to see both if but a single CPU is online and if
      	the system is still in early boot.
      	This allows rcupreempt to again work correctly if running
      	on a single CPU after booting is complete.
      o	Added check to rcupreempt's synchronize_sched() for there
      	being but one online CPU.
      Tested all three variants both SMP and !SMP, booted fine, passed a short
      rcutorture test on both x86 and Power.
      Located-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Tested-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Tested-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  4. 21 Feb, 2009 1 commit
  5. 26 Jan, 2009 1 commit
  6. 15 Jan, 2009 3 commits
  7. 14 Jan, 2009 1 commit
  8. 08 Jan, 2009 4 commits
  9. 07 Jan, 2009 1 commit
    • Arjan van de Ven's avatar
      async: Asynchronous function calls to speed up kernel boot · 22a9d645
      Arjan van de Ven authored
      Right now, most of the kernel boot is strictly synchronous, such that
      various hardware delays are done sequentially.
      In order to make the kernel boot faster, this patch introduces
      infrastructure to allow doing some of the initialization steps
      asynchronously, which will hide significant portions of the hardware delays
      in practice.
      In order to not change device order and other similar observables, this
      patch does NOT do full parallel initialization.
      Rather, it operates more in the way an out of order CPU does; the work may
      be done out of order and asynchronous, but the observable effects
      (instruction retiring for the CPU) are still done in the original sequence.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
  10. 06 Jan, 2009 8 commits
  11. 05 Jan, 2009 1 commit
  12. 04 Jan, 2009 1 commit
  13. 02 Jan, 2009 1 commit
  14. 31 Dec, 2008 2 commits
  15. 29 Dec, 2008 1 commit
  16. 27 Dec, 2008 1 commit
  17. 25 Dec, 2008 1 commit
    • Ingo Molnar's avatar
      rcu: provide RCU options on non-preempt architectures too · 12d79baf
      Ingo Molnar authored
      Impact: build fix
      Some old architectures still do not use kernel/Kconfig.preempt, so the
      moving of the RCU options there broke their build:
       In file included from /home/mingo/tip/include/linux/sem.h:81,
                       from /home/mingo/tip/include/linux/sched.h:69,
                       from /home/mingo/tip/arch/alpha/kernel/asm-offsets.c:9:
       /home/mingo/tip/include/linux/rcupdate.h:62:2: error: #error "Unknown RCU implementation specified to kernel configuration"
      Move these options back to init/Kconfig, which every architecture
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  18. 19 Dec, 2008 1 commit
    • Jan Beulich's avatar
      allow stripping of generated symbols under CONFIG_KALLSYMS_ALL · 9bb48247
      Jan Beulich authored
      Building upon parts of the module stripping patch, this patch
      introduces similar stripping for vmlinux when CONFIG_KALLSYMS_ALL=y.
      Using CONFIG_KALLSYMS_STRIP_GENERATED reduces the overhead of
      CONFIG_KALLSYMS_ALL from 245k/310k to 65k/80k for the (i386/x86-64)
      kernels I tested with.
      The patch also does away with the need to special case the kallsyms-
      internal symbols by making them available even in the first linking
      While it is a generated file, the patch includes the changes to
      scripts/genksyms/keywords.c_shipped, as I'm unsure what the procedure
      here is.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
  19. 18 Dec, 2008 1 commit
    • Paul E. McKenney's avatar
      "Tree RCU": scalable classic RCU implementation · 64db4cff
      Paul E. McKenney authored
      This patch fixes a long-standing performance bug in classic RCU that
      results in massive internal-to-RCU lock contention on systems with
      more than a few hundred CPUs.  Although this patch creates a separate
      flavor of RCU for ease of review and patch maintenance, it is intended
      to replace classic RCU.
      This patch still handles stress better than does mainline, so I am still
      calling it ready for inclusion.  This patch is against the -tip tree.
      Nevertheless, experience on an actual 1000+ CPU machine would still be
      most welcome.
      Most of the changes noted below were found while creating an rcutiny
      (which should permit ejecting the current rcuclassic) and while doing
      detailed line-by-line documentation.
      Updates from v9 (http://lkml.org/lkml/2008/12/2/334):
      o	Fixes from remainder of line-by-line code walkthrough,
      	including comment spelling, initialization, undesirable
      	narrowing due to type conversion, removing redundant memory
      	barriers, removing redundant local-variable initialization,
      	and removing redundant local variables.
      	I do not believe that any of these fixes address the CPU-hotplug
      	issues that Andi Kleen was seeing, but please do give it a whirl
      	in case the machine is smarter than I am.
      	A writeup from the walkthrough may be found at the following
      	URL, in case you are suffering from terminal insomnia or
      o	Made rcutree tracing use seq_file, as suggested some time
      	ago by Lai Jiangshan.
      o	Added a .csv variant of the rcudata debugfs trace file, to allow
      	people having thousands of CPUs to drop the data into
      	a spreadsheet.	Tested with oocalc and gnumeric.  Updated
      	documentation to suit.
      Updates from v8 (http://lkml.org/lkml/2008/11/15/139):
      o	Fix a theoretical race between grace-period initialization and
      	force_quiescent_state() that could occur if more than three
      	jiffies were required to carry out the grace-period
      	initialization.  Which it might, if you had enough CPUs.
      o	Apply Ingo's printk-standardization patch.
      o	Substitute local variables for repeated accesses to global
      o	Fix comment misspellings and redundant (but harmless) increments
      	of ->n_rcu_pending (this latter after having explicitly added it).
      o	Apply checkpatch fixes.
      Updates from v7 (http://lkml.org/lkml/2008/10/10/291):
      o	Fixed a number of problems noted by Gautham Shenoy, including
      	the cpu-stall-detection bug that he was having difficulty
      	convincing me was real.  ;-)
      o	Changed cpu-stall detection to wait for ten seconds rather than
      	three in order to reduce false positive, as suggested by Ingo
      o	Produced a design document (http://lwn.net/Articles/305782/).
      	The act of writing this document uncovered a number of both
      	theoretical and "here and now" bugs as noted below.
      o	Fix dynticks_nesting accounting confusion, simplify WARN_ON()
      	condition, fix kerneldoc comments, and add memory barriers
      	in dynticks interface functions.
      o	Add more data to tracing.
      o	Remove unused "rcu_barrier" field from rcu_data structure.
      o	Count calls to rcu_pending() from scheduling-clock interrupt
      	to use as a surrogate timebase should jiffies stop counting.
      o	Fix a theoretical race between force_quiescent_state() and
      	grace-period initialization.  Yes, initialization does have to
      	go on for some jiffies for this race to occur, but given enough
      Updates from v6 (http://lkml.org/lkml/2008/9/23/448):
      o	Fix a number of checkpatch.pl complaints.
      o	Apply review comments from Ingo Molnar and Lai Jiangshan
      	on the stall-detection code.
      o	Fix several bugs in !CONFIG_SMP builds.
      o	Fix a misspelled config-parameter name so that RCU now announces
      	at boot time if stall detection is configured.
      o	Run tests on numerous combinations of configurations parameters,
      	which after the fixes above, now build and run correctly.
      Updates from v5 (http://lkml.org/lkml/2008/9/15/92, bad subject line):
      o	Fix a compiler error in the !CONFIG_FANOUT_EXACT case (blew a
      	changeset some time ago, and finally got around to retesting
      	this option).
      o	Fix some tracing bugs in rcupreempt that caused incorrect
      	totals to be printed.
      o	I now test with a more brutal random-selection online/offline
      	script (attached).  Probably more brutal than it needs to be
      	on the people reading it as well, but so it goes.
      o	A number of optimizations and usability improvements:
      	o	Make rcu_pending() ignore the grace-period timeout when
      		there is no grace period in progress.
      	o	Make force_quiescent_state() avoid going for a global
      		lock in the case where there is no grace period in
      	o	Rearrange struct fields to improve struct layout.
      	o	Make call_rcu() initiate a grace period if RCU was
      		idle, rather than waiting for the next scheduling
      		clock interrupt.
      	o	Invoke rcu_irq_enter() and rcu_irq_exit() only when
      		idle, as suggested by Andi Kleen.  I still don't
      		completely trust this change, and might back it out.
      	o	Make CONFIG_RCU_TRACE be the single config variable
      		manipulated for all forms of RCU, instead of the prior
      	o	Document tracing files and formats for both rcupreempt
      		and rcutree.
      Updates from v4 for those missing v5 given its bad subject line:
      o	Separated dynticks interface so that NMIs and irqs call separate
      	functions, greatly simplifying it.  In particular, this code
      	no longer requires a proof of correctness.  ;-)
      o	Separated dynticks state out into its own per-CPU structure,
      	avoiding the duplicated accounting.
      o	The case where a dynticks-idle CPU runs an irq handler that
      	invokes call_rcu() is now correctly handled, forcing that CPU
      	out of dynticks-idle mode.
      o	Review comments have been applied (thank you all!!!).
      	For but one example, fixed the dynticks-ordering issue that
      	Manfred pointed out, saving me much debugging.  ;-)
      o	Adjusted rcuclassic and rcupreempt to handle dynticks changes.
      Attached is an updated patch to Classic RCU that applies a hierarchy,
      greatly reducing the contention on the top-level lock for large machines.
      This passes 10-hour concurrent rcutorture and online-offline testing on
      128-CPU ppc64 without dynticks enabled, and exposes some timekeeping
      bugs in presence of dynticks (exciting working on a system where
      "sleep 1" hangs until interrupted...), which were fixed in the
      2.6.27 kernel.  It is getting more reliable than mainline by some
      measures, so the next version will be against -tip for inclusion.
      See also Manfred Spraul's recent patches (or his earlier work from
      2004 at http://marc.info/?l=linux-kernel&m=108546384711797&w=2).
      We will converge onto a common patch in the fullness of time, but are
      currently exploring different regions of the design space.  That said,
      I have already gratefully stolen quite a few of Manfred's ideas.
      This patch provides CONFIG_RCU_FANOUT, which controls the bushiness
      of the RCU hierarchy.  Defaults to 32 on 32-bit machines and 64 on
      64-bit machines.  If CONFIG_NR_CPUS is less than CONFIG_RCU_FANOUT,
      there is no hierarchy.  By default, the RCU initialization code will
      adjust CONFIG_RCU_FANOUT to balance the hierarchy, so strongly NUMA
      architectures may choose to set CONFIG_RCU_FANOUT_EXACT to disable
      this balancing, allowing the hierarchy to be exactly aligned to the
      underlying hardware.  Up to two levels of hierarchy are permitted
      (in addition to the root node), allowing up to 16,384 CPUs on 32-bit
      systems and up to 262,144 CPUs on 64-bit systems.  I just know that I
      am going to regret saying this, but this seems more than sufficient
      for the foreseeable future.  (Some architectures might wish to set
      CONFIG_RCU_FANOUT=4, which would limit such architectures to 64 CPUs.
      If this becomes a real problem, additional levels can be added, but I
      doubt that it will make a significant difference on real hardware.)
      In the common case, a given CPU will manipulate its private rcu_data
      structure and the rcu_node structure that it shares with its immediate
      neighbors.  This can reduce both lock and memory contention by multiple
      orders of magnitude, which should eliminate the need for the strange
      manipulations that are reported to be required when running Linux on
      very large systems.
      Some shortcomings:
      o	More bugs will probably surface as a result of an ongoing
      	line-by-line code inspection.
      	Patches will be provided as required.
      o	There are probably hangs, rcutorture failures, &c.  Seems
      	quite stable on a 128-CPU machine, but that is kind of small
      	compared to 4096 CPUs.  However, seems to do better than
      	Patches will be provided as required.
      o	The memory footprint of this version is several KB larger
      	than rcuclassic.
      	A separate UP-only rcutiny patch will be provided, which will
      	reduce the memory footprint significantly, even compared
      	to the old rcuclassic.  One such patch passes light testing,
      	and has a memory footprint smaller even than rcuclassic.
      	Initial reaction from various embedded guys was "it is not
      	worth it", so am putting it aside.
      o	Manfred Spraul for ideas, review comments, and bugs spotted,
      	as well as some good friendly competition.  ;-)
      o	Josh Triplett, Ingo Molnar, Peter Zijlstra, Mathieu Desnoyers,
      	Lai Jiangshan, Andi Kleen, Andy Whitcroft, and Andrew Morton
      	for reviews and comments.
      o	Thomas Gleixner for much-needed help with some timer issues
      	(see patches below).
      o	Jon M. Tollefson, Tim Pepper, Andrew Theurer, Jose R. Santos,
      	Andy Whitcroft, Darrick Wong, Nishanth Aravamudan, Anton
      	Blanchard, Dave Kleikamp, and Nathan Lynch for keeping machines
      	alive despite my heavy abuse^Wtesting.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  20. 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
  21. 08 Dec, 2008 1 commit
    • Yinghai Lu's avatar
      sparse irq_desc[] array: core kernel and x86 changes · 0b8f1efa
      Yinghai Lu authored
      Impact: new feature
      Problem on distro kernels: irq_desc[NR_IRQS] takes megabytes of RAM with
      NR_CPUS set to large values. The goal is to be able to scale up to much
      larger NR_IRQS value without impacting the (important) common case.
      To solve this, we generalize irq_desc[NR_IRQS] to an (optional) array of
      irq_desc pointers.
      When CONFIG_SPARSE_IRQ=y is used, we use kzalloc_node to get irq_desc,
      this also makes the IRQ descriptors NUMA-local (to the site that calls
      This gets rid of the irq_cfg[] static array on x86 as well: irq_cfg now
      uses desc->chip_data for x86 to store irq_cfg.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  22. 23 Nov, 2008 1 commit
  23. 16 Nov, 2008 1 commit
  24. 13 Nov, 2008 3 commits
    • David Howells's avatar
      CRED: Inaugurate COW credentials · d84f4f99
      David Howells authored
      Inaugurate copy-on-write credentials management.  This uses RCU to manage the
      credentials pointer in the task_struct with respect to accesses by other tasks.
      A process may only modify its own credentials, and so does not need locking to
      access or modify its own credentials.
      A mutex (cred_replace_mutex) is added to the task_struct to control the effect
      of PTRACE_ATTACHED on credential calculations, particularly with respect to
      With this patch, the contents of an active credentials struct may not be
      changed directly; rather a new set of credentials must be prepared, modified
      and committed using something like the following sequence of events:
      	struct cred *new = prepare_creds();
      	int ret = blah(new);
      	if (ret < 0) {
      		return ret;
      	return commit_creds(new);
      There are some exceptions to this rule: the keyrings pointed to by the active
      credentials may be instantiated - keyrings violate the COW rule as managing
      COW keyrings is tricky, given that it is possible for a task to directly alter
      the keys in a keyring in use by another task.
      To help enforce this, various pointers to sets of credentials, such as those in
      the task_struct, are declared const.  The purpose of this is compile-time
      discouragement of altering credentials through those pointers.  Once a set of
      credentials has been made public through one of these pointers, it may not be
      modified, except under special circumstances:
        (1) Its reference count may incremented and decremented.
        (2) The keyrings to which it points may be modified, but not replaced.
      The only safe way to modify anything else is to create a replacement and commit
      using the functions described in Documentation/credentials.txt (which will be
      added by a later patch).
      This patch and the preceding patches have been tested with the LTP SELinux
      This patch makes several logical sets of alteration:
       (1) execve().
           This now prepares and commits credentials in various places in the
           security code rather than altering the current creds directly.
       (2) Temporary credential overrides.
           do_coredump() and sys_faccessat() now prepare their own credentials and
           temporarily override the ones currently on the acting thread, whilst
           preventing interference from other threads by holding cred_replace_mutex
           on the thread being dumped.
           This will be replaced in a future patch by something that hands down the
           credentials directly to the functions being called, rather than altering
           the task's objective credentials.
       (3) LSM interface.
           A number of functions have been changed, added or removed:
           (*) security_capset_check(), ->capset_check()
           (*) security_capset_set(), ->capset_set()
           	 Removed in favour of security_capset().
           (*) security_capset(), ->capset()
           	 New.  This is passed a pointer to the new creds, a pointer to the old
           	 creds and the proposed capability sets.  It should fill in the new
           	 creds or return an error.  All pointers, barring the pointer to the
           	 new creds, are now const.
           (*) security_bprm_apply_creds(), ->bprm_apply_creds()
           	 Changed; now returns a value, which will cause the process to be
           	 killed if it's an error.
           (*) security_task_alloc(), ->task_alloc_security()
           	 Removed in favour of security_prepare_creds().
           (*) security_cred_free(), ->cred_free()
           	 New.  Free security data attached to cred->security.
           (*) security_prepare_creds(), ->cred_prepare()
           	 New. Duplicate any security data attached to cred->security.
           (*) security_commit_creds(), ->cred_commit()
           	 New. Apply any security effects for the upcoming installation of new
           	 security by commit_creds().
           (*) security_task_post_setuid(), ->task_post_setuid()
           	 Removed in favour of security_task_fix_setuid().
           (*) security_task_fix_setuid(), ->task_fix_setuid()
           	 Fix up the proposed new credentials for setuid().  This is used by
           	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
           	 setuid() changes.  Changes are made to the new credentials, rather
           	 than the task itself as in security_task_post_setuid().
           (*) security_task_reparent_to_init(), ->task_reparent_to_init()
           	 Removed.  Instead the task being reparented to init is referred
           	 directly to init's credentials.
      	 NOTE!  This results in the loss of some state: SELinux's osid no
      	 longer records the sid of the thread that forked it.
           (*) security_key_alloc(), ->key_alloc()
           (*) security_key_permission(), ->key_permission()
           	 Changed.  These now take cred pointers rather than task pointers to
           	 refer to the security context.
       (4) sys_capset().
           This has been simplified and uses less locking.  The LSM functions it
           calls have been merged.
       (5) reparent_to_kthreadd().
           This gives the current thread the same credentials as init by simply using
           commit_thread() to point that way.
       (6) __sigqueue_alloc() and switch_uid()
           __sigqueue_alloc() can't stop the target task from changing its creds
           beneath it, so this function gets a reference to the currently applicable
           user_struct which it then passes into the sigqueue struct it returns if
           switch_uid() is now called from commit_creds(), and possibly should be
           folded into that.  commit_creds() should take care of protecting
       (7) [sg]et[ug]id() and co and [sg]et_current_groups.
           The set functions now all use prepare_creds(), commit_creds() and
           abort_creds() to build and check a new set of credentials before applying
           security_task_set[ug]id() is called inside the prepared section.  This
           guarantees that nothing else will affect the creds until we've finished.
           The calling of set_dumpable() has been moved into commit_creds().
           Much of the functionality of set_user() has been moved into
           The get functions all simply access the data directly.
       (8) security_task_prctl() and cap_task_prctl().
           security_task_prctl() has been modified to return -ENOSYS if it doesn't
           want to handle a function, or otherwise return the return value directly
           rather than through an argument.
           Additionally, cap_task_prctl() now prepares a new set of credentials, even
           if it doesn't end up using it.
       (9) Keyrings.
           A number of changes have been made to the keyrings code:
           (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
           	 all been dropped and built in to the credentials functions directly.
           	 They may want separating out again later.
           (b) key_alloc() and search_process_keyrings() now take a cred pointer
           	 rather than a task pointer to specify the security context.
           (c) copy_creds() gives a new thread within the same thread group a new
           	 thread keyring if its parent had one, otherwise it discards the thread
           (d) The authorisation key now points directly to the credentials to extend
           	 the search into rather pointing to the task that carries them.
           (e) Installing thread, process or session keyrings causes a new set of
           	 credentials to be created, even though it's not strictly necessary for
           	 process or session keyrings (they're shared).
      (10) Usermode helper.
           The usermode helper code now carries a cred struct pointer in its
           subprocess_info struct instead of a new session keyring pointer.  This set
           of credentials is derived from init_cred and installed on the new process
           after it has been cloned.
           call_usermodehelper_setup() allocates the new credentials and
           call_usermodehelper_freeinfo() discards them if they haven't been used.  A
           special cred function (prepare_usermodeinfo_creds()) is provided
           specifically for call_usermodehelper_setup() to call.
           call_usermodehelper_setkeys() adjusts the credentials to sport the
           supplied keyring as the new session keyring.
      (11) SELinux.
           SELinux has a number of changes, in addition to those to support the LSM
           interface changes mentioned above:
           (a) selinux_setprocattr() no longer does its check for whether the
           	 current ptracer can access processes with the new SID inside the lock
           	 that covers getting the ptracer's SID.  Whilst this lock ensures that
           	 the check is done with the ptracer pinned, the result is only valid
           	 until the lock is released, so there's no point doing it inside the
      (12) is_single_threaded().
           This function has been extracted from selinux_setprocattr() and put into
           a file of its own in the lib/ directory as join_session_keyring() now
           wants to use it too.
           The code in SELinux just checked to see whether a task shared mm_structs
           with other tasks (CLONE_VM), but that isn't good enough.  We really want
           to know if they're part of the same thread group (CLONE_THREAD).
      (13) nfsd.
           The NFS server daemon now has to use the COW credentials to set the
           credentials it is going to use.  It really needs to pass the credentials
           down to the functions it calls, but it can't do that until other patches
           in this series have been applied.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • Simon Arlott's avatar
      Kconfig: SLUB is the default slab allocator · 02f56210
      Simon Arlott authored
      In 2007, a0acd820 changed the default
      slab allocator to SLUB, but the SLAB help text still says SLAB is the
      default. This change fixes that.
      Signed-off-by: default avatarSimon Arlott <simon@fire.lp0.eu>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
    • Adrian Knoth's avatar
      sched: correct sched-rt-group.txt pathname in init/Kconfig · 2fe401e3
      Adrian Knoth authored
      init/Kconfig directs the user to Documentation/sched-rt-group.txt, but
      the file is actually in Documentation/scheduler/sched-rt-group.txt.
      This patch corrects the pathname mentioned in init/Kconfig.
      Signed-off-by: default avatarAdrian Knoth <adi@drcomp.erfurt.thur.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>