- 15 Nov, 2012 4 commits
-
-
Stanislav Kinsbursky authored
This hash holds nfs4_clients info, which are network namespace aware. So let's make it allocated per network namespace. Note: this hash is used only by legacy tracker. So let's allocate hash in tracker init. Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Stanislav Kinsbursky authored
And use it's net where possible. Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Stanislav Kinsbursky authored
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Commit bbf43dc8 "sunrpc/cache.h: replace simple_strtoul" introduced new range-checking which could cause get_int to fail on unsigned integers too large to be represented as an int. We could parse them as unsigned instead--but it turns out svcgssd is actually passing down "-1" in some cases. Which is perhaps stupid, but there's nothing we can do about it now. So just revert back to the previous "sloppy" behavior that accepts either representation. Cc: stable@vger.kernel.org Reported-by: Sven Geggus <lists@fuchsschwanzdomain.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 14 Nov, 2012 2 commits
-
-
Fengguang Wu authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Fengguang Wu authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 12 Nov, 2012 11 commits
-
-
Jeff Layton authored
The current code holds on to this list until nfsd is shut down, but it's never touched once the grace period ends. Release that memory back into the wild when the grace period ends. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
Remove the cl_recdir field from the nfs4_client struct. Instead, just compute it on the fly when and if it's needed, which is now only when the legacy client tracking code is in effect. The error handling in the legacy client tracker is also changed to handle the case where md5 is unavailable. In that case, we'll warn the admin with a KERN_ERR message and disable the client tracking. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
The current code requires that we md5 hash the name in order to store the client in the confirmed and unconfirmed trees. Change it instead to store the clients in a pair of rbtrees, and simply compare the cl_names directly instead of hashing them. This also necessitates that we add a new flag to the clp->cl_flags field to indicate which tree the client is currently in. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
When nfsd starts, the legacy reboot recovery code creates a tracking struct for each directory in the v4recoverydir. When the grace period ends, it basically does a "readdir" on the directory again, and matches each dentry in there to an existing client id to see if it should be removed or not. If the matching client doesn't exist, or hasn't reclaimed its state then it will remove that dentry. This is pretty inefficient since it involves doing a lot of hash-bucket searching. It also means that we have to keep relying on being able to search for a nfs4_client by md5 hashed cl_recdir name. Instead, add a pointer to the nfs4_client that indicates the association between the nfs4_client_reclaim and nfs4_client. When a reclaim operation comes in, we set the pointer to make that association. On gracedone, the legacy client tracker will keep the recdir around iff: 1/ there is a reclaim record for the directory ...and... 2/ there's an association between the reclaim record and a client record -- that is, a create or check operation was performed on the client that matches that directory. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
Later callers will need to make changes to the record. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
We'll need to be able to call this from nfs4recover.c eventually. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
Currently, it takes a client pointer, but later we're going to need to search for these records without knowing whether a matching client even exists. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
Let's shoot for removing the nfsdcld upcall in 3.10. Most likely, no one is actually using it so I don't expect this warning to fire often (except maybe on misconfigured systems). Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
The usermodehelper upcall program can then decide to use this info as a (one-way) transition mechanism to the new scheme. When a "check" upcall occurs and the client doesn't exist in the database, we can look to see whether the directory exists. If it does, then we'd add the client to the database, remove the legacy recdir, and return success to the kernel to allow the recovery to proceed. For gracedone, we simply pass the v4recovery "topdir" so that the upcall can clean it out prior to returning to the kernel. A module parm is also added to disable the legacy conversion if the admin chooses. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
First, try to use the new usermodehelper upcall. It should succeed or fail quickly, so there's little cost to doing so. If it fails, and the legacy tracking dir exists, use that. If it doesn't exist then fall back to using nfsdcld. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
Add a new client tracker upcall type that uses call_usermodehelper to call out to a program. This seems to be the preferred method of calling out to usermode these days for seldom-called upcalls. It's simple and doesn't require a running daemon, so it should "just work" as long as the binary is installed. The client tracking exit operation is also changed to check for a NULL pointer before running. The UMH upcall doesn't need to do anything at module teardown time. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 10 Nov, 2012 3 commits
-
-
Jeff Layton authored
Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Jeff Layton authored
If the credential save fails, then we'll leak our mnt_want_write_file reference. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 08 Nov, 2012 14 commits
-
-
J. Bruce Fields authored
For now this only adds support for AUTH_NULL. (Previously we assumed AUTH_UNIX.) We'll also need AUTH_GSS, which is trickier. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
I've found it confusing having the only references to nfsd4_do_callback_rpc() in a different file. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
This operation is mandatory for servers to implement. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
We're currently ignoring the callback security parameters specified in create_session, and just assuming the client wants auth_sys, because that's all the current linux client happens to care about. But this could cause us callbacks to fail to a client that wanted something different. For now, all we're doing is no longer ignoring the uid and gid passed in the auth_sys case. Further patches will add support for auth_null and gss (and possibly use more of the auth_sys information; the spec wants us to use exactly the credential we're passed, though it's hard to imagine why a client would care). Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Move the callback parsing into a separate function. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
NFSv4 shares the same struct file across multiple writes. (And we'd like NFSv2 and NFSv3 to do that as well some day.) So setting O_SYNC on the struct file as a way to request a synchronous write doesn't work. Instead, do a vfs_fsync_range() in that case. Reported-by: Peter Staubach <pstaubach@exagrid.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
I don't really see how you could claim to support nfsd and not support fsync somehow. And in practice a quick look through the exportable filesystems suggests the only ones without an ->fsync are read-only (efs, isofs, squashfs) or in-memory (shmem). Also, performing a write and then returning an error if the sync fails (as we would do here in the wgather case) seems unhelpful to clients. Also remove an incorrect comment. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
These conditions would indeed indicate bugs in the code, but if we want to hear about them we're likely better off warning and returning than immediately dying while holding file_lock_lock. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
In general I'd rather random bad behavior on the network won't trigger a printk. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
J. Bruce Fields authored
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Yanchuan Nian authored
The object type in the cache of lockowner_slab is wrong, and it is better to fix it. Cc: stable@vger.kernel.org Signed-off-by: Yanchuan Nian <ycnian@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Wei Yongjun authored
The variable inode is initialized but never used otherwise, so remove the unused variable. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
Namjae Jeon authored
This commit adds FILEID_INVALID = 0xff in fid_type to indicate invalid fid_type It avoids using magic number 255 Signed-off-by: Namjae Jeon <linkinjeon@gmail.com> Signed-off-by: Vivek Trivedi <vtrivedi018@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
-
- 20 Oct, 2012 6 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64Linus Torvalds authored
Pull arm64 fixes from Catalin Marinas: "Main changes: - AArch64 Linux compilation fixes following 3.7-rc1 changes (MODULES_USE_ELF_RELA, update_vsyscall() prototype) - Unnecessary register setting in start_thread() (thanks to Al Viro) - ptrace fixes" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64: arm64: fix alignment padding in assembly code arm64: ptrace: use HW_BREAKPOINT_EMPTY type for disabled breakpoints arm64: ptrace: make structure padding explicit for debug registers arm64: No need to set the x0-x2 registers in start_thread() arm64: Ignore memory blocks below PHYS_OFFSET arm64: Fix the update_vsyscall() prototype arm64: Select MODULES_USE_ELF_RELA arm64: Remove duplicate inclusion of mmu_context.h in smp.c
-
Marc Zyngier authored
An interesting effect of using the generic version of linkage.h is that the padding is defined in terms of x86 NOPs, which can have even more interesting effects when the assembly code looks like this: ENTRY(func1) mov x0, xzr ENDPROC(func1) // fall through ENTRY(func2) mov x0, #1 ret ENDPROC(func2) Admittedly, the code is not very nice. But having code from another architecture doesn't look completely sane either. The fix is to add arm64's version of linkage.h, which causes the insertion of proper AArch64 NOPs. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
-
Kees Cook authored
The min/max call needed to have explicit types on some architectures (e.g. mn10300). Use clamp_t instead to avoid the warning: kernel/sys.c: In function 'override_release': kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default] Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Ingo Molnar: "Assorted small fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf python: Properly link with libtraceevent perf hists browser: Add back callchain folding symbol perf tools: Fix build on sparc. perf python: Link with libtraceevent perf python: Initialize 'page_size' variable tools lib traceevent: Fix missed freeing of subargs in free_arg() in filter lib tools traceevent: Add back pevent assignment in __pevent_parse_format() perf hists browser: Fix off-by-two bug on the first column perf tools: Remove warnings on JIT samples for srcline sort key perf tools: Fix segfault when using srcline sort key perf: Require exclude_guest to use PEBS - kernel side enforcement perf tool: Precise mode requires exclude_guest
-
Arnaldo Carvalho de Melo authored
Namhyung Kim reported that the build fails with: GEN python/perf.so gcc: error: python_ext_build/tmp//../../libtraceevent.a: No such file or directory error: command 'gcc' failed with exit status 1 cp: cannot stat `python_ext_build/lib/perf.so': No such file or directory make: *** [python/perf.so] Error 1 We need to propagate the TE_PATH variable to the setup.py file. Reported-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Link: http://lkml.kernel.org/n/tip-8umiPbm4sxpknKivbjgykhut@git.kernel.org [ Fixed superfluous variable build error. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>
-