1. 18 7月, 2007 8 次提交
  2. 10 5月, 2007 1 次提交
  3. 15 2月, 2007 2 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
    • N
      [PATCH] knfsd: add some new fsid types · af6a4e28
      NeilBrown 提交于
      Add support for using a filesystem UUID to identify and export point in the
      filehandle.
      
      For NFSv2, this UUID is xor-ed down to 4 or 8 bytes so that it doesn't take up
      too much room.  For NFSv3+, we use the full 16 bytes, and possibly also a
      64bit inode number for exports beneath the root of a filesystem.
      
      When generating an fsid to return in 'stat' information, use the UUID (hashed
      down to size) if it is available and a small 'fsid' was not specifically
      provided.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      af6a4e28
  4. 31 1月, 2007 1 次提交
  5. 14 12月, 2006 4 次提交
  6. 21 10月, 2006 1 次提交
  7. 04 10月, 2006 4 次提交
  8. 02 10月, 2006 4 次提交
  9. 01 7月, 2006 1 次提交
  10. 24 5月, 2006 1 次提交
  11. 11 4月, 2006 1 次提交
  12. 28 3月, 2006 7 次提交
  13. 07 11月, 2005 1 次提交
  14. 08 9月, 2005 1 次提交
    • B
      [PATCH] sunrpc: cache_register can use wrong module reference · f35279d3
      Bruce Allan 提交于
      When registering an RPC cache, cache_register() always sets the owner as the
      sunrpc module.  However, there are RPC caches owned by other modules.  With
      the incorrect owner setting, the real owning module can be removed potentially
      with an open reference to the cache from userspace.
      
      For example, if one were to stop the nfs server and unmount the nfsd
      filesystem, the nfsd module could be removed eventhough rpc.idmapd had
      references to the idtoname and nametoid caches (i.e.
      /proc/net/rpc/nfs4.<cachename>/channel is still open).  This resulted in a
      system panic on one of our machines when attempting to restart the nfs
      services after reloading the nfsd module.
      
      The following patch adds a 'struct module *owner' field in struct
      cache_detail.  The owner is further assigned to the struct proc_dir_entry
      in cache_register() so that the module cannot be unloaded while user-space
      daemons have an open reference on the associated file under /proc.
      Signed-off-by: NBruce Allan <bwa@us.ibm.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f35279d3
  15. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4