The following set of patches fix known issues with the 2.6.28-rc5 NFS client
code, and significantly enhance the support for NFSv4.
- linux-2.6.28-000-fixup_generic_match.dif:
-
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Wed, 19 Nov 2008 23:27:42 -0500
SUNRPC: Fix a performance regression in the RPC authentication code
Fix a regression reported by Max Kellermann whereby kernel profiling showed that his
clients were spending 45% of their time in rpcauth_lookup_credcache.
It turns out that although his processes had identical uid/gid/groups,
generic_match() was failing to detect this, because the task->group_info pointers
were not shared. This again lead to the creation of a huge number of identical
credentials at the RPC layer.
The regression is fixed by comparing the contents of task->group_info if the
actual pointers are not identical.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-001-convert_reclaimer_to_use_kthread.dif:
-
From: Jeff Layton <jlayton@redhat.com>
Date: Wed, 19 Nov 2008 23:27:43 -0500
lockd: convert reclaimer thread to kthread interface
My understanding is that there is a push to turn the kernel_thread interface into a
non-exported symbol and move all kernel threads to use the kthread API. This patch
changes lockd to use kthread_run to spawn the reclaimer thread.
I've made the assumption here that the extra module references taken when we spawn
this thread are unnecessary and removed them. I've also added a KERN_ERR printk that
pops if the thread can't be spawned to warn the admin that the locks won't be
reclaimed.
In the future, it would be nice to be able to notify userspace that locks have been
lost (probably by implementing SIGLOST), and adding some good policies about how long
we should reattempt to reclaim the locks.
Finally, I removed a comment about memory leaks that I believe is obsolete and added
a new one to clarify the result of sending a SIGKILL to the reclaimer thread. As best I
can tell, doing so doesn't actually cause a memory leak.
I consider this patch 2.6.29 material.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-002-rename_nfs_path_variable.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Wed, 19 Nov 2008 23:27:45 -0500
NFS: rename nfs_path variable
Clean up: I'm about to move the declaration of nfs_mount into fs/nfs/internal.h and
include it in fs/nfs/nfsroot.c. There's a conflicting definition of nfs_path in
fs/nfs/internal.h and fs/nfs/nfsroot.c, so rename the private one.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-003-move_declaration_of_nfs_mount_to_fs_nfs_internal_h.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Wed, 19 Nov 2008 23:27:46 -0500
NFS: Move declaration of nfs_mount() to fs/nfs/internal.h
Clean up: The nfs_mount() function is not to be used outside of the NFS client.
Move its public declaration to fs/nfs/internal.h.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-004-introduce_nfs_mount_info_struct_for_calling_nfs_mount.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Wed, 19 Nov 2008 23:27:47 -0500
NFS: introduce nfs_mount_info struct for calling nfs_mount()
Clean up: convert nfs_mount() to take a single data structure argument to make it
simpler to add more arguments.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-005-expand_flags_passed_to_nfs_create_rpc_client.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Wed, 19 Nov 2008 23:27:49 -0500
NFS: expand flags passed to nfs_create_rpc_client()
The nfs_create_rpc_client() function sets up an RPC client for an NFS mount point.
Add an option that allows it to set up an RPC transport from an unprivileged port.
Instead of having nfs_create_rpc_client()'s callers retain local knowledge about how
to set up an RPC client, create a couple of flag arguments to control the use of
RPC_CLNT_CREATE flags.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-006-move_nfs_server_flag_initialization.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Wed, 19 Nov 2008 23:27:50 -0500
NFS: move nfs_server flag initialization
Make it possible for the NFSv4 mount set up logic to pass mount option flags down
the stack to nfs_create_rpc_client().
This is immediately useful if we want NFS mount options to modulate settings of the
underlying RPC transport, but it may be useful at some later point if other parts of
the NFSv4 mount initialization logic want to know what the mount options are.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-007-add_no_resvport_mount_option.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Thu, 20 Nov 2008 14:46:16 -0500
NFS: add "[no]resvport" mount option
The standard default security setting for NFS is AUTH_SYS. An NFS client connects
to NFS servers via a privileged source port and a fixed standard destination port
(2049). The client sends raw uid and gid numbers to identify users making NFS
requests, and the server assumes an appropriate authority on the client has vetted
these values because the source port is privileged.
On Linux, by default in-kernel RPC services use a privileged port in the range
between 650 and 1023 to avoid using source ports of well- known IP services. Using
such a small range limits the number of NFS mount points and the number of unique NFS
servers to which a client can connect concurrently.
An NFS client can use unprivileged source ports to expand the range of source port
numbers, allowing more concurrent server connections and more NFS mount points.
Servers must explicitly allow NFS connections from unprivileged ports for this to
work.
In the past, bumping the value of the sunrpc.max_resvport sysctl on the client would
permit the NFS client to use unprivileged ports. Bumping this setting also changes the
maximum port number used by other in-kernel RPC services, some of which still required
a port number less than 1023.
This is exacerbated by the way source port numbers are chosen by the Linux RPC
client, which starts at the top of the range and works downwards. It means that
bumping the maximum means all RPC services requesting a source port will likely get an
unprivileged port instead of a privileged one.
Changing this setting effects all NFS mount points on a client. A sysadmin could
not selectively choose which mount points would use non-privileged ports and which
could not.
Lastly, this mechanism of expanding the limit on the number of NFS mount points was
entirely undocumented.
To address the need for the NFS client to use a large range of source ports without
interfering with the activity of other in-kernel RPC services, we introduce a new NFS
mount option. This option explicitly tells only the NFS client to use a non-privileged
source port when communicating with the NFS server for one specific mount point.
This new mount option is called "resvport," like the similar NFS mount option on
FreeBSD and Mac OS X. A sister patch for nfs-utils will be submitted that documents
this new option in nfs(5).
The default setting for this new mount option requires the NFS client to use a
privileged port, as before. Explicitly specifying the "noresvport" mount option allows
the NFS client to use an unprivileged source port for this mount point when connecting
to the NFS server port.
This mount option is supported only for text-based NFS mounts.
[ Sidebar: it is widely known that security mechanisms based on the use of
privileged source ports are ineffective. However, the NFS client can combine the use
of unprivileged ports with the use of secure authentication mechanisms, such as
Kerberos. This allows a large number of connections and mount points while ensuring a
useful level of security.
Eventually we may change the default setting for this option depending on the
security flavor used for the mount. For example, if the mount is using only AUTH_SYS,
then the default setting will be "resvport;" if the mount is using a strong security
flavor such as krb5, the default setting will be "noresvport." ]
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
[Trond.Myklebust@netapp.com: Fixed a bug whereby nfs4_init_client() was being called
with incorrect arguments.]
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-008-no_resvport_mount_option_changes_mountd_client_too.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Thu, 20 Nov 2008 14:46:18 -0500
NFS: "[no]resvport" mount option changes mountd client too
If the admin has specified the "noresvport" option for an NFS mount point, the
kernel's NFS client uses an unprivileged source port for the main NFS transport. The
kernel's mountd client should use an unprivileged port in this case as well.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
- linux-2.6.28-009-allow_lockd_requests_from_an_unprivileged_port.dif:
-
From: Chuck Lever <chuck.lever@oracle.com>
Date: Thu, 20 Nov 2008 14:46:19 -0500
NLM: allow lockd requests from an unprivileged port
If the admin has specified the "noresvport" option for an NFS mount point, the
kernel's NFS client uses an unprivileged source port for the main NFS transport. The
kernel's lockd client should use an unprivileged port in this case as well.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
![[TXT]](/icons/text.gif){kind=icon}
![[ ]](/icons/unknown.gif){kind=icon}