Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 28 7月, 2012 15 次提交
  3. 27 7月, 2012 1 次提交
  5. 25 7月, 2012 5 次提交
  7. 11 7月, 2012 4 次提交
    • J
      nfsd: share some function prototypes · 7f2e7dc0
      由 J. Bruce Fields 提交于 
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7f2e7dc0
    • J
      nfsd: allow owner_override only for regular files · d91d0b56
      由 J. Bruce Fields 提交于 
      We normally allow the owner of a file to override permissions checks on
IO operations, since:
	- the client will take responsibility for doing an access check
	  on open;
	- the permission checks offer no protection against malicious
	  clients--if they can authenticate as the file's owner then
	  they can always just change its permissions;
	- checking permission on each IO operation breaks the usual
	  posix rule that permission is checked only on open.

However, we've never allowed the owner to override permissions on
readdir operations, even though the above logic would also apply to
directories.  I've never heard of this causing a problem, probably
because a) simultaneously opening and creating a directory (with
restricted mode) isn't possible, and b) opening a directory, then
chmod'ing it, is rare.

Our disallowal of owner-override on directories appears to be an
accident, though--the readdir itself succeeds, and then we fail just
because lookup_one_len() calls in our filldir methods fail.

I'm not sure what the easiest fix for that would be.  For now, just make
this behavior obvious by denying the override right at the start.

This also fixes some odd v4 behavior: with the rdattr_error attribute
requested, it would perform the readdir but return an ACCES error with
each entry.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      d91d0b56
    • J
      nfsd4: release openowners on free in >=4.1 case · 74dbafaf
      由 J. Bruce Fields 提交于 
      We don't need to keep openowners around in the >=4.1 case, because they
aren't needed to handle CLOSE replays any more (that's a problem for
sessions).  And doing so causes unexpected failures on a subsequent
destroy_clientid to fail.

We probably also need something comparable for lock owners on last
unlock.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      74dbafaf
    • J
      nfsd4: our filesystems are normally case sensitive · 2930d381
      由 J. Bruce Fields 提交于 
      Actually, xfs and jfs can optionally be case insensitive; we'll handle
that case in later patches.

Cc: stable@vger.kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      2930d381
  9. 20 6月, 2012 5 次提交
    • J
      nfsd4: process_open2 cleanup · 4af82504
      由 J. Bruce Fields 提交于 
      Note we can simplify the error handling a little by doing the truncate
earlier.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      4af82504
    • J
      nfsd4: nfsd4_lock() cleanup · e1aaa891
      由 J. Bruce Fields 提交于 
      Share a little common logic.  And note the comments here are a little
out of date (e.g. we don't always create new state in the "new" case any
more.)
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      e1aaa891
    • 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
    • C
      NFSD: TEST_STATEID should not return NFS4ERR_STALE_STATEID · 7df302f7
      由 Chuck Lever 提交于 
      According to RFC 5661, the TEST_STATEID operation is not allowed to
return NFS4ERR_STALE_STATEID.  In addition, RFC 5661 says:

15.1.16.5.  NFS4ERR_STALE_STATEID (Error Code 10023)

   A stateid generated by an earlier server instance was used.  This
   error is moot in NFSv4.1 because all operations that take a stateid
   MUST be preceded by the SEQUENCE operation, and the earlier server
   instance is detected by the session infrastructure that supports
   SEQUENCE.

I triggered NFS4ERR_STALE_STATEID while testing the Linux client's
NOGRACE recovery.  Bruce suggested an additional test that could be
useful to client developers.

Lastly, RFC 5661, section 18.48.3 has this:

 o  Special stateids are always considered invalid (they result in the
    error code NFS4ERR_BAD_STATEID).

An explicit check is made for those state IDs to avoid printk noise.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7df302f7
    • W
      nfsd: probe the back channel on new connections · 24119673
      由 Weston Andros Adamson 提交于 
      Initiate a CB probe when a new connection with the correct direction is added
to a session (IFF backchannel is marked as down).  Without this a
BIND_CONN_TO_SESSION has no effect on the internal backchannel state, which
causes the server to reply to every SEQUENCE op with the
SEQ4_STATUS_CB_PATH_DOWN flag set until DESTROY_SESSION.
Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      24119673
  11. 18 6月, 2012 2 次提交
  13. 16 6月, 2012 2 次提交
  15. 15 6月, 2012 6 次提交