From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757525Ab2DYJli (ORCPT ); Wed, 25 Apr 2012 05:41:38 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:47253 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756636Ab2DYJle (ORCPT ); Wed, 25 Apr 2012 05:41:34 -0400 From: Miklos Szeredi To: Jeff Layton Cc: Peter Staubach , Steve Dickson , "linux-fsdevel\@vger.kernel.org" , "linux-nfs\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , "viro\@ZenIV.linux.org.uk" , "hch\@infradead.org" , "michael.brantley\@deshaw.com" , "sven.breuner\@itwm.fraunhofer.de" , "chuck.lever\@oracle.com" , "malahal\@us.ibm.com" , "bfields\@fieldses.org" , "trond.myklebust\@fys.uio.no" , "rees\@umich.edu" Subject: Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors from getattr call In-Reply-To: <20120424123413.17625d5d@tlielax.poochiereds.net> (Jeff Layton's message of "Tue, 24 Apr 2012 12:34:13 -0400") References: <1334316311-22331-1-git-send-email-jlayton@redhat.com> <1334749927-26138-1-git-send-email-jlayton@redhat.com> <20120420104055.511e15bc@tlielax.poochiereds.net> <4F91C49D.8070908@RedHat.com> <20120420171300.326d6e36@corrin.poochiereds.net> <4F956D5C.5050801@RedHat.com> <20120423113216.01992555@tlielax.poochiereds.net> <4F959A36.2080402@RedHat.com> <20120424105049.5ed96b40@tlielax.poochiereds.net> <87lillktv3.fsf@tucsk.pomaz.szeredi.hu> <20120424123413.17625d5d@tlielax.poochiereds.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Date: Wed, 25 Apr 2012 11:41:52 +0200 Message-ID: <87bomgkv1b.fsf@tucsk.pomaz.szeredi.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jeff Layton writes: >> And an audit would still not ensure safety against future additions of >> ESTALE. >> > > Well, nothing is safe from the future. It's incumbent upon us to review > patches and such before such breakage goes in. Good interfaces are safe against stupidity, and that very much applies to the kernel too. Review is not an excuse for bad interfaces. > But, let's say for the purposes of argument that we do have a fs (FUSE > or otherwise) that is persistently returning ESTALE on a lookup. Why > was Peter's check that we were making forward progress not enough to > guard against this problem? > > In particular, I'm talking about the code he added to link_path_walk in > this patch to check that the value of nd->path.dentry was changing: > > https://lkml.org/lkml/2008/3/10/266 > > It seems like that ought to be enough to alleviate your fears on this. > We could also check for fatal signals on each pass and that would allow > users to break out of the loop even when the underlying fs doesn't > handle signals properly. AFAICS that doesn't ensure progress, only change. It helps those cases which persistently return ESTALE, but not cases where there is change but no progress. E.g. it doesn't prevent DoS by a client doing renames over a directory in a tight loop. Thanks, Miklos From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miklos Szeredi Subject: Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors from getattr call Date: Wed, 25 Apr 2012 11:41:52 +0200 Message-ID: <87bomgkv1b.fsf@tucsk.pomaz.szeredi.hu> References: <1334316311-22331-1-git-send-email-jlayton@redhat.com> <1334749927-26138-1-git-send-email-jlayton@redhat.com> <20120420104055.511e15bc@tlielax.poochiereds.net> <4F91C49D.8070908@RedHat.com> <20120420171300.326d6e36@corrin.poochiereds.net> <4F956D5C.5050801@RedHat.com> <20120423113216.01992555@tlielax.poochiereds.net> <4F959A36.2080402@RedHat.com> <20120424105049.5ed96b40@tlielax.poochiereds.net> <87lillktv3.fsf@tucsk.pomaz.szeredi.hu> <20120424123413.17625d5d@tlielax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Staubach , Steve Dickson , "linux-fsdevel\@vger.kernel.org" , "linux-nfs\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , "viro\@ZenIV.linux.org.uk" , "hch\@infradead.org" , "michael.brantley\@deshaw.com" , "sven.breuner\@itwm.fraunhofer.de" , "chuck.lever\@oracle.com" , "malahal\@us.ibm.com" , "bfields\@fieldses.org" , "trond.myklebust\@fys.uio.no" , "rees\@umich.edu" To: Jeff Layton Return-path: In-Reply-To: <20120424123413.17625d5d-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org> (Jeff Layton's message of "Tue, 24 Apr 2012 12:34:13 -0400") Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org Jeff Layton writes: >> And an audit would still not ensure safety against future additions of >> ESTALE. >> > > Well, nothing is safe from the future. It's incumbent upon us to review > patches and such before such breakage goes in. Good interfaces are safe against stupidity, and that very much applies to the kernel too. Review is not an excuse for bad interfaces. > But, let's say for the purposes of argument that we do have a fs (FUSE > or otherwise) that is persistently returning ESTALE on a lookup. Why > was Peter's check that we were making forward progress not enough to > guard against this problem? > > In particular, I'm talking about the code he added to link_path_walk in > this patch to check that the value of nd->path.dentry was changing: > > https://lkml.org/lkml/2008/3/10/266 > > It seems like that ought to be enough to alleviate your fears on this. > We could also check for fatal signals on each pass and that would allow > users to break out of the loop even when the underlying fs doesn't > handle signals properly. AFAICS that doesn't ensure progress, only change. It helps those cases which persistently return ESTALE, but not cases where there is change but no progress. E.g. it doesn't prevent DoS by a client doing renames over a directory in a tight loop. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html