- 10 Mar, 2012 1 commit
-
-
Trond Myklebust authored
When the NFSv4.0 server tells us that it can no-longer talk to us on the callback channel, we should attempt a new SETCLIENTID in order to re-transmit the callback channel information. Note that as long as we do not change the boot verifier, this is a safe procedure; the server is required to keep our state. Also move the function nfs_handle_cb_pathdown to fs/nfs/nfs4state.c, and change the name in order to mark it as being specific to NFSv4.0. Signed-off-by:Trond Myklebust <Trond.Myklebust@netapp.com>
-
- 09 Mar, 2012 2 commits
-
-
Trond Myklebust authored
Ensure that we select delegation stateids first, then lock stateids and then open stateids. Signed-off-by: -
Trond Myklebust authored
The server will just return an NFS4ERR_OPENMODE anyway. Signed-off-by:
-
- 08 Mar, 2012 1 commit
-
-
Andy Adamson authored
The error handler nfs4_state parameter is never NULL in the pNFS case as the open_context must carry an nfs_state. Signed-off-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
-
- 07 Mar, 2012 5 commits
-
-
Trond Myklebust authored
If a setattr() fails because of an NFS4ERR_OPENMODE error, it is probably due to us holding a read delegation. Ensure that the recovery routines return that delegation in this case. Reported-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Trond Myklebust authored
Otherwise we can end up with sequence id problems if the client reuses the owner_id before the server has processed the release_lockowner Signed-off-by: -
Andy Adamson authored
Handle DS READ and WRITE stateid errors by recovering the stateid on the MDS. NFS4ERR_OLD_STATEID is ignored as the client always sends a state sequenceid of zero for DS READ and WRITE stateids. Signed-off-by:
-
Weston Andros Adamson authored
Print the filehandle crc in two debug messages Signed-off-by:
Weston Andros Adamson <dros@netapp.com> Signed-off-by:
-
Weston Andros Adamson authored
Match wireshark's CRC-32 hash for easier debugging Signed-off-by:
-
- 06 Mar, 2012 17 commits
-
-
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Chuck Lever authored
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. Fix this by using a __be32 array to generate a verifier's contents, and then byte-copy the contents into the verifier field. The contents of a verifier, for all intents and purposes, are opaque bytes. Only local code that generates a verifier need know the actual content and format. Everyone else compares the full byte array for exact equality. 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:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
Replace the union with the common struct stateid4 as defined in both RFC3530 and RFC5661. This makes it easier to access the sequence id, which will again make implementing support for parallel OPEN calls easier. Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
It is really a function for selecting the correct stateid to use in a read or write situation. Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
The current version of encode_stateid really only applies to open stateids. You can't use it for locks, delegations or layouts. Signed-off-by: -
Trond Myklebust authored
Change the name to reflect what we're really doing: testing two stateids for whether or not they match according the the rules in RFC3530 and RFC5661. Move the code from callback_proc.c to nfs4proc.c Signed-off-by: -
Trond Myklebust authored
nfs41_validate_delegation_stateid is broken if we supply a stateid with a non-zero sequence id. Instead of trying to match the sequence id, the function assumes that we always want to error. While this is true for a delegation callback, it is not true in general. Also fix a typo in nfs4_callback_recall. Reported-by:
-
Trond Myklebust authored
If we know that the delegation stateid is bad or revoked, we need to remove that delegation as soon as possible, and then mark all the stateids that relied on that delegation for recovery. We cannot use the delegation as part of the recovery process. Also note that NFSv4.1 uses a different error code (NFS4ERR_DELEG_REVOKED) to indicate that the delegation was revoked. Finally, ensure that setlk() and setattr() can both recover safely from a revoked delegation. Signed-off-by: -
Trond Myklebust authored
The check for 'fh == NULL' needs to come _before_ we dereference fh. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 05 Mar, 2012 2 commits
-
-
Trond Myklebust authored
The attempt to display the implementation ID needs to be conditional on whether or not CONFIG_NFS_V4_1 is defined Reported-by:
Bryan Schumaker <Bryan.Schumaker@netapp.com> Signed-off-by:
-
Bryan Schumaker authored
When compiled without NFS v4 configured these function won't be defined and the compiler will yell. Signed-off-by:
Bryan Schumaker <bjschuma@netapp.com> Signed-off-by:
-
- 03 Mar, 2012 1 commit
-
-
Trond Myklebust authored
Conflicts: fs/nfs/nfs4proc.c Back-merge of the upstream kernel in order to fix a conflict with the slotid type conversion and implementation id patches...
-
- 02 Mar, 2012 11 commits
-
-
Chuck Lever authored
Get rid of encode_compound: tag= when XDR debugging is enabled. The current Linux client never sets compound tags. Signed-off-by:
-
Chuck Lever authored
The fh_expire_type file attribute is a filesystem wide attribute that consists of flags that indicate what characteristics file handles on this FSID have. Our client doesn't support volatile file handles. It should find out early (say, at mount time) whether the server is going to play shenanighans with file handles during a migration. Signed-off-by:
-
Chuck Lever authored
The Linux NFS client must distinguish between referral events (which it currently supports) and migration events (which it does not yet support). In both types of events, an fs_locations array is returned. But upper layers, not the XDR layer, should make the distinction between a referral and a migration. There really isn't a way for an XDR decoder function to distinguish the two, in general. Slightly adjust the FATTR flags returned by decode_fs_locations() to set NFS_ATTR_FATTR_V4_LOCATIONS only if a non-empty locations array was returned from the server. Then have logic in nfs4proc.c distinguish whether the locations array is for a referral or something else. Signed-off-by:
-
Chuck Lever authored
Clean up: pass just the clientid4 to encode_renew(). This enables it to be used by callers who might not have an full nfs_client. Signed-off-by:
-
Chuck Lever authored
For debugging, introduce a simplistic function to print NFS file handles on the system console. The main function is hooked into the dprintk debugging facility, but you can directly call the helper, _nfs_display_fhandle(), if you want to print a handle unconditionally. Signed-off-by:
-
Chuck Lever authored
For NFSv4 mounts, the clientaddr= mount option has always been required. Now we have rpc_localaddr() in the kernel, which was modeled after the same logic in the mount.nfs command that constructs the clientaddr= mount option. If user space doesn't provide a clientaddr= mount option, the kernel can now construct its own. Signed-off-by:
-
Chuck Lever authored
NFSv4.0 clients must send endpoint information for their callback service to NFSv4.0 servers during their first contact with a server. Traditionally on Linux, user space provides the callback endpoint IP address via the "clientaddr=" mount option. During an NFSv4 migration event, it is possible that an FSID may be migrated to a destination server that is accessible via a different source IP address than the source server was. The client must update callback endpoint information on the destination server so that it can maintain leases and allow delegation. Without a new "clientaddr=" option from user space, however, the kernel itself must construct an appropriate IP address for the callback update. Provide an API in the RPC client for upper layer RPC consumers to acquire a source address for a remote. The mechanism used by the mount.nfs command is copied: set up a connected UDP socket to the designated remote, then scrape the source address off the socket. We are careful to select the correct network namespace when setting up the temporary UDP socket. Signed-off-by:
-
Trond Myklebust authored
When the cl_xprt field is updated, the cl_server field will also have to change. Since the contents of cl_server follow the remote endpoint of cl_xprt, just move that field to the rpc_xprt. Signed-off-by:
-
Trond Myklebust authored
A migration event will replace the rpc_xprt used by an rpc_clnt. To ensure this can be done safely, all references to cl_xprt must now use a form of rcu_dereference(). Special care is taken with rpc_peeraddr2str(), which returns a pointer to memory whose lifetime is the same as the rpc_xprt. Signed-off-by:
-
Chuck Lever authored
CLOSE is new with NFSv4. Sometimes it's important to know the timing of this operation compared to things like lease renewal. Signed-off-by:
-
Chuck Lever authored
I noticed recently that decode_attr_fs_locations() is not generating very pretty debugging output. The pathname components each appear on a separate line of output, though that does not appear to be the intended display behavior. The preferred way to generate continued lines of output on the console is to use pr_cont(). Note that incoming pathname4 components contain a string that is not necessarily NUL-terminated. I did actually see some trailing garbage on the console. In addition to correcting the line continuation problem, add a string precision format specifier to ensure that each component string is displayed properly, and that vsnprintf() does not Oops. Someone pointed out that allowing incoming network data to possibly generate a console line of unbounded length may not be such a good idea. Since this output will rarely be enabled, and there is a hard upper bound (NFS4_PATHNAME_MAXCOMPONENTS) in our implementation, this is probably not a major concern. It might be useful to additionally sanity-check the length of each incoming component, however. RFC 3530bis15 does not suggest a maximum number of UTF-8 characters per component for either the pathname4 or component4 types. However, we could invent one that is appropriate for our implementation. Another possibility is to scrap all of this and print these pathnames in upper layers after a reasonable amount of sanity checking in the XDR layer. This would give us an opportunity to allocate a full buffer so that the whole pathname would be output via a single dprintk. Introduced by commit 7aaa0b3b: "NFSv4: convert fs-locations-components to conform to RFC3530," (June 9, 2006). Signed-off-by:
-
