Return-Path: linux-nfs-owner@vger.kernel.org Received: from e7.ny.us.ibm.com ([32.97.182.137]:34099 "EHLO e7.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752363Ab1LIPY1 (ORCPT ); Fri, 9 Dec 2011 10:24:27 -0500 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 9 Dec 2011 10:24:27 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB9FNgqs2375784 for ; Fri, 9 Dec 2011 10:23:42 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB9FNguN017221 for ; Fri, 9 Dec 2011 10:23:42 -0500 From: Matthew Treinish To: linux-nfs@vger.kernel.org Cc: treinish@linux.vnet.ibm.com Subject: [PATCH/RFC v2 0/7] Volatile Filehandle Client-side Support Date: Fri, 9 Dec 2011 10:23:25 -0500 Message-Id: <1323444212-9855-1-git-send-email-treinish@linux.vnet.ibm.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: This patch series implements client side support for volatile file handle recovery (RFC 3530 section 4.2 and 4.3) with walk back using the dcache. To test the client you either need a server that supports volatile file handles or you can hard code the Linux server to output NFS4ERR_FHEXPIRED instead of NFSERR_STALE. The approach used here for recovery is to perform lookups for each file handle that receives a FHEXPIRED error. If the lookup also fails with FHEXPIRED using the dcache, it will recursively walk back to the root of the mount, and recover that using get_root. Simple testing has shown that this approach works and will correctly recover from a FHEXPIRED error code. However, the current implementation uses d_obtain_alias if a nfs4_proc function is only given an inode. When hardlinks are involved, this results in getting a path, but not necessarily a path which the user has access, which might lead to permission issues. As Trond pointed out on the first posting originally it was unable to recover from FHEXPIRED in state_recovery or rpciod since lookup operations started in either thread context would not have access to perform the lookup. So this version attempts to fix this by passing an rpc_cred to vfh_lookup. Then the credential is added to the lookup's rpc message so that the recovery lookup will have access. The only thing I am unsure of now is where I pass credential from for rpciod and state recovery contexts. v2: - Added rpc_cred passing to the vfh lookup and added handling of access errors on the lookup Matthew Treinish (7): New mount option for volatile filehandle recovery Added support for FH_EXPIRE_TYPE attribute. Add VFS objects from nfs4_proc calls into nfs4_exception. Save root file handle in nfs_server. Added VFH FHEXPIRED recovery functions. Perform recovery on both inodes for rename. Added error handling for NFS4ERR_FHEXPIRED fs/nfs/client.c | 3 + fs/nfs/getroot.c | 7 + fs/nfs/nfs4_fs.h | 3 + fs/nfs/nfs4proc.c | 287 ++++++++++++++++++++++++++++++++++++++++----- fs/nfs/nfs4xdr.c | 27 +++++ fs/nfs/super.c | 6 + include/linux/nfs_fs_sb.h | 2 + include/linux/nfs_mount.h | 1 + include/linux/nfs_xdr.h | 1 + 9 files changed, 308 insertions(+), 29 deletions(-) -- 1.7.4.4