1. 17 Nov, 2007 1 commit
  2. 19 Oct, 2007 5 commits
    • Pavel Emelyanov's avatar
      Isolate the explicit usage of signal->pgrp · 9a2e7057
      Pavel Emelyanov authored
      The pgrp field is not used widely around the kernel so it is now marked as
      deprecated with appropriate comment.
      
      The initialization of INIT_SIGNALS is trimmed because
      a) they are set to 0 automatically;
      b) gcc cannot properly initialize two anonymous (the second one
         is the one with the session) unions. In this particular case
         to make it compile we'd have to add some field initialized
         right before the .pgrp.
      
      This is the same patch as the 1ec320af
      
       one
      (from Cedric), but for the pgrp field.
      
      Some progress report:
      
      We have to deprecate the pid, tgid, session and pgrp fields on struct
      task_struct and struct signal_struct.  The session and pgrp are already
      deprecated.  The tgid value is close to being such - the worst known usage
      in in fs/locks.c and audit code.  The pid field deprecation is mainly
      blocked by numerous printk-s around the kernel that print the tsk->pid to
      log.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9a2e7057
    • Pavel Emelyanov's avatar
      Uninline find_task_by_xxx set of functions · 228ebcbe
      Pavel Emelyanov authored
      
      The find_task_by_something is a set of macros are used to find task by pid
      depending on what kind of pid is proposed - global or virtual one.  All of
      them are wrappers above the most generic one - find_task_by_pid_type_ns() -
      and just substitute some args for it.
      
      It turned out, that dereferencing the current->nsproxy->pid_ns construction
      and pushing one more argument on the stack inline cause kernel text size to
      grow.
      
      This patch moves all this stuff out-of-line into kernel/pid.c.  Together
      with the next patch it saves a bit less than 400 bytes from the .text
      section.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Paul Menage <menage@google.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      228ebcbe
    • Pavel Emelyanov's avatar
      pid namespaces: changes to show virtual ids to user · b488893a
      Pavel Emelyanov authored
      This is the largest patch in the set. Make all (I hope) the places where
      the pid is shown to or get from user operate on the virtual pids.
      
      The idea is:
       - all in-kernel data structures must store either struct pid itself
         or the pid's global nr, obtained with pid_nr() call;
       - when seeking the task from kernel code with the stored id one
         should use find_task_by_pid() call that works with global pids;
       - when showing pid's numerical value to the user the virtual one
         should be used, but however when one shows task's pid outside this
         task's namespace the global one is to be used;
       - when getting the pid from userspace one need to consider this as
         the virtual one and use appropriate task/pid-searching functions.
      
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: nuther build fix]
      [akpm@linux-foundation.org: yet nuther build fix]
      [akpm@linux-foundation.org: remove unneeded casts]
      Signed-off-by: Pavel Emelyanov <xemul@openvz.org...
      b488893a
    • Pavel Emelianov's avatar
      pid namespaces: round up the API · a47afb0f
      Pavel Emelianov authored
      
      The set of functions process_session, task_session, process_group and
      task_pgrp is confusing, as the names can be mixed with each other when looking
      at the code for a long time.
      
      The proposals are to
      * equip the functions that return the integer with _nr suffix to
        represent that fact,
      * and to make all functions work with task (not process) by making
        the common prefix of the same name.
      
      For monotony the routines signal_session() and set_signal_session() are
      replaced with task_session_nr() and set_task_session(), especially since they
      are only used with the explicit task->signal dereference.
      Signed-off-by: default avatarPavel Emelianov <xemul@openvz.org>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus T...
      a47afb0f
    • Alexey Dobriyan's avatar
      Add kernel/notifier.c · fe9d4f57
      Alexey Dobriyan authored
      
      There is separate notifier header, but no separate notifier .c file.
      
      Extract notifier code out of kernel/sys.c which will remain for
      misc syscalls I hope. Merge kernel/die_notifier.c into kernel/notifier.c.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@sw.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fe9d4f57
  3. 18 Oct, 2007 1 commit
  4. 01 Oct, 2007 1 commit
  5. 31 Aug, 2007 1 commit
  6. 29 Jul, 2007 1 commit
  7. 26 Jul, 2007 1 commit
  8. 19 Jul, 2007 2 commits
  9. 18 Jul, 2007 2 commits
    • Jeremy Fitzhardinge's avatar
      usermodehelper: Tidy up waiting · 86313c48
      Jeremy Fitzhardinge authored
      
      Rather than using a tri-state integer for the wait flag in
      call_usermodehelper_exec, define a proper enum, and use that.  I've
      preserved the integer values so that any callers I've missed should
      still work OK.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Joel Becker <joel.becker@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: David Howells <dhowells@redhat.com>
      86313c48
    • Jeremy Fitzhardinge's avatar
      Add common orderly_poweroff() · 10a0a8d4
      Jeremy Fitzhardinge authored
      
      Various pieces of code around the kernel want to be able to trigger an
      orderly poweroff.  This pulls them together into a single
      implementation.
      
      By default the poweroff command is /sbin/poweroff, but it can be set
      via sysctl: kernel/poweroff_cmd.  This is split at whitespace, so it
      can include command-line arguments.
      
      This patch replaces four other instances of invoking either "poweroff"
      or "shutdown -h now": two sbus drivers, and acpi thermal
      management.
      
      sparc64 has its own "powerd"; still need to determine whether it should
      be replaced by orderly_poweroff().
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
      Acked-by: default avatarLen Brown <lenb@kernel.org>
      Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David S. Miller <davem@davemloft.net>
      10a0a8d4
  10. 16 Jul, 2007 2 commits
  11. 11 May, 2007 3 commits
  12. 09 May, 2007 3 commits
    • Gautham R Shenoy's avatar
      Extend notifier_call_chain to count nr_calls made · 6f7cc11a
      Gautham R Shenoy authored
      Since 2.6.18-something, the community has been bugged by the problem to
      provide a clean and a stable mechanism to postpone a cpu-hotplug event as
      lock_cpu_hotplug was badly broken.
      
      This is another proposal towards solving that problem.  This one is along the
      lines of the solution provided in kernel/workqueue.c
      
      Instead of having a global mechanism like lock_cpu_hotplug, we allow the
      subsytems to define their own per-subsystem hot cpu mutexes.  These would be
      taken(released) where ever we are currently calling
      lock_cpu_hotplug(unlock_cpu_hotplug).
      
      Also, in the per-subsystem hotcpu callback function,we take this mutex before
      we handle any pre-cpu-hotplug events and release it once we finish handling
      the post-cpu-hotplug events.  A standard means for doing this has been
      provided in [PATCH 2/4] and demonstrated in [PATCH 3/4].
      
      The ordering of these per-subsystem mutexes might still prove to be a
      problem, but hopefully lockdep should help us get out of that muddle.
      
      The patch set to be applied against linux-2.6.19-rc5 is as follows:
      
      [PATCH 1/4] :	Extend notifier_call_chain with an option to specify the
      		number of notifications to be sent and also count the
      		number of notifications actually sent.
      
      [PATCH 2/4] :	Define events CPU_LOCK_ACQUIRE and CPU_LOCK_RELEASE
      		and send out notifications for these in _cpu_up and
      		_cpu_down. This would help us standardise the acquire and
      		release of the subsystem locks in the hotcpu
      		callback functions of these subsystems.
      
      [PATCH 3/4] :	Eliminate lock_cpu_hotplug from kernel/sched.c.
      
      [PATCH 4/4] :	In workqueue_cpu_callback function, acquire(release) the
      		workqueue_mutex while handling
      		CPU_LOCK_ACQUIRE(CPU_LOCK_RELEASE).
      
      If the per-subsystem-locking approach survives the test of time, we can expect
      a slow phasing out of lock_cpu_hotplug, which has not yet been eliminated in
      these patches :)
      
      This patch:
      
      Provide notifier_call_chain with an option to call only a specified number of
      notifiers and also record the number of call to notifiers made.
      
      The need for this enhancement was identified in the post entitled
      "Slab - Eliminate lock_cpu_hotplug from slab"
      (http://lkml.org/lkml/2006/10/28/92
      
      ) by Ravikiran G Thirumalai and
      Andrew Morton.
      
      This patch adds two additional parameters to notifier_call_chain API namely
       - int nr_to_calls : Number of notifier_functions to be called.
       		     The don't care value is -1.
      
       - unsigned int *nr_calls : Records the total number of notifier_funtions
      			    called by notifier_call_chain. The don't care
      			    value is NULL.
      
      [michal.k.k.piotrowski@gmail.com: build fix]
      Credit: Andrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: default avatarMichal Piotrowski <michal.k.k.piotrowski@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6f7cc11a
    • Rafael J. Wysocki's avatar
      PM: Separate hibernation code from suspend code · a3d25c27
      Rafael J. Wysocki authored
      
      [ With Johannes Berg <johannes@sipsolutions.net> ]
      
      Separate the hibernation (aka suspend to disk code) from the other suspend
      code.  In particular:
      
       * Remove the definitions related to hibernation from include/linux/pm.h
       * Introduce struct hibernation_ops and a new hibernate() function to hibernate
         the system, defined in include/linux/suspend.h
       * Separate suspend code in kernel/power/main.c from hibernation-related code
         in kernel/power/disk.c and kernel/power/user.c (with the help of
         hibernation_ops)
       * Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_ops
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Cc: Greg KH <greg@kroah.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a3d25c27
    • John Anthony Kazos Jr's avatar
      general: convert "kernel" subdirectory to UTF-8 · f42df9e6
      John Anthony Kazos Jr authored
      
      Convert the "kernel" subdirectory of the tree to UTF-8. The only file
      modified is <kernel/sys.c>.
      Signed-off-by: default avatarJohn Anthony Kazos Jr. <jakj@j-a-k-j.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      f42df9e6
  13. 08 May, 2007 1 commit
    • Tom Alsberg's avatar
      CPU time limit patch / setrlimit(RLIMIT_CPU, 0) cheat fix · 9926e4c7
      Tom Alsberg authored
      
      As discovered here today, the change in Kernel 2.6.17 intended to inhibit
      users from setting RLIMIT_CPU to 0 (as that is equivalent to unlimited) by
      "cheating" and setting it to 1 in such a case, does not make a difference,
      as the check is done in the wrong place (too late), and only applies to the
      profiling code.
      
      On all systems I checked running kernels above 2.6.17, no matter what the
      hard and soft CPU time limits were before, a user could escape them by
      issuing in the shell (sh/bash/zsh) "ulimit -t 0", and then the user's
      process was not ever killed.
      
      Attached is a trivial patch to fix that.  Simply moving the check to a
      slightly earlier location (specifically, before the line that actually
      assigns the limit - *old_rlim = new_rlim), does the trick.
      
      Do note that at least the zsh (but not ash, dash, or bash) shell has the
      problem of "caching" the limits set by the ulimit command, so when running
      zsh the fix will not immediately be evident - after entering "ulimit -t 0",
      "ulimit -a" will show "-t: cpu time (seconds) 0", even though the actual
      limit as returned by getrlimit(...) will be 1.  It can be verified by
      opening a subshell (which will not have the values of the parent shell in
      cache) and checking in it, or just by running a CPU intensive command like
      "echo '65536^1048576' | bc" and verifying that it dumps core after one
      second.
      
      Regardless of whether that is a misfeature in the shell, perhaps it would
      be better to return -EINVAL from setrlimit in such a case instead of
      cheating and setting to 1, as that does not really reflect the actual state
      of the process anymore.  I do not however know what the ground for that
      decision was in the original 2.6.17 change, and whether there would be any
      "backward" compatibility issues, so I preferred not to touch that right
      now.
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9926e4c7
  14. 07 May, 2007 1 commit
  15. 12 Feb, 2007 2 commits
  16. 11 Feb, 2007 1 commit
  17. 23 Jan, 2007 1 commit
    • Ingo Molnar's avatar
      [PATCH] notifiers: fix blocking_notifier_call_chain() scalability · 1b5180b6
      Ingo Molnar authored
      
      while lock-profiling the -rt kernel i noticed weird contention during
      mmap-intense workloads, and the tracer showed the following gem, in one
      of our MM hotpaths:
      
       threaded-2771  1....   65us : sys_munmap (sysenter_do_call)
       threaded-2771  1....   66us : profile_munmap (sys_munmap)
       threaded-2771  1....   66us : blocking_notifier_call_chain (profile_munmap)
       threaded-2771  1....   66us : rt_down_read (blocking_notifier_call_chain)
      
      ouch! a global rw-semaphore taken in one of the most performance-
      sensitive codepaths of the kernel.  And i dont even have oprofile
      enabled! All distro kernels have CONFIG_PROFILING enabled, so this
      scalability problem affects the majority of Linux users.
      
      The fix is to enhance blocking_notifier_call_chain() to only take the
      lock if there appears to be work on the call-chain.
      
      With this patch applied i get nicely saturated system, and much higher
      munmap performance, on SMP systems.
      
      And as a bonus this also fixes a similar scalability bottleneck in the
      thread-exit codepath: profile_task_exit() ...
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1b5180b6
  18. 08 Dec, 2006 3 commits
    • Oleg Nesterov's avatar
      [PATCH] sys_setpgid: eliminate unnecessary do_each_task_pid(PIDTYPE_PGID) · f020bc46
      Oleg Nesterov authored
      
      All tasks in the process group have the same sid, we don't need to iterate
      them all to check that the caller of sys_setpgid() doesn't change its
      session.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f020bc46
    • Cedric Le Goater's avatar
      [PATCH] add process_session() helper routine · 937949d9
      Cedric Le Goater authored
      
      Replace occurences of task->signal->session by a new process_session() helper
      routine.
      
      It will be useful for pid namespaces to abstract the session pid number.
      Signed-off-by: default avatarCedric Le Goater <clg@fr.ibm.com>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      937949d9
    • Peter Zijlstra's avatar
      [PATCH] tty: ->signal->tty locking · 24ec839c
      Peter Zijlstra authored
      Fix the locking of signal->tty.
      
      Use ->sighand->siglock to protect ->signal->tty; this lock is already used
      by most other members of ->signal/->sighand.  And unless we are 'current'
      or the tasklist_lock is held we need ->siglock to access ->signal anyway.
      
      (NOTE: sys_unshare() is broken wrt ->sighand locking rules)
      
      Note that tty_mutex is held over tty destruction, so while holding
      tty_mutex any tty pointer remains valid.  Otherwise the lifetime of ttys
      are governed by their open file handles.  This leaves some holes for tty
      access from signal->tty (or any other non file related tty access).
      
      It solves the tty SLAB scribbles we were seeing.
      
      (NOTE: the change from group_send_sig_info to __group_send_sig_info needs to
             be examined by someone familiar with the security framework, I think
             it is safe given the SEND_SIG_PRIV from other __group_send_sig_info
             invocations)
      
      [schwidefsky@de.ibm.com: 3270 fix]
      [akpm@osdl.org: various post-viro fixes]
      Signed-off...
      24ec839c
  19. 07 Dec, 2006 1 commit
  20. 22 Nov, 2006 1 commit
    • David Howells's avatar
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      David Howells authored
      
      Pass the work_struct pointer to the work function rather than context data.
      The work function can use container_of() to work out the data.
      
      For the cases where the container of the work_struct may go away the moment the
      pending bit is cleared, it is made possible to defer the release of the
      structure by deferring the clearing of the pending bit.
      
      To make this work, an extra flag is introduced into the management side of the
      work_struct.  This governs auto-release of the structure upon execution.
      
      Ordinarily, the work queue executor would release the work_struct for further
      scheduling or deallocation by clearing the pending bit prior to jumping to the
      work function.  This means that, unless the driver makes some guarantee itself
      that the work_struct won't go away, the work function may not access anything
      else in the work_struct or its container lest they be deallocated..  This is a
      problem if the auxiliary data is taken away (as done by the last patch).
      
      However, if the pending bit is *not* cleared before jumping to the work
      function, then the work function *may* access the work_struct and its container
      with no problems.  But then the work function must itself release the
      work_struct by calling work_release().
      
      In most cases, automatic release is fine, so this is the default.  Special
      initiators exist for the non-auto-release case (ending in _NAR).
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      65f27f38
  21. 04 Oct, 2006 2 commits
    • Alan Stern's avatar
      [PATCH] SRCU: report out-of-memory errors · e6a92013
      Alan Stern authored
      
      Currently the init_srcu_struct() routine has no way to report out-of-memory
      errors.  This patch (as761) makes it return -ENOMEM when the per-cpu data
      allocation fails.
      
      The patch also makes srcu_init_notifier_head() report a BUG if a notifier
      head can't be initialized.  Perhaps it should return -ENOMEM instead, but
      in the most likely cases where this might occur I don't think any recovery
      is possible.  Notifier chains generally are not created dynamically.
      
      [akpm@osdl.org: avoid statement-with-side-effect in macro]
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarPaul E. McKenney <paulmck@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e6a92013
    • Alan Stern's avatar
      [PATCH] Add SRCU-based notifier chains · eabc0694
      Alan Stern authored
      
      This patch (as751) adds a new type of notifier chain, based on the SRCU
      (Sleepable Read-Copy Update) primitives recently added to the kernel.  An
      SRCU notifier chain is much like a blocking notifier chain, in that it must
      be called in process context and its callout routines are allowed to sleep.
       The difference is that the chain's links are protected by the SRCU
      mechanism rather than by an rw-semaphore, so calling the chain has
      extremely low overhead: no memory barriers and no cache-line bouncing.  On
      the other hand, unregistering from the chain is expensive and the chain
      head requires special runtime initialization (plus cleanup if it is to be
      deallocated).
      
      SRCU notifiers are appropriate for notifiers that will be called very
      frequently and for which unregistration occurs very seldom.  The proposed
      "task notifier" scheme qualifies, as may some of the network notifiers.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarPaul E. McKenney <paulmck@us.ibm.com>
      Acked-by: default avatarChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      eabc0694
  22. 02 Oct, 2006 3 commits
  23. 01 Oct, 2006 1 commit