1. 23 Mar, 2006 1 commit
  2. 08 Feb, 2006 1 commit
  3. 12 Jan, 2006 2 commits
  4. 09 Jan, 2006 5 commits
    • Oleg Nesterov's avatar
      [PATCH] simplify k_getrusage() · 0f59cc4a
      Oleg Nesterov authored
      Factor out common code for different RUSAGE_xxx cases.
      Don't take ->sighand->siglock in RUSAGE_SELF case, suggested by Ravikiran G
      Thirumalai <kiran@scalex86.org>.
      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>
    • Oleg Nesterov's avatar
      [PATCH] setpgid: should not accept ptraced childs · f7dd795e
      Oleg Nesterov authored
      sys_setpgid() allows to change ->pgrp of ptraced childs.
      'man setpgid' does not tell anything about that, so I consider
      this behaviour is a bug.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Oren Laadan <orenl@cs.columbia.edu>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Oren Laadan's avatar
      [PATCH] setpgid: should work for sub-threads · e19f247a
      Oren Laadan authored
      setsid() does not work unless the calling process is a
      'man setpgid' does not tell anything about that, so I consider this
      behaviour is a bug.
      Signed-off-by: default avatarOren Laadan <orenl@cs.columbia.edu>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Oleg Nesterov's avatar
      [PATCH] setpgid: should work for sub-threads · ee0acf90
      Oleg Nesterov authored
      setpgid(0, pgid) or setpgid(forked_child_pid, pgid) does not work unless
      the calling process is a thread_group_leader().
      'man setpgid' does not tell anything about that, so I consider this
      behaviour is a bug.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Oren Laadan <orenl@cs.columbia.edu>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Eric W. Biederman's avatar
      [PATCH] Don't attempt to power off if power off is not implemented · 5e38291d
      Eric W. Biederman authored
      The problem.  It is expected that /sbin/halt -p works exactly like
      /sbin/halt, when the kernel does not implement power off functionality.
      The kernel can do a lot of work in the reboot notifiers and in
      device_shutdown before we even get to machine_power_off.  Some of that
      shutdown is not safe if you are leaving the power on, and it definitely
      gets in the way of using sysrq or pressing ctrl-alt-del.  Since the
      shutdown happens in generic code there is no way to fix this in
      architecture specific code :(
      Some machines are kernel oopsing today because of this.
      The simple solution is to turn LINUX_REBOOT_CMD_POWER_OFF into
      LINUX_REBOOT_CMD_HALT if power_off functionality is not implemented.
      This has the unfortunate side effect of disabling the power off
      functionality on architectures that leave pm_power_off to null and still
      implement something in machine_power_off.  And it will break the build on
      some architectures that don't have a pm_power_off variable at all.
      On both counts I say tough.
      For architectures like alpha that don't implement the pm_power_off variable
      pm_power_off is declared in linux/pm.h and it is a generic part of our
      power management code, and all architectures should implement it.
      For architectures like parisc that have a default power off method in
      machine_power_off if pm_power_off is not implemented or fails.  It is easy
      enough to set the pm_power_off variable.  And nothing bad happens there,
      the machines just stop powering off.
      The current semantics are impossible without a flag at the top level so we
      can avoid the problem code if a power off is not implemented.  pm_power_off
      is as good a flag as any with the bonus that it works without modification
      on at least x86, x86_64, powerpc, and ppc today.
      Andrew can you pick this up and put this in the mm tree.  Kernels that
      don't compile or don't power off seem saner than kernels that oops or
      panic.  Until we get the arch specific patches for the problem
      architectures this probably isn't smart to push into the stable kernel.
      Unfortunately I don't have the time at the moment to walk through every
      architecture and make them work.  And even if I did I couldn't test it :(
      From: Hirokazu Takata <takata@linux-m32r.org>
          Add pm_power_off() for build fix of arch/m32r/kernel/process.c.
      From: Miklos Szeredi <miklos@szeredi.hu>
          UML build fix
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarHayato Fujiwara <fujiwara@linux-m32r.org>
      Signed-off-by: default avatarHirokazu Takata <takata@linux-m32r.org>
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  5. 15 Dec, 2005 1 commit
  6. 12 Dec, 2005 1 commit
  7. 10 Nov, 2005 1 commit
  8. 07 Nov, 2005 4 commits
  9. 23 Sep, 2005 1 commit
  10. 17 Sep, 2005 1 commit
  11. 07 Sep, 2005 1 commit
    • Jesper Juhl's avatar
      [PATCH] remove a redundant variable in sys_prctl() · 0730ded5
      Jesper Juhl authored
      The patch removes a redundant variable `sig' from sys_prctl().
      For some reason, when sys_prctl is called with option == PR_SET_PDEATHSIG
      then the value of arg2 is assigned to an int variable named sig.  Then sig
      is tested with valid_signal() and later used to set the value of
      current->pdeath_signal .
      There is no reason to use this intermediate variable since valid_signal()
      takes a unsigned long argument, so it can handle being passed arg2
      directly, and if the call to valid_signal is OK, then we know the value of
      arg2 is in the range zero to _NSIG and thus it'll easily fit in a plain int
      and thus there's no problem assigning it later to current->pdeath_signal
      (which is an int).
      The patch gets rid of the pointless variable `sig'.
      This reduces the size of kernel/sys.o in 2.6.13-rc6-mm1 by 32 bytes on my
      Patch has been compile tested, boot tested, and just to make damn sure I
      didn't break anything I wrote a quick test app that calls
      prctl(PR_SET_PDEATHSIG ...) with the entire range of values for a
      unsigned long, and it behaves as expected with and without the patch.
      Signed-off-by: default avatarJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  12. 04 Aug, 2005 1 commit
    • Benjamin Herrenschmidt's avatar
      [PATCH] Remove suspend() calls from shutdown path · c36f19e0
      Benjamin Herrenschmidt authored
      This removes the calls to device_suspend() from the shutdown path that
      were added sometime during 2.6.13-rc*.  They aren't working properly on
      a number of configs (I got reports from both ppc powerbook users and x86
      users) causing the system to not shutdown anymore.
      I think it isn't the right approach at the moment anyway.  We have
      already a shutdown() callback for the drivers that actually care about
      shutdown and the suspend() code isn't yet in a good enough shape to be
      so much generalized.  Also, the semantics of suspend and shutdown are
      slightly different on a number of setups and the way this was patched in
      provides little way for drivers to cleanly differenciate.  It should
      have been at least a different message.
      For 2.6.13, I think we should revert to 2.6.12 behaviour and have a
      working suspend back.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  13. 29 Jul, 2005 1 commit
  14. 27 Jul, 2005 1 commit
  15. 26 Jul, 2005 4 commits
  16. 25 Jun, 2005 2 commits
  17. 24 Jun, 2005 1 commit
    • David Howells's avatar
      [PATCH] Keys: Make request-key create an authorisation key · 3e30148c
      David Howells authored
      The attached patch makes the following changes:
       (1) There's a new special key type called ".request_key_auth".
           This is an authorisation key for when one process requests a key and
           another process is started to construct it. This type of key cannot be
           created by the user; nor can it be requested by kernel services.
           Authorisation keys hold two references:
           (a) Each refers to a key being constructed. When the key being
           	 constructed is instantiated the authorisation key is revoked,
           	 rendering it of no further use.
           (b) The "authorising process". This is either:
           	 (i) the process that called request_key(), or:
           	 (ii) if the process that called request_key() itself had an
           	      authorisation key in its session keyring, then the authorising
           	      process referred to by that authorisation key will also be
           	      referred to by the new authorisation key.
      	 This means that the process that initiated a chain of key requests
      	 will authorise the lot of them, and will, by default, wind up with
      	 the keys obtained from them in its keyrings.
       (2) request_key() creates an authorisation key which is then passed to
           /sbin/request-key in as part of a new session keyring.
       (3) When request_key() is searching for a key to hand back to the caller, if
           it comes across an authorisation key in the session keyring of the
           calling process, it will also search the keyrings of the process
           specified therein and it will use the specified process's credentials
           (fsuid, fsgid, groups) to do that rather than the calling process's
           This allows a process started by /sbin/request-key to find keys belonging
           to the authorising process.
       (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
           direct read or search permission if that key is contained within the
           keyrings of a process specified by an authorisation key found within the
           calling process's session keyring, and is searchable using the
           credentials of the authorising process.
           This allows a process started by /sbin/request-key to read keys belonging
           to the authorising process.
       (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
           KEYCTL_NEGATE will specify a keyring of the authorising process, rather
           than the process doing the instantiation.
       (6) One of the process keyrings can be nominated as the default to which
           request_key() should attach new keys if not otherwise specified. This is
           done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
           constants. The current setting can also be read using this call.
       (7) request_key() is partially interruptible. If it is waiting for another
           process to finish constructing a key, it can be interrupted. This permits
           a request-key cycle to be broken without recourse to rebooting.
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-Off-By: default avatarBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  18. 23 Jun, 2005 2 commits
    • Christoph Lameter's avatar
      [PATCH] Optimize sys_times for a single thread process · 71a2224d
      Christoph Lameter authored
      Avoid taking the tasklist_lock in sys_times if the process is single
      threaded.  In a NUMA system taking the tasklist_lock may cause a bouncing
      cacheline if multiple independent processes continually call sys_times to
      measure their performance.
      Signed-off-by: default avatarChristoph Lameter <christoph@lameter.com>
      Signed-off-by: default avatarShai Fultheim <shai@scalex86.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Alan Cox's avatar
      [PATCH] setuid core dump · d6e71144
      Alan Cox authored
      Add a new `suid_dumpable' sysctl:
      This value can be used to query and set the core dump mode for setuid
      or otherwise protected/tainted binaries. The modes are
      0 - (default) - traditional behaviour.  Any process which has changed
          privilege levels or is execute only will not be dumped
      1 - (debug) - all processes dump core when possible.  The core dump is
          owned by the current user and no security is applied.  This is intended
          for system debugging situations only.  Ptrace is unchecked.
      2 - (suidsafe) - any binary which normally would not be dumped is dumped
          readable by root only.  This allows the end user to remove such a dump but
          not access it directly.  For security reasons core dumps in this mode will
          not overwrite one another or other files.  This mode is appropriate when
          adminstrators are attempting to debug problems in a normal environment.
      > > +EXPORT_SYMBOL(suid_dumpable);
      No problem to me.
      > >  	if (current->euid == current->uid && current->egid == current->gid)
      > >  		current->mm->dumpable = 1;
      > Should this be SUID_DUMP_USER?
      Actually the feedback I had from last time was that the SUID_ defines
      should go because its clearer to follow the numbers. They can go
      everywhere (and there are lots of places where dumpable is tested/used
      as a bool in untouched code)
      > Maybe this should be renamed to `dump_policy' or something.  Doing that
      > would help us catch any code which isn't using the #defines, too.
      Fair comment. The patch was designed to be easy to maintain for Red Hat
      rather than for merging. Changing that field would create a gigantic
      diff because it is used all over the place.
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  19. 05 May, 2005 1 commit
  20. 01 May, 2005 3 commits
  21. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!