Skip to content

cloud-kernel
cloud-kernel

bug2833 / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

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

切换分支/标签
  1. 25 3月, 2011 1 次提交
  3. 24 3月, 2011 1 次提交
  5. 12 1月, 2011 2 次提交
  7. 18 12月, 2010 1 次提交
  9. 25 10月, 2010 3 次提交
  11. 02 10月, 2010 1 次提交
  13. 31 7月, 2010 1 次提交
  15. 06 12月, 2009 2 次提交
  17. 09 9月, 2009 1 次提交
  19. 11 7月, 2009 1 次提交
  21. 18 6月, 2009 3 次提交
  23. 04 4月, 2009 3 次提交
  25. 08 1月, 2009 1 次提交
  27. 24 6月, 2008 1 次提交
  29. 11 7月, 2007 1 次提交
    • J
      NFS4: on a O_EXCL OPEN make sure SETATTR sets the fields holding the verifier · aa53ed54
      由 Jeff Layton 提交于 
      The Linux NFS4 client simply skips over the bitmask in an O_EXCL open
call and so it doesn't bother to reset any fields that may be holding
the verifier. This patch has us save the first two words of the bitmask
(which is all the current client has #defines for). The client then
later checks this bitmask and turns on the appropriate flags in the
sattr->ia_verify field for the following SETATTR call.

This patch only currently checks to see if the server used the atime
and mtime slots for the verifier (which is what the Linux server uses
for this). I'm not sure of what other fields the server could
reasonably use, but adding checks for others should be trivial.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      aa53ed54
  31. 15 5月, 2007 1 次提交
    • T
      NFS4: Fix incorrect use of sizeof() in fs/nfs/nfs4xdr.c · 8ae20abd
      由 Trond Myklebust 提交于 
      The XDR code should not depend on the physical allocation size of
structures like nfs4_stateid and nfs4_verifier since those may have to
change at some future date. We therefore replace all uses of
sizeof() with constants like NFS4_VERIFIER_SIZE and NFS4_STATEID_SIZE.

This also has the side-effect of fixing some warnings of the type
	format ‘%u’ expects type ‘unsigned int’, but argument X has type
		‘long unsigned int’
on 64-bit systems
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      8ae20abd
  33. 17 2月, 2007 1 次提交
  35. 11 7月, 2006 1 次提交
  37. 09 6月, 2006 1 次提交
    • T
      NFSv4: Implement the fs_locations function call · 683b57b4
      由 Trond Myklebust 提交于 
      NFSv4 allows for the fact that filesystems may be replicated across
several servers or that they may be migrated to a backup server in case of
failure of the primary server.
fs_locations is an NFSv4 operation for retrieving information about the
location of migrated and/or replicated filesystems.

Based on an initial implementation by Jiaying Zhang <jiayingz@citi.umich.edu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      683b57b4
  39. 25 4月, 2006 1 次提交
  41. 24 6月, 2005 1 次提交
    • N
      [PATCH] nfsd4: fix fh_expire_type · 49640001
      由 NeilBrown 提交于 
      We're returning NFS4_FH_NOEXPIRE_WITH_OPEN | NFS4_FH_VOL_RENAME for the
fh_expire_type attribute.  This is incorrect:
	1. The spec actually only allows NOEXPIRE_WITH_OPEN when
	   VOLATILE_ANY is also set.
	2. Filehandles for open files can expire, if the file is removed
	   and there is a reboot.
	3. Filehandles are only volatile on rename in the nosubtree check
	   case.

Unfortunately, there's no way to indicate that we only expire on remove.  So
our only choice is FH4_VOLATILE_ANY.  Although it's redundant, we also set
FH4_VOL_RENAME in the subtree check case, since subtreecheck does actually
cause problems in practice and it seems possibly useful to give clients some
way to distinguish that case.

Fix a mispelled #define while we're at it.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      49640001
  43. 23 6月, 2005 2 次提交
  45. 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