1. 26 6月, 2005 35 次提交
  2. 24 6月, 2005 5 次提交
    • A
      [PATCH] make various thing static · 52c1da39
      Adrian Bunk 提交于
      Another rollup of patches which give various symbols static scope
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      52c1da39
    • M
      [PATCH] modules: add version and srcversion to sysfs · c988d2b2
      Matt Domsch 提交于
      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: NGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c988d2b2
    • D
      [PATCH] Keys: Make request-key create an authorisation key · 3e30148c
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Signed-Off-By: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e30148c
    • D
      [PATCH] Keys: Pass session keyring to call_usermodehelper() · 7888e7ff
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7888e7ff
    • B
      [PATCH] aio: make wait_queue ->task ->private · c43dc2fd
      Benjamin LaHaise 提交于
      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: NBenjamin LaHaise <benjamin.c.lahaise@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c43dc2fd