1. 20 6月, 2005 1 次提交
  2. 19 6月, 2005 1 次提交
  3. 17 6月, 2005 1 次提交
  4. 14 6月, 2005 1 次提交
  5. 10 6月, 2005 1 次提交
  6. 08 6月, 2005 1 次提交
    • T
      [PATCH] NFS: Fix lookup intent handling · 1d6757fb
      Trond Myklebust 提交于
      We should never apply a lookup intent to anything other than the last
      path component in an open(), create() or access() call.
      
      Introduce the helper nfs_lookup_check_intent() which always returns
      zero if LOOKUP_CONTINUE or LOOKUP_PARENT are set, and returns the
      intent flags if we're on the last component of the lookup.
      By doing so, we fix a bug in open(O_EXCL), where we may end up
      optimizing away a real lookup of the parent directory.
      
      Problem noticed by Linda Dunaphant <linda.dunaphant@ccur.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1d6757fb
  7. 07 6月, 2005 20 次提交
  8. 05 6月, 2005 1 次提交
  9. 03 6月, 2005 3 次提交
  10. 01 6月, 2005 2 次提交
    • B
      [PATCH] ppc32/ppc64: cleanup /proc/device-tree · 5f64f739
      Benjamin Herrenschmidt 提交于
      This cleans up the /proc/device-tree representation of the Open Firmware
      device-tree on ppc and ppc64.  It does the following things:
      
       - Workaround an issue in some Apple device-trees where a property may
         exist with the same name as a child node of the parent.  We now
         simply "drop" the property instead of creating duplicate entries in
         /proc with random result...
      
       - Do not try to chop off the "@0" at the end of a node name whose unit
         address is 0.  This is not useful, inconsistent, and the code was
         buggy and didn't always work anyway.
      
       - Do not create symlinks for the short name and unit address parts of a
         node.  These were never really used, bloated the memory footprint of
         the device-tree with useless struct proc_dir_entry and their matching
         dentry and inode cache bloat.
      
      This results in smaller code, smaller memory footprint, and a more
      accurate view of the tree presented to userland.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5f64f739
    • G
      [PATCH] UDF filesystem: array '__mon_yday' declared as not static · e74d633d
      Goffredo Baroncelli 提交于
      in fs/udf/udftime.c the global array '__mon_yday' is not static, and it
      conflicts with the glibc one when the kernel is compiled as user mode.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e74d633d
  11. 29 5月, 2005 1 次提交
  12. 27 5月, 2005 1 次提交
  13. 22 5月, 2005 1 次提交
  14. 20 5月, 2005 1 次提交
  15. 19 5月, 2005 1 次提交
    • S
      [PATCH] Avoid console spam with ext3 aborted journal. · 30121624
      Stephen Tweedie 提交于
      Avoid console spam with ext3 aborted journal.
      
      ext3 usually reports error conditions that it detects in its environment.
      But when its journal gets aborted due to such errors, it can sometimes
      continue to report that condition forever, spamming the console to such
      an extent that the initial first cause of the journal abort can be lost.
      
      When the journal aborts, we put the filesystem into readonly mode.  Most
      subsequent filesystem operations will get rejected immediately by checks
      for MS_RDONLY either in the filesystem or in the VFS.  But some paths do
      not have such checks --- for example, if we continue to write to a file
      handle that was opened before the fs went readonly.  (We only check for
      the ROFS condition when the file is first opened.)  In these cases, we
      can continue to generate log errors similar to
      
      EXT3-fs error (device $DEV) in start_transaction: Journal has aborted
      
      for each subsequent write.
      
      There is really no point in generating these errors after the initial
      error has been fully reported.  Specifically, if we're starting a
      completely new filesystem operation, and the filesystem is *already*
      readonly (ie. the ext3 layer has already detected and handled the
      underlying jbd abort), and we see an EROFS error, then there is simply
      no point in reporting it again.
      Signed-off-by: NStephen Tweedie <sct@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      30121624
  16. 18 5月, 2005 3 次提交