Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 31 5月, 2006 4 次提交
  3. 22 4月, 2006 2 次提交
  5. 27 3月, 2006 1 次提交
  7. 23 3月, 2006 1 次提交
  9. 04 3月, 2006 1 次提交
  11. 02 3月, 2006 1 次提交
  13. 01 3月, 2006 1 次提交
  15. 28 2月, 2006 1 次提交
  17. 15 2月, 2006 1 次提交
  19. 28 1月, 2006 1 次提交
  21. 19 1月, 2006 1 次提交
  23. 13 1月, 2006 1 次提交
  25. 09 1月, 2006 1 次提交
    • O
      [PATCH] Fix and add EXPORT_SYMBOL(filemap_write_and_wait) · 28fd1298
      由 OGAWA Hirofumi 提交于 
      This patch add EXPORT_SYMBOL(filemap_write_and_wait) and use it.

See mm/filemap.c:

And changes the filemap_write_and_wait() and filemap_write_and_wait_range().

Current filemap_write_and_wait() doesn't wait if filemap_fdatawrite()
returns error.  However, even if filemap_fdatawrite() returned an
error, it may have submitted the partially data pages to the device.
(e.g. in the case of -ENOSPC)

<quotation>
Andrew Morton writes,

If filemap_fdatawrite() returns an error, this might be due to some
I/O problem: dead disk, unplugged cable, etc.  Given the generally
crappy quality of the kernel's handling of such exceptions, there's a
good chance that the filemap_fdatawait() will get stuck in D state
forever.
</quotation>

So, this patch doesn't wait if filemap_fdatawrite() returns the -EIO.

Trond, could you please review the nfs part?  Especially I'm not sure,
nfs must use the "filemap_fdatawrite(inode->i_mapping) == 0", or not.
Acked-by: NTrond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      28fd1298
  27. 13 12月, 2005 1 次提交
  29. 03 12月, 2005 1 次提交
  31. 19 11月, 2005 1 次提交
  33. 21 10月, 2005 1 次提交
  35. 13 10月, 2005 1 次提交
  37. 12 10月, 2005 1 次提交
  39. 11 10月, 2005 1 次提交
  41. 06 10月, 2005 4 次提交
  43. 04 10月, 2005 1 次提交
  45. 16 9月, 2005 2 次提交
  47. 01 9月, 2005 1 次提交
  49. 31 8月, 2005 2 次提交
  51. 27 8月, 2005 1 次提交
    • S
      [PATCH] Fix oops in fs/locks.c on close of file with pending locks · d634cc15
      由 Steve French 提交于 
      The recent change to locks_remove_flock code in fs/locks.c changes how
byte range locks are removed from closing files, which shows up a bug in
cifs.

The assumption in the cifs code was that the close call sent to the
server would remove any pending locks on the server on this file, but
that is no longer safe as the fs/locks.c code on the client wants unlock
of 0 to PATH_MAX to remove all locks (at least from this client, it is
not possible AFAIK to remove all locks from other clients made to the
server copy of the file).

Note that cifs locks are different from posix locks - and it is not
possible to map posix locks perfectly on the wire yet, due to
restrictions of the cifs network protocol, even to Samba without adding
a new request type to the network protocol (which we plan to do for
Samba 3.0.21 within a few months), but the local client will have the
correct, posix view, of the lock in most cases.

The correct fix for cifs for this would involve a bigger change than I
would like to do this late in the 2.6.13-rc cycle - and would involve
cifs keeping track of all unmerged (uncoalesced) byte range locks for
each remote inode and scanning that list to remove locks that intersect
or fall wholly within the range - locks that intersect may have to be
reaquired with the smaller, remaining range.
Signed-off-by: NSteve French <sfrench@us.ibm.com>
Signed-off-by: NDave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d634cc15
  53. 25 8月, 2005 2 次提交
  55. 21 8月, 2005 1 次提交
  57. 24 6月, 2005 1 次提交
  59. 23 6月, 2005 1 次提交