- 31 Aug, 2015 5 commits
-
-
Kinglong Mee authored
Security label can be set in OPEN/CREATE request, nfsd should set the bitmask in word2 if setting success. Signed-off-by:
Kinglong Mee <kinglongmee@gmail.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com>
-
Kinglong Mee authored
According to rfc5661 18.16.4, "If EXCLUSIVE4_1 was used, the client determines the attributes used for the verifier by comparing attrset with cva_attrs.attrmask;" So, EXCLUSIVE4_1 also needs those bitmask used to store the verifier. Signed-off-by:
-
Kinglong Mee authored
The encode order should be as the bitmask defined order. Signed-off-by:
-
Kinglong Mee authored
Currently we'll respond correctly to a request for either FS_LAYOUT_TYPES or LAYOUT_TYPES, but not to a request for both attributes simultaneously. Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org Signed-off-by:
-
Kinglong Mee authored
After commit ae7095a7 (nfsd4: helper function for getting mounted_on ino) we ignore the return value from get_parent_attributes(). Also, the following FATTR4_WORD2_LAYOUT_BLKSIZE uses stat.blksize, so to avoid overwriting that, use an independent value for the parent's attributes. Signed-off-by:
-
- 13 Aug, 2015 7 commits
-
-
Andreas Gruenbacher authored
(espect -> expect) and (no -> know) Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
NLM locks don't conflict with NFSv4 share reservations, so we're not going to learn anything new by watiting for them. They do conflict with NFSv4 locks and with delegations. Signed-off-by: -
Jeff Layton authored
export.h refers to the pnfs_layouttype enum, which is defined there. Signed-off-by:
Jeff Layton <jeff.layton@primarydata.com> Reviewed-by:
-
Kinglong Mee authored
Switch using list_head for cache_head in cache_detail, it is useful of remove an cache_head entry directly from cache_detail. v8, using hash list, not head list Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
-
Kinglong Mee authored
Nfsd has implement a site of seq_operations functions as sunrpc's cache. Just exports sunrpc's codes, and remove nfsd's redundant codes. v8, same as v6 Signed-off-by:
-
Kinglong Mee authored
Cleanup. Just store cache_detail in seq_file's private, an allocated handle is redundant. v8, same as v6. Signed-off-by:
-
Kinglong Mee authored
According to Christoph's advice, this patch introduce a new helper nfsd4_cb_sequence_done() for processing more callback errors, following the example of the client's nfs41_sequence_done(). Signed-off-by:
-
- 10 Aug, 2015 22 commits
-
-
J. Bruce Fields authored
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Kinglong Mee authored
Commit 294ac32e "nfsd: protect clid and verifier generation with client_lock" moved gen_confirm() to gen_clid(). After that commit, setclientid will return a bad reply with all-zero verifier after copy_clid(). Signed-off-by:
-
Kinglong Mee authored
If using clientid_counter, it seems possible that gen_confirm could generate the same verifier for the same client in some situations. Add a new counter for client confirm verifier to make sure gen_confirm generates a different verifier on each call for the same clientid. Signed-off-by:
Jeff Layton <jlayton@poochiereds.net> Signed-off-by:
-
Kinglong Mee authored
v2, new helper nfs4_free_stateowner for freeing so_owner.data and sop Signed-off-by:
-
Kinglong Mee authored
Layout is a state resource, nfsd should check it too. v2, drop unneeded updating in nfsd4_renew() v3, fix compile error without CONFIG_NFSD_PNFS Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
Jeff Layton authored
In later patches, we'll want to be able to allocate and free svc_rqst structures without monkeying with the serv->sv_nrthreads refcount. Factor those pieces out of their respective functions. Signed-off-by:
Shirley Ma <shirley.ma@oracle.com> Acked-by:
Jeff Layton <jlayton@primarydata.com> Tested-by:
-
Jeff Layton authored
In later patches, we're going to need to allow code external to svc.c to figure out what pool_mode is in use. Move these definitions into svc.h to prepare for that. Also, make the svc_pool_map object available and exported so that other modules can peek in there to get insight into what pool mode is in use. Likewise, export svc_pool_map_get/put function to make it safe to do so. Signed-off-by:
-
Jeff Layton authored
Add an operation that will do setup of the service. In the case of a classic thread-based service that means starting up threads. In the case of a workqueue-based service, the setup will do something different. Signed-off-by:
Shirley Ma <shirliey.ma@oracle.com> Signed-off-by:
-
Jeff Layton authored
For now, all services use svc_xprt_do_enqueue, but once we add workqueue-based service support, we'll need to do something different. Signed-off-by:
-
Jeff Layton authored
...not technically an operation, but it's more convenient and cleaner to pass the module pointer in this struct. Signed-off-by:
-
Jeff Layton authored
Since we now have a container for holding svc_serv operations, move the sv_function into it as well. Signed-off-by:
-
Jeff Layton authored
In later patches we'll need to abstract out more operations on a per-service level, besides sv_shutdown and sv_function. Declare a new svc_serv_ops struct to hold these operations, and move sv_shutdown into this struct. Signed-off-by:
-
Chuck Lever authored
Both commit 0380a3f3 ("svcrdma: Add a separate "max data segs" macro for svcrdma") and commit 7e5be288 ("svcrdma: advertise the correct max payload") are incorrect. This commit reverts both changes, restoring the server's maximum payload size to 1MB. Commit 7e5be288 based the server's maximum payload on the _client's_ RPCRDMA_MAX_DATA_SEGS value. That was wrong. Commit 0380a3f3 tried to fix this so that the client maximum payload size could be raised without affecting the server, but managed to confuse matters more on the server side. More importantly, limiting the advertised maximum payload size was meant to be a workaround, not the actual fix. We need to revisit https://bugzilla.linux-nfs.org/show_bug.cgi?id=270 A Linux client on a platform with 64KB pages can overrun and crash an x86_64 NFS/RDMA server when the r/wsize is 1MB. An x86/64 Linux client seems to work fine using 1MB reads and writes when the Linux server's maximum payload size is restored to 1MB. BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=270 Fixes: 0380a3f3 ("svcrdma: Add a separate "max data segs" macro") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
- 31 Jul, 2015 1 commit
-
-
Jeff Layton authored
Currently, preprocess_stateid_op calls nfs4_check_olstateid which verifies that the open stateid corresponds to the current filehandle in the call by calling nfs4_check_fh. If the stateid is a NFS4_DELEG_STID however, then no such check is done. This could cause incorrect enforcement of permissions, because the nfsd_permission() call in nfs4_check_file uses current the current filehandle, but any subsequent IO operation will use the file descriptor in the stateid. Move the call to nfs4_check_fh into nfs4_check_file instead so that it can be done for all stateid types. Signed-off-by:
-
- 20 Jul, 2015 5 commits
-
-
Chuck Lever authored
Commit 0bf48289 ("svcrdma: refactor marshalling logic") removed the last call site for svc_rdma_fastreg(). Signed-off-by:
-
Chuck Lever authored
Kernel coding conventions frown upon having large nontrivial functions in header files, and the preference these days is to allow the compiler to make inlining decisions if possible. As these functions are re-homed into a .c file, be sure that comparisons with fields in struct rpcrdma_msg are with be32 constants. This is a refactoring change; no behavior change is intended. Signed-off-by:
-
Chuck Lever authored
The Linux NFS server returns garbage in the data payload of inline NFS/RDMA READ replies. These are READs of under 1000 bytes or so where the client has not provided either a reply chunk or a write list. The NFS server delivers the data payload for an NFS READ reply to the transport in an xdr_buf page list. If the NFS client did not provide a reply chunk or a write list, send_reply() is supposed to set up a separate sge for the page containing the READ data, and another sge for XDR padding if needed, then post all of the sges via a single SEND Work Request. The problem is send_reply() does not advance through the xdr_buf when setting up scatter/gather entries for SEND WR. It always calls dma_map_xdr with xdr_off set to zero. When there's more than one sge, dma_map_xdr() sets up the SEND sge's so they all point to the xdr_buf's head. The current Linux NFS/RDMA client always provides a reply chunk or a write list when performing an NFS READ over RDMA. Therefore, it does not exercise this particular case. The Linux server has never had to use more than one extra sge for building RPC/RDMA replies with a Linux client. However, an NFS/RDMA client _is_ allowed to send small NFS READs without setting up a write list or reply chunk. The NFS READ reply fits entirely within the inline reply buffer in this case. This is perhaps a more efficient way of performing NFS READs that the Linux NFS/RDMA client may some day adopt. Fixes: b432e6b3 ('svcrdma: Change DMA mapping logic to . . .') BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285Signed-off-by:
-
Shirley Ma authored
When removing underlying RDMA device, the rmmod will hang forever if there are any outstanding NFS/RDMA client mounts. The outstanding NFS/RDMA counts could also prevent the server from shutting down. Further debugging shows that the existing connections are not teared down and resource are not released when receiving RDMA_CM_EVENT_DEVICE_REMOVAL event. It seems the original code missing svc_xprt_put() in RDMA_CM_EVENT_REMOVAL event handler thus svc_xprt_free is never invoked to release the existing connection resources. The patch has been passed removing, adding device back and forth without stopping NFS/RDMA service. This will also allow a device to be unplugged and swapped out without shutting down NFS service. BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=252Signed-off-by:
-
Kinglong Mee authored
Signed-off-by:
-
