Skip to content

L
linux

xiphi1978 / linux

通知 2
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 6月, 2005 1 次提交
  3. 17 6月, 2005 1 次提交
  5. 14 6月, 2005 1 次提交
  7. 10 6月, 2005 1 次提交
  9. 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
  11. 07 6月, 2005 20 次提交
  13. 05 6月, 2005 1 次提交
  15. 03 6月, 2005 3 次提交
  17. 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
  19. 29 5月, 2005 1 次提交
  21. 27 5月, 2005 1 次提交
  23. 22 5月, 2005 1 次提交
  25. 20 5月, 2005 1 次提交
  27. 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
  29. 18 5月, 2005 3 次提交
  31. 17 5月, 2005 1 次提交
    • A
      [PATCH] block_read_full_page() get_block() error handling fix · c64610ba
      由 Andrew Morton 提交于 
      If block_read_full_page() detects an error when running get_block() it will
run SetPageError(), then it will zero out the block in pagecache and will mark
the buffer_head uptodate.

So at the end of readahead we end up with a non-uptodate pagecache page which
is marked PageError.  But it has uptodate buffers.

The pagefault code will run ClearPageError, will launch readpage a second time
and block_read_full_page() will notice the uptodate buffers and will mark the
page uptodate as well.  We end up with an uptodate, !PageError page full of
zeros and the error is lost.

(It seems a little odd that filemap_nopage() runs ClearPageError().  I guess
all of this adds up to meaning that for each attempted access to the page, the
pagefault handler will retry the I/O.  Which is good and bad.  If the app is
ignoring SIGBUS for some reason we could get a lot of back-to-back I/O
errors.)

Fix it by not marking the pagecache buffer_head as uptodate if the attempt to
map that buffer to a disk block failed.

Credit-to: Qu Fuping <fs@ercist.iscas.ac.cn>

  For reporting the bug and identifying its source.
Signed-off-by: NQu Fuping <fs@ercist.iscas.ac.cn>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c64610ba