Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 31 5月, 2014 1 次提交
    • J
      nfsd4: teach encoders to handle reserve_space failures · d0a381dd
      由 J. Bruce Fields 提交于 
      We've tried to prevent running out of space with COMPOUND_SLACK_SPACE
and special checking in those operations (getattr) whose result can vary
enormously.

However:
	- COMPOUND_SLACK_SPACE may be difficult to maintain as we add
	  more protocol.
	- BUG_ON or page faulting on failure seems overly fragile.
	- Especially in the 4.1 case, we prefer not to fail compounds
	  just because the returned result came *close* to session
	  limits.  (Though perfect enforcement here may be difficult.)
	- I'd prefer encoding to be uniform for all encoders instead of
	  having special exceptions for encoders containing, for
	  example, attributes.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      d0a381dd
  3. 27 5月, 2014 1 次提交
  5. 23 5月, 2014 2 次提交
  7. 29 3月, 2014 1 次提交
  9. 07 1月, 2014 1 次提交
  11. 04 1月, 2014 1 次提交
  13. 15 5月, 2013 1 次提交
  15. 08 4月, 2013 1 次提交
    • J
      nfsd4: cleanup handling of nfsv4.0 closed stateid's · 9411b1d4
      由 J. Bruce Fields 提交于 
      Closed stateid's are kept around a little while to handle close replays
in the 4.0 case.  So we stash them in the last-used stateid in the
oo_last_closed_stateid field of the open owner.  We can free that in
encode_seqid_op_tail once the seqid on the open owner is next
incremented.  But we don't want to do that on the close itself; so we
set NFS4_OO_PURGE_CLOSE flag set on the open owner, skip freeing it the
first time through encode_seqid_op_tail, then when we see that flag set
next time we free it.

This is unnecessarily baroque.

Instead, just move the logic that increments the seqid out of the xdr
code and into the operation code itself.

The justification given for the current placement is that we need to
wait till the last minute to be sure we know whether the status is a
sequence-id-mutating error or not, but examination of the code shows
that can't actually happen.
Reported-by: NYanchuan Nian <ycnian@gmail.com>
Tested-by: NYanchuan Nian <ycnian@gmail.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9411b1d4
  17. 03 4月, 2013 2 次提交
  19. 24 1月, 2013 1 次提交
  21. 18 12月, 2012 1 次提交
  23. 26 11月, 2012 2 次提交
    • J
      nfsd4: delay filling in write iovec array till after xdr decoding · ffe1137b
      由 J. Bruce Fields 提交于 
      Our server rejects compounds containing more than one write operation.
It's unclear whether this is really permitted by the spec; with 4.0,
it's possibly OK, with 4.1 (which has clearer limits on compound
parameters), it's probably not OK.  No client that we're aware of has
ever done this, but in theory it could be useful.

The source of the limitation: we need an array of iovecs to pass to the
write operation.  In the worst case that array of iovecs could have
hundreds of elements (the maximum rwsize divided by the page size), so
it's too big to put on the stack, or in each compound op.  So we instead
keep a single such array in the compound argument.

We fill in that array at the time we decode the xdr operation.

But we decode every op in the compound before executing any of them.  So
once we've used that array we can't decode another write.

If we instead delay filling in that array till the time we actually
perform the write, we can reuse it.

Another option might be to switch to decoding compound ops one at a
time.  I considered doing that, but it has a number of other side
effects, and I'd rather fix just this one problem for now.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ffe1137b
    • J
      nfsd4: move more write parameters into xdr argument · 70cc7f75
      由 J. Bruce Fields 提交于 
      In preparation for moving some of this elsewhere.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      70cc7f75
  25. 15 11月, 2012 1 次提交
  27. 08 11月, 2012 1 次提交
  29. 01 6月, 2012 1 次提交
  31. 21 3月, 2012 1 次提交
    • C
      NFSD: Fix nfs4_verifier memory alignment · ab4684d1
      由 Chuck Lever 提交于 
      Clean up due to code review.

The nfs4_verifier's data field is not guaranteed to be u32-aligned.
Casting an array of chars to a u32 * is considered generally
hazardous.

We can fix most of this by using a __be32 array to generate the
verifier's contents and then byte-copying it into the verifier field.

However, there is one spot where there is a backwards compatibility
constraint: the do_nfsd_create() call expects a verifier which is
32-bit aligned.  Fix this spot by forcing the alignment of the create
verifier in the nfsd4_open args structure.

Also, sizeof(nfs4_verifer) is the size of the in-core verifier data
structure, but NFS4_VERIFIER_SIZE is the number of octets in an XDR'd
verifier.  The two are not interchangeable, even if they happen to
have the same value.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ab4684d1
  33. 18 2月, 2012 3 次提交
  35. 16 2月, 2012 3 次提交
  37. 15 2月, 2012 1 次提交
    • J
      nfsd4: rearrange struct nfsd4_slot · 73e79482
      由 J. Bruce Fields 提交于 
      Combine two booleans into a single flag field, move the smaller fields
to the end.

(In practice this doesn't make the struct any smaller.  But we'll be
adding another flag here soon.)

Remove some debugging code that doesn't look useful, while we're in the
neighborhood.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      73e79482
  39. 24 10月, 2011 1 次提交
  41. 18 10月, 2011 4 次提交
  43. 12 10月, 2011 1 次提交
  45. 27 9月, 2011 1 次提交
  47. 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
  49. 07 9月, 2011 1 次提交
  51. 01 9月, 2011 3 次提交
  53. 28 8月, 2011 1 次提交
  55. 18 7月, 2011 1 次提交
    • J
      nfsd: turn on reply cache for NFSv4 · 1091006c
      由 J. Bruce Fields 提交于 
      It's sort of ridiculous that we've never had a working reply cache for
NFSv4.

On the other hand, we may still not: our current reply cache is likely
not very good, especially in the TCP case (which is the only case that
matters for v4).  What we really need here is some serious testing.

Anyway, here's a start.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      1091006c