From: Miklos Szeredi Subject: Re: [PATCH 2/3] enhanced syscall ESTALE error handling (v2) Date: Fri, 01 Feb 2008 23:03:25 +0100 Message-ID: References: <4790C768.4080207@redhat.com> <47A387D4.70605@redhat.com> <47A39471.4010105@redhat.com> Cc: miklos@szeredi.hu, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, akpm@linux-foundation.org, trond.myklebust@fys.uio.no, linux-fsdevel@vger.kernel.org To: staubach@redhat.com Return-path: Received: from fxip-0047f.externet.hu ([88.209.222.127]:40482 "EHLO pomaz-ex.szeredi.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753202AbYBAWDn (ORCPT ); Fri, 1 Feb 2008 17:03:43 -0500 In-reply-to: <47A39471.4010105@redhat.com> (message from Peter Staubach on Fri, 01 Feb 2008 16:51:45 -0500) Sender: linux-nfs-owner@vger.kernel.org List-ID: > > This doesn't apply to -mm, because the ro-mounts stuff touches a lot > > of the same places as this patch. You probably need to rebase this on > > top of those changes. > > > > > >> This patch adds handling for the error, ESTALE, to the system > >> calls which take pathnames as arguments. The algorithm used > >> is to detect that an ESTALE error has occurred during an > >> operation subsequent to the lookup process and then to unwind > >> appropriately and then to perform the lookup process again. > >> Eventually, either the lookup process will return an error > >> or a valid dentry/inode combination and then operation can > >> succeed or fail based on its own merits. > >> > > > > If a broken NFS server or FUSE filesysem keeps returning ESTALE, this > > goes into an infinite loop. How are we planning to deal with that? > > > > > > Would you describe the situation that would cause the kernel to > go into an infinite loop, please? The patch basically does: do { ... error = inode->i_op->foo() ... } while (error == ESTALE); What is the guarantee, that ->foo() will not always return ESTALE? Miklos