Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 11月, 2012 1 次提交
  3. 08 11月, 2012 3 次提交
  5. 11 9月, 2012 1 次提交
  7. 21 8月, 2012 1 次提交
  9. 20 6月, 2012 1 次提交
    • J
      nfsd4: remove unnecessary comment · 9068bed1
      由 J. Bruce Fields 提交于 
      For the most part readers of cl_cb_state only need a value that is
"eventually" right.  And the value is set only either 1) in response to
some change of state, in which case it's set to UNKNOWN and then a
callback rpc is sent to probe the real state, or b) in the handling of a
response to such a callback.  UNKNOWN is therefore always a "temporary"
state, and for the other states we're happy to accept last writer wins.

So I think we're OK here.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9068bed1
  11. 01 6月, 2012 1 次提交
  13. 29 3月, 2012 1 次提交
  15. 26 3月, 2012 1 次提交
    • J
      nfsd: convert nfs4_client->cl_cb_flags to a generic flags field · a52d726b
      由 Jeff Layton 提交于 
      We'll need a way to flag the nfs4_client as already being recorded on
stable storage so that we don't continually upcall. Currently, that's
recorded in the cl_firststate field of the client struct. Using an
entire u32 to store a flag is rather wasteful though.

The cl_cb_flags field is only using 2 bits right now, so repurpose that
to a generic flags field. Rename NFSD4_CLIENT_KILL to
NFSD4_CLIENT_CB_KILL to make it evident that it's part of the callback
flags. Add a mask that we can use for existing checks that look to see
whether any flags are set, so that the new flags don't interfere.

Convert all references to cl_firstate to the NFSD4_CLIENT_STABLE flag,
and add a new NFSD4_CLIENT_RECLAIM_COMPLETE flag.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      a52d726b
  17. 10 3月, 2012 1 次提交
  19. 01 2月, 2012 2 次提交
  21. 05 1月, 2012 1 次提交
  23. 24 10月, 2011 1 次提交
  25. 27 9月, 2011 1 次提交
  27. 14 9月, 2011 1 次提交
  29. 23 2月, 2011 1 次提交
  31. 14 2月, 2011 1 次提交
  33. 15 1月, 2011 1 次提交
  35. 14 1月, 2011 1 次提交
  37. 12 1月, 2011 6 次提交
  39. 05 1月, 2011 2 次提交
  41. 17 12月, 2010 5 次提交
  43. 25 10月, 2010 1 次提交
  45. 21 10月, 2010 5 次提交
    • J
      nfsd4: only require krb5 principal for NFSv4.0 callbacks · 5d18c1c2
      由 J. Bruce Fields 提交于 
      In the sessions backchannel case, we don't need a krb5 principal name
for the client; we use the already-created forechannel credentials
instead.

Some cleanup, while we're there: make it clearer which code here is 4.0-
or sessions- specific.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      5d18c1c2
    • J
      nfsd4: move minorversion to client · 8323c3b2
      由 J. Bruce Fields 提交于 
      The minorversion seems more a property of the client than the callback
channel.

Some time we should probably also enforce consistent minorversion usage
from the client; for now, this is just a cosmetic change.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      8323c3b2
    • J
      nfsd4: separate callback change and callback probe · 5a3c9d71
      由 J. Bruce Fields 提交于 
      Only one of the nfsd4_callback_probe callers actually cares about
changing the callback information.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      5a3c9d71
    • J
      nfsd4: callback program number is per-session · 8b5ce5cd
      由 J. Bruce Fields 提交于 
      The callback program is allowed to depend on the session which the
callback is going over.

No change in behavior yet, while we still only do callbacks over a
single session for the lifetime of the client.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      8b5ce5cd
    • J
      nfsd4: make backchannel sequence number per-session · ac7c46f2
      由 J. Bruce Fields 提交于 
      Currently we don't deal well with a client that has multiple sessions
associated with it (even simultaneously, or serially over the lifetime
of the client).

In particular, we don't attempt to keep the backchannel running after
the original session diseappears.

We will fix that soon.

Once we do that, we need the slot sequence number to be per-session;
otherwise, for example, we cannot correctly handle a case like this:

	- All session 1 connections are lost.
	- The client creates session 2.  We use it for the backchannel
	  (since it's the only working choice).
	- The client gives us a new connection to use with session 1.
	- The client destroys session 2.

At this point our only choice is to go back to using session 1.  When we
do so we must use the sequence number that is next for session 1.  We
therefore need to maintain multiple sequence number streams.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      ac7c46f2