Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 8月, 2013 1 次提交
  3. 13 7月, 2013 1 次提交
    • J
      nfsd4: fix minorversion support interface · 35f7a14f
      由 J. Bruce Fields 提交于 
      You can turn on or off support for minorversions using e.g.

	echo "-4.2" >/proc/fs/nfsd/versions

However, the current implementation is a little wonky.  For example, the
above will turn off 4.2 support, but it will also turn *on* 4.1 support.

This didn't matter as long as we only had 2 minorversions, which was
true till very recently.

And do a little cleanup here.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      35f7a14f
  5. 02 7月, 2013 1 次提交
  7. 15 5月, 2013 1 次提交
  9. 04 5月, 2013 1 次提交
  11. 01 5月, 2013 1 次提交
    • J
      nfsd4: don't remap EISDIR errors in rename · 2a6cf944
      由 J. Bruce Fields 提交于 
      We're going out of our way here to remap an error to make rfc 3530
happy--but the rfc itself (nor rfc 1813, which has similar language)
gives no justification.  And disagrees with local filesystem behavior,
with Linux and posix man pages, and knfsd's implemented behavior for v2
and v3.

And the documented behavior seems better, in that it gives a little more
information--you could implement the 3530 behavior using the posix
behavior, but not the other way around.

Also, the Linux client makes no attempt to remap this error in the v4
case, so it can end up just returning EEXIST to the application in a
case where it should return EISDIR.

So honestly I think the rfc's are just buggy here--or in any case it
doesn't see worth the trouble to remap this error.
Reported-by: NFrank S Filz <ffilz@us.ibm.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      2a6cf944
  13. 09 4月, 2013 2 次提交
  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. 04 4月, 2013 1 次提交
  19. 03 4月, 2013 2 次提交
  21. 24 1月, 2013 1 次提交
  23. 18 12月, 2012 2 次提交
  25. 11 12月, 2012 2 次提交
    • S
      nfsd: make NFSd service boot time per-net · b9c0ef85
      由 Stanislav Kinsbursky 提交于 
      This is simple: an NFSd service can be started at different times in
different network environments. So, its "boot time" has to be assigned
per net.
Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b9c0ef85
    • N
      nfsd: avoid permission checks on EXCLUSIVE_CREATE replay · 7007c90f
      由 Neil Brown 提交于 
      With NFSv4, if we create a file then open it we explicit avoid checking
the permissions on the file during the open because the fact that we
created it ensures we should be allow to open it (the create and the
open should appear to be a single operation).

However if the reply to an EXCLUSIVE create gets lots and the client
resends the create, the current code will perform the permission check -
because it doesn't realise that it did the open already..

This patch should fix this.

Note that I haven't actually seen this cause a problem.  I was just
looking at the code trying to figure out a different EXCLUSIVE open
related issue, and this looked wrong.

(Fix confirmed with pynfs 4.0 test OPEN4--bfields)

Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>
[bfields: use OWNER_OVERRIDE and update for 4.1]
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7007c90f
  27. 26 11月, 2012 1 次提交
    • 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
  29. 15 11月, 2012 1 次提交
  31. 08 11月, 2012 1 次提交
  33. 02 10月, 2012 1 次提交
  35. 21 8月, 2012 1 次提交
  37. 28 7月, 2012 1 次提交
  39. 13 4月, 2012 1 次提交
  41. 12 4月, 2012 1 次提交
    • J
      nfsd: don't fail unchecked creates of non-special files · 9dc4e6c4
      由 J. Bruce Fields 提交于 
      Allow a v3 unchecked open of a non-regular file succeed as if it were a
lookup; typically a client in such a case will want to fall back on a
local open, so succeeding and giving it the filehandle is more useful
than failing with nfserr_exist, which makes it appear that nothing at
all exists by that name.

Similarly for v4, on an open-create, return the same errors we would on
an attempt to open a non-regular file, instead of returning
nfserr_exist.

This fixes a problem found doing a v4 open of a symlink with
O_RDONLY|O_CREAT, which resulted in the current client returning EEXIST.

Thanks also to Trond for analysis.

Cc: stable@kernel.org
Reported-by: NOrion Poplawski <orion@cora.nwra.com>
Tested-by: NOrion Poplawski <orion@cora.nwra.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9dc4e6c4
  43. 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
  45. 21 3月, 2012 2 次提交
  47. 07 3月, 2012 2 次提交
  49. 18 2月, 2012 1 次提交
  51. 16 2月, 2012 9 次提交