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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1JM6aW-0003aJ-Eh@pomaz-ex.szeredi.hu>
Date:	Mon, 04 Feb 2008 20:02:40 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	staubach@...hat.com
CC:	miklos@...redi.hu, linux-kernel@...r.kernel.org,
	linux-nfs@...r.kernel.org, akpm@...ux-foundation.org,
	trond.myklebust@....uio.no, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 2/3] enhanced syscall ESTALE error handling (v2)

> > I don't know what NFS does, but returning EINTR without actually
> > canceling an operation in the server is generally not a good idea.
> >
> >   
> 
> This is what NFS has been doing, for several decades, and no one
> has complained yet.

Is it really?  Man nfs says something quite different (emphasis mine):

   intr        If an NFS file operation has a *major timeout* and  it  is
               hard  mounted,  then  allow signals to interupt the file
               operation and cause it to return EINTR  to  the  calling
               program.  The *default* is to *not* allow file operations to
               be *interrupted*.

> >> Have you noticed another one?  I would be happy to chat with the
> >> developers for that file system to see if this support would
> >> negatively impact them.
> >>     
> >
> > Oh, I have no idea.  And I wouldn't want to do a full audit of all the
> > filesystems to find out.  But if you do, please go ahead.
> >
> >   
> 
> Well, you brought it up.  I thought that perhaps you had something
> other than FUD.

It's not FUD, it's being careful not to break an implementation when
changing an API in a backward incompatbile way.

> Please describe this real and existing fuse installation so that I can
> better understand the situation and the real requirements here.

I have already done so:

  "Also up till now, returning ESTALE in a fuse filesystem was a
   perfectly valid thing to do.  This patch changes the behavior of
   that rather drastically.  There might be installed systems that
   rely on current behavior, and we want to avoid breaking those on a
   kernel upgrade."

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/