From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.7.10-1.3.2 Description of problem: -------- Original Message -------- Subject: [NFS] [PATCH] NFS/RPC/GSS - oops in gss_pipe_release() Date: Fri, 16 Sep 2005 13:40:15 -0400 From: Steve Dickson <SteveD> To: nfs.net During some recent debugging I found that an oops can occur in gss_pipe_release() because the client handle that is being passed in has already been freed. The scenario is as follows: root# mount -o sec=krb5 server:/export /mnt/export user$ ls /mnt/export (which hangs because user does not have the correct credentials) root# reboot The oops occurs when the /mnt/export filesystem is unmounted. The reason being is gss_pipe_release() was already called when the ls process was killed. The stack dump of the ls process was: [<e09dda84>] gss_pipe_release+0x74/0xd8 [auth_rpcgss] [<e0a045c0>] rpc_pipe_release+0xa5/0xb9 [sunrpc] [<c015a9d6>] __fput+0x55/0x100 [<c0159626>] filp_close+0x59/0x5f [<c012363f>] put_files_struct+0x57/0xc0 [<c0124255>] do_exit+0x227/0x3de [<c01244fa>] sys_exit_group+0x0/0xd [<c02d120b>] syscall_call+0x7/0xb So when the rpc_shutdown_client code is called via the umount: [<e09dda84>] gss_pipe_release+0x74/0xd8 [auth_rpcgss] [<e0a0447c>] rpc_close_pipes+0x80/0x9a [sunrpc] [<e0a04bb0>] rpc_depopulate+0xfb/0x142 [sunrpc] [<c01651bc>] cached_lookup+0xf/0x56 [<c0166410>] __lookup_hash+0x46/0x89 [<e0a05005>] rpc_rmdir+0x5a/0x89 [sunrpc] [<e09fcede>] rpcauth_free_credcache+0x87/0xd0 [sunrpc] [<e09f8431>] rpc_destroy_client+0x70/0xa4 [sunrpc] [<e09f8421>] rpc_destroy_client+0x60/0xa4 [sunrpc] [<e09f83ba>] rpc_shutdown_client+0xd1/0xd8 [sunrpc] [<c011e586>] default_wake_function+0x0/0xc [<e0aefe75>] nfs_kill_super+0x38/0x63 [nfs] the client handle (which is in the rpc_inode) passed to gss_pipe_release() has already been freeded. It appears from other places in the code (namely rpc_close_pipes()) that the only way to invalidate an rpc_inode is to set the ops pointer to NULL which is what the attached patch does. = Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. root# mount -o sec=krb5 server:/export /mnt/export 2. user$ ls /mnt/export (which hangs because user does not have the correct credentials) 3. root# reboot Actual Results: system oops Expected Results: the ls should fail with Permission denied Additional info:
Created attachment 119195 [details] Proposed patch
*** This bug has been marked as a duplicate of 171112 ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0132.html