Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 12月, 2012 1 次提交
    • 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
  3. 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
  5. 15 11月, 2012 1 次提交
  7. 08 11月, 2012 1 次提交
  9. 02 10月, 2012 1 次提交
  11. 21 8月, 2012 1 次提交
  13. 28 7月, 2012 1 次提交
  15. 13 4月, 2012 1 次提交
  17. 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
  19. 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
  21. 21 3月, 2012 2 次提交
  23. 07 3月, 2012 2 次提交
  25. 18 2月, 2012 1 次提交
  27. 16 2月, 2012 9 次提交
  29. 04 1月, 2012 1 次提交
  31. 07 12月, 2011 1 次提交
  33. 24 10月, 2011 1 次提交
  35. 19 10月, 2011 1 次提交
  37. 18 10月, 2011 2 次提交
    • J
      nfsd4: warn on open failure after create · 856121b2
      由 J. Bruce Fields 提交于 
      If we create the object and then return failure to the client, we're
left with an unexpected file in the filesystem.

I'm trying to eliminate such cases but not 100% sure I have so an
assertion might be helpful for now.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      856121b2
    • J
      nfsd4: clean up open owners on OPEN failure · d29b20cd
      由 J. Bruce Fields 提交于 
      If process_open1() creates a new open owner, but the open later fails,
the current code will leave the open owner around.  It won't be on the
close_lru list, and the client isn't expected to send a CLOSE, so it
will hang around as long as the client does.

Similarly, if process_open1() removes an existing open owner from the
close lru, anticipating that an open owner that previously had no
associated stateid's now will, but the open subsequently fails, then
we'll again be left with the same leak.

Fix both problems.
Reported-by: NBryan Schumaker <bjschuma@netapp.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      d29b20cd
  39. 12 10月, 2011 1 次提交
  41. 21 9月, 2011 1 次提交
  43. 17 9月, 2011 1 次提交
  45. 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
  47. 07 9月, 2011 1 次提交
  49. 01 9月, 2011 2 次提交
  51. 28 8月, 2011 2 次提交
    • J
      nfsd4: stop using nfserr_resource for transitory errors · 3e772463
      由 J. Bruce Fields 提交于 
      The server is returning nfserr_resource for both permanent errors and
for errors (like allocation failures) that might be resolved by retrying
later.  Save nfserr_resource for the former and use delay/jukebox for
the latter.

Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      3e772463
    • J
      nfsd4: permit read opens of executable-only files · a043226b
      由 J. Bruce Fields 提交于 
      A client that wants to execute a file must be able to read it.  Read
opens over nfs are therefore implicitly allowed for executable files
even when those files are not readable.

NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on
read requests, but NFSv4 has gotten this wrong ever since
dc730e17 "nfsd4: fix owner-override on
open", when we realized that the file owner shouldn't override
permissions on non-reclaim NFSv4 opens.

So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow
reads of executable files.

So, do the same thing we do whenever we encounter another weird NFS
permission nit: define yet another NFSD_MAY_* flag.

The industry's future standardization on 128-bit processors will be
motivated primarily by the need for integers with enough bits for all
the NFSD_MAY_* flags.
Reported-by: NLeonardo Borda <leonardoborda@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      a043226b
  53. 27 8月, 2011 1 次提交
    • J
      nfsd4: it's OK to return nfserr_symlink · 75c096f7
      由 J. Bruce Fields 提交于 
      The nfsd4 code has a bunch of special exceptions for error returns which
map nfserr_symlink to other errors.

In fact, the spec makes it clear that nfserr_symlink is to be preferred
over less specific errors where possible.

The patch that introduced it back in 2.6.4 is "kNFSd: correct symlink
related error returns.", which claims that these special exceptions are
represent an NFSv4 break from v2/v3 tradition--when in fact the symlink
error was introduced with v4.

I suspect what happened was pynfs tests were written that were overly
faithful to the (known-incomplete) rfc3530 error return lists, and then
code was fixed up mindlessly to make the tests pass.

Delete these unnecessary exceptions.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      75c096f7