- 01 Sep, 2015 1 commit
-
-
J. Bruce Fields authored
Somebody with a Solaris client was hitting this case. We haven't figured out why yet, and don't have a reproducer. Meanwhile Frank noticed that RFC 7530 actually recommends CLID_INUSE for this case. Unlikely to help the original reporter, but may as well fix it. Reported-by:
Frank Filz <ffilzlnx@mindspring.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com>
-
- 31 Aug, 2015 12 commits
-
-
Jeff Layton authored
It's possible that a DELEGRETURN could race with (e.g.) client expiry, in which case we could end up putting the delegation hash reference more than once. Have unhash_delegation_locked return a bool that indicates whether it was already unhashed. In the case of destroy_delegation we only conditionally put the hash reference if that returns true. The other callers of unhash_delegation_locked call it while walking list_heads that shouldn't yet be detached. If we find that it doesn't return true in those cases, then throw a WARN_ON as that indicates that we have a partially hashed delegation, and that something is likely very wrong. Tested-by:
Andrew W Elble <aweits@rit.edu> Tested-by:
Anna Schumaker <Anna.Schumaker@netapp.com> Signed-off-by:
Jeff Layton <jeff.layton@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jeff Layton authored
When an open or lock stateid is hashed, we take an extra reference to it. When we unhash it, we drop that reference. The code however does not properly account for the case where we have two callers concurrently trying to unhash the stateid. This can lead to list corruption and the hash reference being put more than once. Fix this by having unhash_ol_stateid use list_del_init on the st_perfile list_head, and then testing to see if that list_head is empty before releasing the hash reference. This means that some of the unhashing wrappers now become bool return functions so we can test to see whether the stateid was unhashed before we put the reference. Reported-by:
-
Pratyush Anand authored
`perf stat -e sunrpc:svc_xprt_do_enqueue true` results in Warning: unknown op '->' Warning: [sunrpc:svc_xprt_do_enqueue] unknown op '->' Similar warning for svc_handle_xprt as well. Actually TP_printk() should never dereference an address saved in the ring buffer that points somewhere in the kernel. There's no guarantee that that object still exists (with the exception of static strings). Therefore change all the arguments for TP_printk(), so that it references values existing in the ring buffer only. While doing that, also fix another possible bug when argument xprt could be NULL and TP_fast_assign() tries to access it's elements. Signed-off-by:
Pratyush Anand <panand@redhat.com> Reviewed-by:
Steven Rostedt <rostedt@goodmis.org> Cc: stable@vger.kernel.org Fixes: 83a712e0 "sunrpc: add some tracepoints around ..." Signed-off-by:
-
Jeff Layton authored
We can potentially have several nfs4_laundromat jobs running if there are multiple namespaces running nfsd on the box. Those are effectively separated from one another though, so I don't see any reason to serialize them. Also, create_singlethread_workqueue automatically adds the WQ_MEM_RECLAIM flag. Since we run this job on a timer, it's not really involved in any reclaim paths. I see no need for a rescuer thread. Signed-off-by:
-
Paul Gortmaker authored
These messages, combined with the backtrace they trigger, makes it seem like a serious problem, though a quick search shows distros marking it as a "won't fix" non-issue when the problem is reported by users. The backtrace is overkill, and only really manages to show that if you follow the code path, you can't really avoid it with bootargs or configuration settings in the container. Given that, lets tone it down a bit and get rid of the WARN severity, and the associated backtrace, so people aren't needlessly alarmed. Also, lets drop the split printk line, since they are grep unfriendly. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Randy Dunlap authored
Fix kernel-doc warnings in fs/locks.c: Warning(..//fs/locks.c:1577): No description found for parameter 'flags' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
J. Bruce Fields authored
Jeff has been doing a lot of development (including much of the state-locking rewrite just as one example) plus lots of review and other miscellaneous nfsd work, so let's acknowledge the status quo. I'll continue to be the one to send regular pull requests but Jeff will should be available to cover there occasionally too. Signed-off-by: -
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:
-
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:
-
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 20 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:
-
