- 06 Jun, 2014 4 commits
-
-
J. Bruce Fields authored
This constant has the wrong value. And we don't use it. And it's been removed from the 4.2 spec anyway. Signed-off-by:J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: -
J. Bruce Fields authored
While we're here, let's kill off a couple of the read-side macros. Leaving the more complicated ones alone for now. Signed-off-by: -
J. Bruce Fields authored
The rpc code makes available to the NFS server an array of pages to encod into. The server represents its reply as an xdr buf, with the head pointing into the first page in that array, the pages ** array starting just after that, and the tail (if any) sharing any leftover space in the page used by the head. While encoding, we use xdr_stream->page_ptr to keep track of which page we're currently using. Currently we set xdr_stream->page_ptr to buf->pages, which makes the head a weird exception to the rule that page_ptr always points to the page we're currently encoding into. So, instead set it to buf->pages - 1 (the page actually containing the head), and remove the need for a little unintuitive logic in xdr_get_next_encode_buffer() and xdr_truncate_encode. Signed-off-by:
-
- 04 Jun, 2014 5 commits
-
-
Benny Halevy authored
We don't want the stateid to be found in the hash table before the delegation is granted. Currently this is protected by the client_mutex, but we want to break that up and this is a necessary step toward that goal. Signed-off-by:
Benny Halevy <bhalevy@primarydata.com> Signed-off-by:
-
Benny Halevy authored
...as the name is a bit more descriptive and we've started using it for other purposes. Signed-off-by:
-
Jeff Layton authored
The memset of resp in svc_process_common should ensure that these are already zeroed by the time they get here. Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
-
Jeff Layton authored
In the NFS4_OPEN_CLAIM_PREVIOUS case, we should only mark it confirmed if the nfs4_check_open_reclaim check succeeds. In the NFS4_OPEN_CLAIM_DELEG_PREV_FH and NFS4_OPEN_CLAIM_DELEGATE_PREV cases, I see no point in declaring the openowner confirmed when the operation is going to fail anyway, and doing so might allow the client to game things such that it wouldn't need to confirm a subsequent open with the same owner. Signed-off-by:
-
Benny Halevy authored
This fixes a bug in the handling of the fi_delegations list. nfs4_setlease does not hold the recall_lock when adding to it. The client_mutex is held, which prevents against concurrent list changes, but nfsd_break_deleg_cb does not hold while walking it. New delegations could theoretically creep onto the list while we're walking it there. Signed-off-by:
-
- 31 May, 2014 3 commits
-
-
Jeff Layton authored
The laundromat uses two variables to calculate when it should next run, but one is completely ignored at the end of the run. Merge the two and rename the variable to be more descriptive of what it does. Signed-off-by:
-
Jeff Layton authored
sparse says: CHECK fs/nfsd/nfs4xdr.c fs/nfsd/nfs4xdr.c:2043:1: warning: symbol 'nfsd4_encode_fattr' was not declared. Should it be static? Signed-off-by: -
Kinglong Mee authored
When debugging, rpc prints messages from dprintk(KERN_WARNING ...) with "^A4" prefixed, [ 2780.339988] ^A4nfsd: connect from unprivileged port: 127.0.0.1, port=35316 Trond tells, > dprintk != printk. We have NEVER supported dprintk(KERN_WARNING...) This patch removes using of dprintk with KERN_WARNING. Signed-off-by:
Kinglong Mee <kinglongmee@gmail.com> Signed-off-by:
-
- 30 May, 2014 28 commits
-
-
Christoph Hellwig authored
Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
Note nobody's ever noticed because the typical client probably never requests FILES_AVAIL without also requesting something else on the list. Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
ex_nflavors can't be negative number, just defined by uint32_t. Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
No need for a typedef wrapper for svc_export or svc_client, remove them. Signed-off-by:
-
Kinglong Mee authored
Commit 49b28684 ("nfsd: Remove deprecated nfsctl system call and related code") removed the only use of ipv6_addr_set_v4mapped(), so net/ipv6.h is unneeded now. Signed-off-by:
-
Kinglong Mee authored
Commit 8f6c5ffc ("kernel/groups.c: remove return value of set_groups") removed the last use of "ret". Signed-off-by:
-
Kinglong Mee authored
After commit 4c1e1b34 ("nfsd: Store ex_anon_uid and ex_anon_gid as kuids and kgids") using kuid/kgid for ex_anon_uid/ex_anon_gid, user_namespace.h is not needed. Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
If fsloc_parse() failed at kzalloc(), fs/nfsd/export.c 411 412 fsloc->locations = kzalloc(fsloc->locations_count 413 * sizeof(struct nfsd4_fs_location), GFP_KERNEL); 414 if (!fsloc->locations) 415 return -ENOMEM; svc_export_parse() will call nfsd4_fslocs_free() with fsloc->locations = NULL, so that, "kfree(fsloc->locations[i].path);" will cause a crash. If fsloc_parse() failed after that, fsloc_parse() will call nfsd4_fslocs_free(), and svc_export_parse() will call it again, so that, a double free is caused. This patch checks the fsloc->locations, and set to NULL after it be freed. Signed-off-by:
-
J. Bruce Fields authored
RPC_MAX_AUTH_SIZE is scattered around several places. Better to set it once in the auth code, where this kind of estimate should be made. And while we're at it we can leave it zero when we're not using krb5i or krb5p. Signed-off-by: -
J. Bruce Fields authored
And switch a couple other functions from the encode(&p,...) convention to the p = encode(p,...) convention mostly used elsewhere. Signed-off-by: -
J. Bruce Fields authored
Signed-off-by: -
J. Bruce Fields authored
Signed-off-by: -
J. Bruce Fields authored
These macros just obscure what's going on. Adopt the convention of the client-side code. Signed-off-by: -
J. Bruce Fields authored
encode_getattr, for example, can return nfserr_resource to indicate it ran out of buffer space. That's not a legal error in the 4.1 case. And in the 4.1 case, if we ran out of buffer space, we should have exceeded a session limit too. (Note in 1bc49d83 "nfsd4: fix nfs4err_resource in 4.1 case" we originally tried fixing this error return before fixing the problem that we could error out while we still had lots of available space. The result was to trade one illegal error for another in those cases. We decided that was helpful, so reverted the change in fc208d02, and are only reinstating it now that we've elimited almost all of those cases.) Signed-off-by:
-
J. Bruce Fields authored
I'm not sure why a client would want to stuff multiple reads in a single compound rpc, but it's legal for them to do it, and we should really support it. Signed-off-by: -
J. Bruce Fields authored
More cleanup, no change in functionality. Signed-off-by: -
J. Bruce Fields authored
Trivial cleanup, no change in functionality. Signed-off-by: -
J. Bruce Fields authored
The splice and readv cases are actually quite different--for example the former case ignores the array of vectors we build up for the latter. It is probably clearer to separate the two cases entirely. There's some code duplication between the split out encoders, but this is only temporary and will be fixed by a later patch. Signed-off-by: -
J. Bruce Fields authored
Signed-off-by: -
J. Bruce Fields authored
We currently allow only one read per compound, with operations before and after whose responses will require no more than about a page to encode. While we don't expect clients to violate those limits any time soon, this limitation isn't really condoned by the spec, so to future proof the server we should lift the limitation. At the same time we'd like to continue to support zero-copy reads. Supporting multiple zero-copy-reads per compound would require a new data structure to replace struct xdr_buf, which can represent only one set of included pages. So for now we plan to modify encode_read() to support either zero-copy or non-zero-copy reads, and use some heuristics at the start of the compound processing to decide whether a zero-copy read will work. This will allow us to support more exotic compounds without introducing a performance regression in the normal case. Later patches handle those "exotic compounds", this one just makes sure zero-copy is turned off in those cases. Signed-off-by: -
J. Bruce Fields authored
Otherwise a following patch would turn off all 4.1 zero-copy reads. Signed-off-by: -
J. Bruce Fields authored
We plan to use this estimate to decide whether or not to allow zero-copy reads. Currently we're assuming all getattr's are a page, which can be both too small (ACLs e.g. may be arbitrarily long) and too large (after an upcoming read patch this will unnecessarily prevent zero copy reads in any read compound also containing a getattr). Signed-off-by: -
J. Bruce Fields authored
There's no advantage to this zero-copy-style readlink encoding, and it unnecessarily limits the kinds of compounds we can handle. (In practice I can't see why a client would want e.g. multiple readlink calls in a comound, but it's probably a spec violation for us not to handle it.) Signed-off-by: -
J. Bruce Fields authored
As long as we're here, let's enforce the protocol's limit on the number of directory entries to return in a readdir. I don't think anyone's ever noticed our lack of enforcement, but maybe there's more of a chance they will now that we allow larger readdirs. Signed-off-by:
-
