LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Peter Staubach <staubach@redhat.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-nfs@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Trond Myklebust <trond.myklebust@fys.uio.no>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/3] enhanced ESTALE error handling
Date: Fri, 18 Jan 2008 13:37:57 -0500	[thread overview]
Message-ID: <20080118183757.GE15158@fieldses.org> (raw)
In-Reply-To: <4790EBF3.4060707@redhat.com>

On Fri, Jan 18, 2008 at 01:12:03PM -0500, Peter Staubach wrote:
> Chuck Lever wrote:
>> On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote:
>>> I can probably imagine a situation where the pathname resolution
>>> would never finish, but I am not sure that it could ever happen
>>> in nature.
>>
>> Unless someone is doing something malicious.  Or if the server is  
>> repeatedly returning ESTALE for some reason.
>>
>
> If the server is repeatedly returning ESTALE, then the pathname
> resolution will fail to make progress and give up, return ENOENT
> to the user level.
>
> A malicious user on the network can cause so many other problems
> than just something like this too.  But, in this case, the user
> would have to predict why and when the client was issuing a
> specific operation and know whether or not to return ESTALE.
> This seems quite far fetched and quite unlikely to me.

Any idea what the consequences would be in this case?  It at least
shouldn't overflow the stack, or freeze the whole machine (because it
spins indefinitely under some crucial lock), or panic, etc.  (If the one
filesystem just becomes unusable--well, fine, what better can you hope
for in the presence of a malicious server or network?)

--b.

  reply	other threads:[~2008-01-18 18:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 15:35 Peter Staubach
2008-01-18 15:46 ` J. Bruce Fields
2008-01-18 16:41 ` Chuck Lever
2008-01-18 16:55   ` Peter Staubach
2008-01-18 17:17     ` Chuck Lever
2008-01-18 17:30       ` Peter Staubach
2008-01-18 17:52         ` Chuck Lever
2008-01-18 18:12           ` Peter Staubach
2008-01-18 18:37             ` J. Bruce Fields [this message]
2008-01-18 19:12               ` Peter Staubach
2008-01-18 18:17         ` Chuck Lever
2008-02-01 20:57 ` [PATCH 0/3] enhanced ESTALE error handling (v2) Peter Staubach
2008-03-10 20:23   ` [PATCH 0/3] enhanced ESTALE error handling (v3) Peter Staubach
2008-03-10 22:42     ` Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080118183757.GE15158@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=akpm@linux-foundation.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=staubach@redhat.com \
    --cc=trond.myklebust@fys.uio.no \
    --subject='Re: [PATCH 0/3] enhanced ESTALE error handling' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).