- 20 Oct, 2020 1 commit
-
-
Roberto Bergantinos Corpas authored
Its possible that using AUTH_SYS and mountd manage-gids option a user may hit the 8k RPC channel buffer limit. This have been observed on field, causing unanswered RPCs on clients after mountd fails to write on channel : rpc.mountd[11231]: auth_unix_gid: error writing reply Userland nfs-utils uses a buffer size of 32k (RPC_CHAN_BUF_SIZE), so lets match those two. Signed-off-by:
Roberto Bergantinos Corpas <rbergant@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com>
-
- 16 Oct, 2020 3 commits
-
-
Dan Aloni authored
This was discovered using O_DIRECT at the client side, with small unaligned file offsets or IOs that span multiple file pages. Fixes: e248aa7b ("svcrdma: Remove max_sge check at connect time") Signed-off-by:
Dan Aloni <dan@kernelim.com> Signed-off-by:
-
Tom Rix authored
Because every path through nfs4_find_file()'s switch does an explicit return, the break is not needed. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Artur Molchanov authored
Fix returning value for sysctl sunrpc.transports. Return error code from sysctl proc_handler function proc_do_xprt instead of number of the written bytes. Otherwise sysctl returns random garbage for this key. Since v1: - Handle negative returned value from memory_read_from_buffer as an error Signed-off-by:
Artur Molchanov <arturmolchanov@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- 12 Oct, 2020 5 commits
-
-
Anna Schumaker authored
Reply to the client with multiple hole and data segments. I use the result of the first vfs_llseek() call for encoding as an optimization so we don't have to immediately repeat the call. This also lets us encode any remaining reply as data if we get an unexpected result while trying to calculate a hole. Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Anna Schumaker authored
But only one of each right now. We'll expand on this in the next patch. Signed-off-by:
-
Anna Schumaker authored
However, we still only reply to the READ_PLUS call with a single segment at this time. Signed-off-by:
-
Anna Schumaker authored
This patch adds READ_PLUS support for returning a single NFS4_CONTENT_DATA segment to the client. This is basically the same as the READ operation, only with the extra information about data segments. Signed-off-by:
-
Chuck Lever authored
The original intent was presumably to reduce code duplication. The trade-off was: - No support for an NFSD proc function returning a non-success RPC accept_stat value. - No support for void NFS replies to non-NULL procedures. - Everyone pays for the deduplication with a few extra conditional branches in a hot path. In addition, nfsd_dispatch() leaves *statp uninitialized in the success path, unlike svc_generic_dispatch(). Address all of these problems by moving the logic for encoding the NFS status code into the NFS XDR encoders themselves. Then update the NFS .pc_func methods to return an RPC accept_stat value. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
- 02 Oct, 2020 13 commits
-
-
Chuck Lever authored
Refactor: Handle this NFS version-specific mapping in the only place where nfserr_wrongsec is generated. Signed-off-by:
-
Chuck Lever authored
Refactor: I'm about to change the return value from .pc_func. Clear the way by replacing the RETURN_STATUS() macro with logic that plants the status code directly into the response structure. Signed-off-by:
-
Chuck Lever authored
Remove special dispatcher logic for NFSv2 error responses. These are rare to the point of becoming extinct, but all NFS responses have to pay the cost of the extra conditional branches. With this change, the NFSv2 error cases now get proper xdr_ressize_check() calls. Signed-off-by:
-
Chuck Lever authored
nfsd_release_fhandle() assumes that rqstp->rq_resp always points to an nfsd_fhandle struct. In fact, no NFSv2 procedure uses struct nfsd_fhandle as its response structure. So far that has been "safe" to do because the res structs put the resp->fh field at that same offset as struct nfsd_fhandle. I don't think that's a guarantee, though, and there is certainly nothing preventing a developer from altering the fields in those structures. Signed-off-by:
-
Chuck Lever authored
Clean up: These are not used. Signed-off-by:
-
Chuck Lever authored
nfsd_dispatch() is a hot path. Ensure the compiler takes the processing of rare error cases out of line. Signed-off-by:
-
Chuck Lever authored
For consistency and code legibility, use a similar organization of variables as svc_generic_dispatch(). Signed-off-by:
-
Chuck Lever authored
Add a documenting comment for the function. Remove comments that simply describe obvious aspects of the code, but leave comments that explain the differences in processing of each NFS version. Signed-off-by:
-
Chuck Lever authored
Reorder the arms so the compiler places checks for the most frequent case first. Signed-off-by:
-
Chuck Lever authored
nfsd_dispatch() is a hot path. Let's optimize the XDR method calls for the by-far common case, which is that the XDR methods are indeed present. Signed-off-by:
-
Chuck Lever authored
Clean up: Follow-up on ten-year-old commit b9081d90 ("NFS: kill off complicated macro 'PROC'") by performing the same conversion in the NFSACL code. To reduce the chance of error, I copied the original C preprocessor output and then made some minor edits. Signed-off-by:
-
Chuck Lever authored
Clean up: Follow-up on ten-year-old commit b9081d90 ("NFS: kill off complicated macro 'PROC'") by performing the same conversion in the lockd code. To reduce the chance of error, I copied the original C preprocessor output and then made some minor edits. Signed-off-by:
-
Chuck Lever authored
There's no protection in nfsd_dispatch() against a NULL .pc_func helpers. A malicious NFS client can trigger a crash by invoking the unused/unsupported NFSv2 ROOT or WRITECACHE procedures. The current NFSD dispatcher does not support returning a void reply to a non-NULL procedure, so the reply to both of these is wrong, for the moment. Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 25 Sep, 2020 18 commits
-
-
J. Bruce Fields authored
Since only the v4 code cares about it, maybe it's better to leave rq_lease_breaker out of the common dispatch code? Signed-off-by: -
J. Bruce Fields authored
There are actually rare races where this is possible (e.g. if a new open intervenes between the read of i_writecount and the fi_fds). Signed-off-by: -
J. Bruce Fields authored
The nfsd open code has always kept separate read-only, read-write, and write-only opens as necessary to ensure that when a client closes or downgrades, we don't retain more access than necessary. Also, I didn't realize the cache behaved this way when I wrote 94415b06 "nfsd4: a client's own opens needn't prevent delegations". There I assumed fi_fds[O_WRONLY] and fi_fds[O_RDWR] would always be distinct. The violation of that assumption is triggering a WARN_ON_ONCE() and could also cause the server to give out a delegation when it shouldn't. Fixes: 94415b06 ("nfsd4: a client's own opens needn't prevent delegations") Tested-by:
-
J. Bruce Fields authored
Is it just me, or is the logic written in a slightly convoluted way? I find it a little easier to read this way. Signed-off-by: -
Xu Wang authored
seq_puts is a lot cheaper than seq_printf, so use that to print literal strings. Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Signed-off-by:
-
Rik van Riel authored
silence nfscache allocation warnings with kvzalloc Currently nfsd_reply_cache_init attempts hash table allocation through kmalloc, and manually falls back to vzalloc if that fails. This makes the code a little larger than needed, and creates a significant amount of serial console spam if you have enough systems. Switching to kvzalloc gets rid of the allocation warnings, and makes the code a little cleaner too as a side effect. Freeing of nn->drc_hashtbl is already done using kvfree currently. Signed-off-by:
Rik van Riel <riel@surriel.com> Signed-off-by:
-
Zheng Bin authored
Fixes coccicheck warning: fs/nfsd/nfs4proc.c:3234:5-29: WARNING: Comparison to bool Signed-off-by:
Zheng Bin <zhengbin13@huawei.com> Signed-off-by:
-
Chuck Lever authored
Squelch some sparse warnings: /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:1860:16: warning: incorrect type in assignment (different base types) /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:1860:16: expected int status /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:1860:16: got restricted __be32 /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:1862:24: warning: incorrect type in return expression (different base types) /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:1862:24: expected restricted __be32 /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:1862:24: got int status Signed-off-by:
-
Chuck Lever authored
Squelch some sparse warnings: /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4692:24: warning: incorrect type in return expression (different base types) /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4692:24: expected int /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4692:24: got restricted __be32 [usertype] /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4702:32: warning: incorrect type in return expression (different base types) /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4702:32: expected int /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4702:32: got restricted __be32 [usertype] /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4739:13: warning: incorrect type in assignment (different base types) /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4739:13: expected restricted __be32 [usertype] err /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4739:13: got int /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4891:15: warning: incorrect type in assignment (different base types) /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4891:15: expected unsigned int [assigned] [usertype] count /home/cel/src/linux/linux/fs/nfsd/nfs4xdr.c:4891:15: got restricted __be32 [usertype] Signed-off-by:
-
Chuck Lever authored
Squelch some sparse warnings: /home/cel/src/linux/linux/fs/nfsd/vfs.c:2264:13: warning: incorrect type in assignment (different base types) /home/cel/src/linux/linux/fs/nfsd/vfs.c:2264:13: expected int err /home/cel/src/linux/linux/fs/nfsd/vfs.c:2264:13: got restricted __be32 /home/cel/src/linux/linux/fs/nfsd/vfs.c:2266:24: warning: incorrect type in return expression (different base types) /home/cel/src/linux/linux/fs/nfsd/vfs.c:2266:24: expected restricted __be32 /home/cel/src/linux/linux/fs/nfsd/vfs.c:2266:24: got int err /home/cel/src/linux/linux/fs/nfsd/vfs.c:2288:13: warning: incorrect type in assignment (different base types) /home/cel/src/linux/linux/fs/nfsd/vfs.c:2288:13: expected int err /home/cel/src/linux/linux/fs/nfsd/vfs.c:2288:13: got restricted __be32 /home/cel/src/linux/linux/fs/nfsd/vfs.c:2290:24: warning: incorrect type in return expression (different base types) /home/cel/src/linux/linux/fs/nfsd/vfs.c:2290:24: expected restricted __be32 /home/cel/src/linux/linux/fs/nfsd/vfs.c:2290:24: got int err Signed-off-by:
-
Anna Schumaker authored
Reserving space for a large READ payload requires special handling when reserving space in the xdr buffer pages. One problem we can have is use of the scratch buffer, which is used to get a pointer to a contiguous region of data up to PAGE_SIZE. When using the scratch buffer, calls to xdr_commit_encode() shift the data to it's proper alignment in the xdr buffer. If we've reserved several pages in a vector, then this could potentially invalidate earlier pointers and result in incorrect READ data being sent to the client. I get around this by looking at the amount of space left in the current page, and never reserve more than that for each entry in the read vector. This lets us place data directly where it needs to go in the buffer pages. Signed-off-by:
-
Hou Tao authored
Now when a read delegation is given, two delegation related traces will be printed: nfsd_deleg_open: client 5f45b854:e6058001 stateid 00000030:00000001 nfsd_deleg_none: client 5f45b854:e6058001 stateid 0000002f:00000001 Although the intention is to let developers know two stateid are returned, the traces are confusing about whether or not a read delegation is handled out. So renaming trace_nfsd_deleg_none() to trace_nfsd_open() and trace_nfsd_deleg_open() to trace_nfsd_deleg_read() to make the intension clearer. The patched traces will be: nfsd_deleg_read: client 5f48a967:b55b21cd stateid 00000003:00000001 nfsd_open: client 5f48a967:b55b21cd stateid 00000002:00000001 Suggested-by:Hou Tao <houtao1@huawei.com> Signed-off-by:
-
J. Bruce Fields authored
This draft is an official RFC now. Signed-off-by: -
J. Bruce Fields authored
It struck me while watching Jon Corbet ask how to keep kernel Documentation up to date, that it might help if we were actually cc'd on Documentation/filesystems/nfs/ changes. Signed-off-by: -
Alex Dewar authored
In nfsd4_encode_listxattrs(), the variable p is assigned to at one point but this value is never used before p is reassigned. Fix this. Addresses-Coverity: ("Unused value") Signed-off-by:Alex Dewar <alex.dewar90@gmail.com> Signed-off-by:
-
Randy Dunlap authored
Drop duplicate words in net/sunrpc/. Also fix "Anyone" to be "Any one". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: "J. Bruce Fields" <bfields@fieldses.org> Cc: Chuck Lever <chuck.lever@oracle.com> Cc: linux-nfs@vger.kernel.org Signed-off-by:
-
Alex Dewar authored
Missing "is". Signed-off-by:
-
J. Bruce Fields authored
The delegation is no longer returnable, so I don't think there's much point retrying the recall. (I think it's worth asking why we even need separate CLOSED_DELEG and REVOKED_DELEG states. But treating them the same would currently cause nfsd4_free_stateid to call list_del_init(&dp->dl_recall_lru) on a delegation that the laundromat had unhashed but not revoked, incorrectly removing it from the laundromat's reaplist or a client's dl_recall_lru.) Signed-off-by:
-
