1. 10 5月, 2011 4 次提交
  2. 03 3月, 2011 1 次提交
    • A
      hpfs: remove the BKL · 9a311b96
      Arnd Bergmann 提交于
      This removes the BKL in hpfs in a rather awful
      way, by making the code only work on uniprocessor
      systems without kernel preemption, as suggested
      by Andi Kleen.
      
      The HPFS code probably has close to zero remaining
      users on current kernels, all archeological uses of
      the file system can probably be done with the significant
      restrictions.
      
      The hpfs_lock/hpfs_unlock functions are left in the
      code, sincen Mikulas has indicated that he is still
      interested in fixing it in a better way.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: linux-fsdevel@vger.kernel.org
      9a311b96
  3. 07 1月, 2011 1 次提交
  4. 04 3月, 2010 2 次提交
  5. 13 7月, 2009 1 次提交
  6. 14 11月, 2008 1 次提交
  7. 23 10月, 2008 1 次提交
  8. 27 7月, 2008 1 次提交
    • M
      [patch 05/14] hpfs: dont call permission() · 1bd5191d
      Miklos Szeredi 提交于
      hpfs_unlink() calls permission() prior to truncating the file.  HPFS
      doesn't define a .permission method, so replace with explicit call to
      generic_permission().
      
      This is equivalent, except that devcgroup_inode_permission() and
      security_inode_permission() are not called.
      
      The truncation is just an implementation detail of the unlink, so
      these security checks are unnecessary.
      
      I suspect that even calling generic_permission() is unnecessary, since
      we shouldn't mind if the file isn't writable.  But I leave that to the
      maintainer to decide.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      CC: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      1bd5191d
  9. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  10. 13 2月, 2007 1 次提交
  11. 01 10月, 2006 3 次提交
  12. 29 6月, 2006 1 次提交
  13. 23 3月, 2006 1 次提交
  14. 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