kernel/git/stable/linux.git/net/sunrpc, branch linux-2.6.32.y

SUNRPC: xs_reset_transport must mark the connection as disconnected

2015-12-05T23:49:08+00:00

commit 0c78789e3a030615c6650fde89546cadf40ec2cc upstream. In case the reconnection attempt fails. Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: add local variable xprt] Signed-off-by: Ben Hutchings (cherry picked from commit 9434e4855e90d2af3751cd93b47b4a3e40bc2dc1) Signed-off-by: Willy Tarreau

SUNRPC: Fix a memory leak in the backchannel code

2015-09-18T11:52:10+00:00

commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream. req->rq_private_buf isn't initialised when xprt_setup_backchannel calls xprt_free_allocation. Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines") Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit bd031759bcc0865938ecc52846a3f22f2a26ad8e) Signed-off-by: Willy Tarreau

kernel panic when mount NFSv4

2013-06-10T09:43:23+00:00

On Tue, 2010-12-14 at 16:58 +0800, Mi Jinlong wrote: > Hi, > > When testing NFSv4 at RHEL6 with kernel 2.6.32, I got a kernel panic > at NFS client's __rpc_create_common function. > > The panic place is: > rpc_mkpipe > __rpc_lookup_create() <=== find pipefile *idmap* > __rpc_mkpipe() <=== pipefile is *idmap* > __rpc_create_common() > ****** BUG_ON(!d_unhashed(dentry)); ****** *panic* > > It means that the dentry's d_flags have be set DCACHE_UNHASHED, > but it should not be set here. > > Is someone known this bug? or give me some idea? > > A reproduce program is append, but it can't reproduce the bug every time. > the export is: "/nfsroot *(rw,no_root_squash,fsid=0,insecure)" > > And the panic message is append. > > ============================================================================ > #!/bin/sh > > LOOPTOTAL=768 > LOOPCOUNT=0 > ret=0 > > while [ $LOOPCOUNT -ne $LOOPTOTAL ] > do > ((LOOPCOUNT += 1)) > service nfs restart > /usr/sbin/rpc.idmapd > mount -t nfs4 127.0.0.1:/ /mnt|| return 1; > ls -l /var/lib/nfs/rpc_pipefs/nfs/*/ > umount /mnt > echo $LOOPCOUNT > done > > =============================================================================== > Code: af 60 01 00 00 89 fa 89 f0 e8 64 cf 89 f0 e8 5c 7c 64 cf 31 c0 8b 5c 24 10 8b > 74 24 14 8b 7c 24 18 8b 6c 24 1c 83 c4 20 c3 <0f> 0b eb fc 8b 46 28 c7 44 24 08 20 > de ee f0 c7 44 24 04 56 ea > EIP:[] __rpc_create_common+0x8a/0xc0 [sunrpc] SS:ESP 0068:eccb5d28 > ---[ end trace 8f5606cd08928ed2]--- > Kernel panic - not syncing: Fatal exception > Pid:7131, comm: mount.nfs4 Tainted: G D -------------------2.6.32 #1 > Call Trace: > [] ? panic+0x42/0xed > [] ? oops_end+0xbc/0xd0 > [] ? do_invalid_op+0x0/0x90 > [] ? do_invalid_op+0x7f/0x90 > [] ? __rpc_create_common+0x8a/0xc0[sunrpc] > [] ? rpc_free_task+0x33/0x70[sunrpc] > [] ? prc_call_sync+0x48/0x60[sunrpc] > [] ? rpc_ping+0x4e/0x60[sunrpc] > [] ? rpc_create+0x38f/0x4f0[sunrpc] > [] ? error_code+0x73/0x78 > [] ? __rpc_create_common+0x8a/0xc0[sunrpc] > [] ? d_lookup+0x2a/0x40 > [] ? rpc_mkpipe+0x111/0x1b0[sunrpc] > [] ? nfs_create_rpc_client+0xb4/0xf0[nfs] > [] ? nfs_fscache_get_client_cookie+0x1d/0x50[nfs] > [] ? nfs_idmap_new+0x7b/0x140[nfs] > [] ? strlcpy+0x3a/0x60 > [] ? nfs4_set_client+0xea/0x2b0[nfs] > [] ? nfs4_create_server+0xac/0x1b0[nfs] > [] ? krealloc+0x40/0x50 > [] ? nfs4_remote_get_sb+0x6b/0x250[nfs] > [] ? kstrdup+0x3c/0x60 > [] ? vfs_kern_mount+0x69/0x170 > [] ? nfs_do_root_mount+0x6c/0xa0[nfs] > [] ? nfs4_try_mount+0x37/0xa0[nfs] > [] ? nfs4_validate_text_mount_data+-x7d/0xf0[nfs] > [] ? nfs4_get_sb+0x92/0x2f0 > [] ? vfs_kern_mount+0x69/0x170 > [] ? get_fs_type+0x32/0xb0 > [] ? do_kern_mount+0x3f/0xe0 > [] ? do_mount+0x2ef/0x740 > [] ? copy_mount_options+0xb0/0x120 > [] ? sys_mount+0x6e/0xa0 Hi, Does the following patch fix the problem? Cheers Trond -------------------------- SUNRPC: Fix a BUG in __rpc_create_common From: Trond Myklebust Mi Jinlong reports: When testing NFSv4 at RHEL6 with kernel 2.6.32, I got a kernel panic at NFS client's __rpc_create_common function. The panic place is: rpc_mkpipe __rpc_lookup_create() <=== find pipefile *idmap* __rpc_mkpipe() <=== pipefile is *idmap* __rpc_create_common() ****** BUG_ON(!d_unhashed(dentry)); ****** *panic* The test is wrong: we can find ourselves with a hashed negative dentry here if the idmapper tried to look up the file before we got round to creating it. Just replace the BUG_ON() with a d_drop(dentry). [2.6.32 background info from Jonathan below] > Hi Willy et al, > > Please consider > > beb0f0a9fba1 kernel panic when mount NFSv4, 2010-12-20 > > for application to kernel.org's 2.6.32.y and 2.6.34.y trees. The > patch was applied upstream during the 2.6.38 merge window, so newer > kernels don't need it. > > (Context: .) Tom Downes (cc-ed) > experienced the bug on a Debian kernel close to 2.6.32.58 and > confirmed that the patch doesn't seem to hurt. > > The patch is part of Fedora 13's 2.6.34-based and Fedora 14's > 2.6.35-based kernels[1]. It was also included in the RHEL kernel at > some point between 2.6.32-71.29.1.el6 and 2.6.32-131.0.15.el6[2]. > > Thoughts of all kinds welcome, as always. > > Regards, > Jonathan > > [1] https://bugzilla.redhat.com/673207 > [2] https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=8028cccdc4b1 Reported-by: Mi Jinlong Signed-off-by: Trond Myklebust (cherry picked from commit beb0f0a9fba1fa98b378329a9a5b0a73f25097ae) Cc: Jonathan Nieder Signed-off-by: Willy Tarreau

svcrpc: sends on closed socket should stop immediately

2012-10-07T21:38:23+00:00

commit f06f00a24d76e168ecb38d352126fd203937b601 upstream. svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply. However, the XPT_CLOSE won't be acted on immediately. Meanwhile other threads could send further replies before the socket is really shut down. This can manifest as data corruption: for example, if a truncated read reply is followed by another rpc reply, that second reply will look to the client like further read data. Symptoms were data corruption preceded by svc_tcp_sendto logging something like kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket Reported-by: Malahal Naineni Tested-by: Malahal Naineni Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping

2012-10-07T21:38:22+00:00

commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream. The rpc server tries to ensure that there will be room to send a reply before it receives a request. It does this by tracking, in xpt_reserved, an upper bound on the total size of the replies that is has already committed to for the socket. Currently it is adding in the estimate for a new reply *before* it checks whether there is space available. If it finds that there is not space, it then subtracts the estimate back out. This may lead the subsequent svc_xprt_enqueue to decide that there is space after all. The results is a svc_recv() that will repeatedly return -EAGAIN, causing server threads to loop without doing any actual work. Reported-by: Michael Tokarev Tested-by: Michael Tokarev Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

nfsd: don't allow zero length strings in cache_parse()

2012-10-07T21:37:37+00:00

commit 6d8d17499810479eabd10731179c04b2ca22152f upstream. There is no point in passing a zero length string here and quite a few of that cache_parse() implementations will Oops if count is zero. Signed-off-by: Dan Carpenter Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

SUNRPC: We must not use list_for_each_entry_safe() in rpc_wake_up()

2012-10-07T21:37:35+00:00

commit 540a0f7584169651f485e8ab67461fcb06934e38 upstream. The problem is that for the case of priority queues, we have to assume that __rpc_remove_wait_queue_priority will move new elements from the tk_wait.links lists into the queue->tasks[] list. We therefore cannot use list_for_each_entry_safe() on queue->tasks[], since that will skip these new tasks that __rpc_remove_wait_queue_priority is adding. Without this fix, rpc_wake_up and rpc_wake_up_status will both fail to wake up all functions on priority wait queues, which can result in some nasty hangs. Reported-by: Andy Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

rpc client can not deal with ENOSOCK, so translate it into ENOCONN

2012-02-13T19:28:49+00:00

commit 5fe46e9d733f19a880ef7e516002bd4c2b833e14 upstream. If NFSv4 client send a request before connect, or the old connection was broken because a ETIMEOUT error catched by call_status, ->send_request will return ENOSOCK, but rpc layer can not deal with it, so make sure ->send_request can translate ENOSOCK into ENOCONN. Signed-off-by: Bian Naimeng Signed-off-by: Trond Myklebust Cc: Chuck Lever Signed-off-by: Greg Kroah-Hartman

svcrpc: destroy server sockets all at once

2012-01-25T21:53:22+00:00

commit 2fefb8a09e7ed251ae8996e0c69066e74c5aa560 upstream. There's no reason I can see that we need to call sv_shutdown between closing the two lists of sockets. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

svcrpc: fix double-free on shutdown of nfsd after changing pool mode

2012-01-25T21:53:22+00:00

commit 61c8504c428edcebf23b97775a129c5b393a302b upstream. The pool_to and to_pool fields of the global svc_pool_map are freed on shutdown, but are initialized in nfsd startup only in the SVC_POOL_PERCPU and SVC_POOL_PERNODE cases. They *are* initialized to zero on kernel startup. So as long as you use only SVC_POOL_GLOBAL (the default), this will never be a problem. You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE. However, the following sequence events leads to a double-free: 1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE 2. start nfsd: both fields are initialized. 3. shutdown nfsd: both fields are freed. 4. set SVC_POOL_GLOBAL 5. start nfsd: the fields are left untouched. 6. shutdown nfsd: now we try to free them again. Step 4 is actually unnecessary, since (for some bizarre reason), nfsd automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman