1. 25 Jun, 2005 25 commits
  2. 24 Jun, 2005 4 commits
    • Adrian Bunk's avatar
      [PATCH] make various thing static · 52c1da39
      Adrian Bunk authored
      
      
      Another rollup of patches which give various symbols static scope
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      52c1da39
    • Matt Domsch's avatar
      [PATCH] modules: add version and srcversion to sysfs · c988d2b2
      Matt Domsch authored
      
      
      This patch adds version and srcversion files to
      /sys/module/${modulename} containing the version and srcversion fields
      of the module's modinfo section (if present).
      
      /sys/module/e1000
      |-- srcversion
      `-- version
      
      This patch differs slightly from the version posted in January, as it
      now uses the new kstrdup() call in -mm.
      
      Why put this in sysfs?
      
      a) Tools like DKMS, which deal with changing out individual kernel
         modules without replacing the whole kernel, can behave smarter if they
         can tell the version of a given module.  The autoinstaller feature, for
         example, which determines if your system has a "good" version of a
         driver (i.e.  if the one provided by DKMS has a newer verson than that
         provided by the kernel package installed), and to automatically compile
         and install a newer version if DKMS has it but your kernel doesn't yet
         have that version.
      
      b) Because sysadmins manually, or with tools like DKMS, can switch out
         modules on the file system, you can't count on 'modinfo foo.ko', which
         looks at /lib/modules/${kernelver}/...  actually matching what is loaded
         into the kernel already.  Hence asking sysfs for this.
      
      c) as the unbind-driver-from-device work takes shape, it will be
         possible to rebind a driver that's built-in (no .ko to modinfo for the
         version) to a newly loaded module.  sysfs will have the
         currently-built-in version info, for comparison.
      
      d) tech support scripts can then easily grab the version info for what's
         running presently - a question I get often.
      
      There has been renewed interest in this patch on linux-scsi by driver
      authors.
      
      As the idea originated from GregKH, I leave his Signed-off-by: intact,
      though the implementation is nearly completely new.  Compiled and run on
      x86 and x86_64.
      
      From: Matthew Dobson <colpatch@us.ibm.com>
      
            build fix
      
      From: Thierry Vignaud <tvignaud@mandriva.com>
      
            build fix
      
      From: Matthew Dobson <colpatch@us.ibm.com>
      
            warning fix
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c988d2b2
    • 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
           credentials.
      
           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>
      3e30148c
    • David Howells's avatar
      [PATCH] Keys: Pass session keyring to call_usermodehelper() · 7888e7ff
      David Howells authored
      
      
      The attached patch makes it possible to pass a session keyring through to the
      process spawned by call_usermodehelper().  This allows patch 3/3 to pass an
      authorisation key through to /sbin/request-key, thus permitting better access
      controls when doing just-in-time key creation.
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7888e7ff
  3. 23 Jun, 2005 11 commits
    • Benjamin LaHaise's avatar
      [PATCH] aio: make wait_queue ->task ->private · c43dc2fd
      Benjamin LaHaise authored
      
      
      In the upcoming aio_down patch, it is useful to store a private data
      pointer in the kiocb's wait_queue.  Since we provide our own wake up
      function and do not require the task_struct pointer, it makes sense to
      convert the task pointer into a generic private pointer.
      Signed-off-by: default avatarBenjamin LaHaise <benjamin.c.lahaise@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c43dc2fd
    • 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>
      71a2224d
    • Kirill Korotaev's avatar
      [PATCH] Software suspend and recalc sigpending bug fix · 4fea2838
      Kirill Korotaev authored
      
      
      This patch fixes recalc_sigpending() to work correctly with tasks which are
      being freezed.
      
      The problem is that freeze_processes() sets PF_FREEZE and TIF_SIGPENDING
      flags on tasks, but recalc_sigpending() called from e.g.
      sys_rt_sigtimedwait or any other kernel place will clear TIF_SIGPENDING due
      to no pending signals queued and the tasks won't be freezed until it
      recieves a real signal or freezed_processes() fail due to timeout.
      Signed-Off-By: default avatarKirill Korotaev <dev@sw.ru>
      Signed-Off-By: default avatarAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4fea2838
    • 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.
      
      (akpm:
      
      > > +EXPORT_SYMBOL(suid_dumpable);
      >
      > EXPORT_SYMBOL_GPL?
      
      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>
      d6e71144
    • Prasanna S Panchamukhi's avatar
      [PATCH] jprobes: allow a jprobe to coexist with muliple kprobes · 8b0914ea
      Prasanna S Panchamukhi authored
      
      
      Presently either multiple kprobes or only one jprobe could be inserted.
      This patch removes the above limitation and allows one jprobe and multiple
      kprobes to coexist at the same address.  However multiple jprobes cannot
      coexist with multiple kprobes.  Currently I am working on the prototype to
      allow multiple jprobes coexist with multiple kprobes.
      Signed-off-by: default avatarAnanth N Mavinakayanhalli <amavin@redhat.com>
      Signed-off-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8b0914ea
    • Prasanna S Panchamukhi's avatar
      [PATCH] kprobes: Temporary disarming of reentrant probe · ea32c65c
      Prasanna S Panchamukhi authored
      
      
      In situations where a kprobes handler calls a routine which has a probe on it,
      then kprobes_handler() disarms the new probe forever.  This patch removes the
      above limitation by temporarily disarming the new probe.  When the another
      probe hits while handling the old probe, the kprobes_handler() saves previous
      kprobes state and handles the new probe without calling the new kprobes
      registered handlers.  kprobe_post_handler() restores back the previous kprobes
      state and the normal execution continues.
      
      However on x86_64 architecture, re-rentrancy is provided only through
      pre_handler().  If a routine having probe is referenced through
      post_handler(), then the probes on that routine are disarmed forever, since
      the exception stack is gets changed after the processor single steps the
      instruction of the new probe.
      
      This patch includes generic changes to support temporary disarming on
      reentrancy of probes.
      Signed-of-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ea32c65c
    • Hien Nguyen's avatar
      [PATCH] kprobes: moves lock-unlock to non-arch kprobe_flush_task · 0aa55e4d
      Hien Nguyen authored
      
      
      This patch moves the lock/unlock of the arch specific kprobe_flush_task()
      to the non-arch specific kprobe_flusk_task().
      Signed-off-by: default avatarHien Nguyen <hien@us.ibm.com>
      Acked-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0aa55e4d
    • Rusty Lynch's avatar
      [PATCH] Move kprobe [dis]arming into arch specific code · 7e1048b1
      Rusty Lynch authored
      
      
      The architecture independent code of the current kprobes implementation is
      arming and disarming kprobes at registration time.  The problem is that the
      code is assuming that arming and disarming is a just done by a simple write
      of some magic value to an address.  This is problematic for ia64 where our
      instructions look more like structures, and we can not insert break points
      by just doing something like:
      
      *p->addr = BREAKPOINT_INSTRUCTION;
      
      The following patch to 2.6.12-rc4-mm2 adds two new architecture dependent
      functions:
      
           * void arch_arm_kprobe(struct kprobe *p)
           * void arch_disarm_kprobe(struct kprobe *p)
      
      and then adds the new functions for each of the architectures that already
      implement kprobes (spar64/ppc64/i386/x86_64).
      
      I thought arch_[dis]arm_kprobe was the most descriptive of what was really
      happening, but each of the architectures already had a disarm_kprobe()
      function that was really a "disarm and do some other clean-up items as
      needed when you stumble across a recursive kprobe." So...  I took the
      liberty of changing the code that was calling disarm_kprobe() to call
      arch_disarm_kprobe(), and then do the cleanup in the block of code dealing
      with the recursive kprobe case.
      
      So far this patch as been tested on i386, x86_64, and ppc64, but still
      needs to be tested in sparc64.
      Signed-off-by: default avatarRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: default avatarAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7e1048b1
    • Hien Nguyen's avatar
      [PATCH] kprobes: function-return probes · b94cce92
      Hien Nguyen authored
      This patch adds function-return probes to kprobes for the i386
      architecture.  This enables you to establish a handler to be run when a
      function returns.
      
      1. API
      
      Two new functions are added to kprobes:
      
      	int register_kretprobe(struct kretprobe *rp);
      	void unregister_kretprobe(struct kretprobe *rp);
      
      2. Registration and unregistration
      
      2.1 Register
      
        To register a function-return probe, the user populates the following
        fields in a kretprobe object and calls register_kretprobe() with the
        kretprobe address as an argument:
      
        kp.addr - the function's address
      
        handler - this function is run after the ret instruction executes, but
        before control returns to the return address in the caller.
      
        maxactive - The maximum number of instances of the probed function that
        can be active concurrently.  For example, if the function is non-
        recursive and is called with a spinlock or mutex held, maxactive = 1
        should be enough.  If the function is non-recursive and can never
        relinquish the CPU (e.g., via a semaphore or preemption), NR_CPUS should
        be enough.  maxactive is used to determine how many kretprobe_instance
        objects to allocate for this particular probed function.  If maxactive <=
        0, it is set to a default value (if CONFIG_PREEMPT maxactive=max(10, 2 *
        NR_CPUS) else maxactive=NR_CPUS)
      
        For example:
      
          struct kretprobe rp;
          rp.kp.addr = /* entrypoint address */
          rp.handler = /*return probe handler */
          rp.maxactive = /* e.g., 1 or NR_CPUS or 0, see the above explanation */
          register_kretprobe(&rp);
      
        The following field may also be of interest:
      
        nmissed - Initialized to zero when the function-return probe is
        registered, and incremented every time the probed function is entered but
        there is no kretprobe_instance object available for establishing the
        function-return probe (i.e., because maxactive was set too low).
      
      2.2 Unregister
      
        To unregiter a function-return probe, the user calls
        unregister_kretprobe() with the same kretprobe object as registered
        previously.  If a probed function is running when the return probe is
        unregistered, the function will return as expected, but the handler won't
        be run.
      
      3. Limitations
      
      3.1 This patch supports only the i386 architecture, but patches for
          x86_64 and ppc64 are anticipated soon.
      
      3.2 Return probes operates by replacing the return address in the stack
          (or in a known register, such as the lr register for ppc).  This may
          cause __builtin_return_address(0), when invoked from the return-probed
          function, to return the address of the return-probes trampoline.
      
      3.3 This implementation uses the "Multiprobes at an address" feature in
          2.6.12-rc3-mm3.
      
      3.4 Due to a limitation in multi-probes, you cannot currently establish
          a return probe and a jprobe on the same function.  A patch to remove
          this limitation is being tested.
      
      This feature is required by SystemTap (http://sourceware.org/systemtap
      
      ),
      and reflects ideas contributed by several SystemTap developers, including
      Will Cohen and Ananth Mavinakayanahalli.
      Signed-off-by: default avatarHien Nguyen <hien@us.ibm.com>
      Signed-off-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarFrederik Deweerdt <frederik.deweerdt@laposte.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b94cce92
    • Alexander Nyberg's avatar
      [PATCH] avoid resursive oopses · df164db5
      Alexander Nyberg authored
      
      
      Prevent recursive faults in do_exit() by leaving the task alone and wait
      for reboot.  This may allow a more graceful shutdown and possibly save the
      original oops.
      Signed-off-by: default avatarAlexander Nyberg <alexn@telia.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      df164db5
    • Christoph Hellwig's avatar
      [PATCH] remove duplicate get_dentry functions in various places · 5f45f1a7
      Christoph Hellwig authored
      
      
      Various filesystem drivers have grown a get_dentry() function that's a
      duplicate of lookup_one_len, except that it doesn't take a maximum length
      argument and doesn't check for \0 or / in the passed in filename.
      
      Switch all these places to use lookup_one_len.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Greg KH <greg@kroah.com>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5f45f1a7