Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 10月, 2011 6 次提交
  3. 27 9月, 2011 4 次提交
  5. 21 9月, 2011 3 次提交
    • J
      leases: split up generic_setlease into lock/unlock cases · 8335ebd9
      由 J. Bruce Fields 提交于 
      Eventually we should probably do the same thing to the file operations
as well.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      8335ebd9
    • J
      nfsd4: make op_cacheresult another flag · c856694e
      由 J. Bruce Fields 提交于 
      I'm not sure why I used a new field for this originally.

Also, the differences between some of these flags are a little subtle;
add some comments to explain.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c856694e
    • J
      nfsd4: fix open downgrade, again · 3d02fa29
      由 J. Bruce Fields 提交于 
      Yet another open-management regression:

	- nfs4_file_downgrade() doesn't remove the BOTH access bit on
	  downgrade, so the server's idea of the stateid's access gets
	  out of sync with the client's.  If we want to keep an O_RDWR
	  open in this case, we should do that in the file_put_access
	  logic rather than here.
	- We forgot to convert v4 access to an open mode here.

This logic has proven too hard to get right.  In the future we may
consider:
	- reexamining the lock/openowner relationship (locks probably
	  don't really need to take their own references here).
	- adding open upgrade/downgrade support to the vfs.
	- removing the atomic operations.  They're redundant as long as
	  this is all under some other lock.

Also, maybe some kind of additional static checking would help catch
O_/NFS4_SHARE_ACCESS confusion.

Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      3d02fa29
  7. 19 9月, 2011 2 次提交
    • J
      nfsd4: hash closed stateid's like any other · f7a4d872
      由 J. Bruce Fields 提交于 
      Look up closed stateid's in the stateid hash like any other stateid
rather than searching the close lru.

This is simpler, and fixes a bug: currently we handle only the case of a
close that is the last close for a given stateowner, but not the case of
a close for a stateowner that still has active opens on other files.
Thus in a case like:

	open(owner, file1)
	open(owner, file2)
	close(owner, file2)
	close(owner, file2)

the final close won't be recognized as a retransmission.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f7a4d872
    • J
      nfsd4: construct stateid from clientid and counter · d3b313a4
      由 J. Bruce Fields 提交于 
      Including the full clientid in the on-the-wire stateid allows more
reliable detection of bad vs. expired stateid's, simplifies code, and
ensures we won't reuse the opaque part of the stateid (as we currently
do when the same openowner closes and reopens the same file).
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      d3b313a4
  9. 17 9月, 2011 3 次提交
  11. 16 9月, 2011 1 次提交
    • M
      nfsd41: try to check reply size before operation · 58e7b33a
      由 Mi Jinlong 提交于 
      For checking the size of reply before calling a operation,
we need try to get maxsize of the operation's reply.

v3: using new method as Bruce said,

 "we could handle operations in two different ways:

	- For operations that actually change something (write, rename,
	  open, close, ...), do it the way we're doing it now: be
	  very careful to estimate the size of the response before even
	  processing the operation.
	- For operations that don't change anything (read, getattr, ...)
	  just go ahead and do the operation.  If you realize after the
	  fact that the response is too large, then return the error at
	  that point.

  So we'd add another flag to op_flags: say, OP_MODIFIES_SOMETHING.  And for
  operations with OP_MODIFIES_SOMETHING set, we'd do the first thing.  For
  operations without it set, we'd do the second."
Signed-off-by: NMi Jinlong <mijinlong@cn.fujitsu.com>
[bfields@redhat.com: crash, don't attempt to handle, undefined op_rsize_bop]
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      58e7b33a
  13. 14 9月, 2011 18 次提交
  15. 07 9月, 2011 2 次提交
  17. 04 9月, 2011 1 次提交