Re: [PATCH 2/3] enhanced syscall ESTALE error handling (v2)

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Miklos Szeredi <miklos@...>
Cc: <linux-kernel@...>, <linux-nfs@...>, <akpm@...>, <trond.myklebust@...>, <linux-fsdevel@...>
Date: Friday, February 1, 2008 - 6:30 pm

Miklos Szeredi wrote:

You skimmed over some stuff, like the pathname lookup component
contained in the first set of dots...

I can't guarantee that ->foo() won't always return ESTALE.

That said, the loop is not unbreakable.  At least for NFS, a signal
to the process will interrupt the loop because the error returned
will change from ESTALE to EINTR.

These changes include the base assumption that the components of
the underlying file system are basically reliable, that there is
a way to deal with bugs and/or malicious entities in the short
term, and that these things will be dealt with appropriately
in the longer term.

The short term resolution is a signal.  The longer term fix is
to hunt down the bug or the malicious entity and either make it
go away or fence it off via some security measure or another to
prevent it from causing another problem.

If the underlying file system is the type that could potentially
return ESTALE, then it needs to be aware of the system architecture
and handle things appropriately.

    Thanx...

       ps
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 2/3] enhanced ESTALE error handling, Peter Staubach, (Fri Jan 18, 11:36 am)
[PATCH 2/3] enhanced syscall ESTALE error handling (v2), Peter Staubach, (Fri Feb 1, 4:57 pm)
[PATCH 2/3] enhanced syscall ESTALE error handling (v3), Peter Staubach, (Mon Mar 10, 4:23 pm)
Re: [PATCH 2/3] enhanced syscall ESTALE error handling (v2), Peter Staubach, (Fri Feb 1, 6:30 pm)