Re: Kernel Compile in tmpfs crumples in 2.4.12 w/epoll patch

[Daniel Phillips]

On October 21, 2001 07:50 pm, Linus Torvalds wrote:
> In article <[e-mail]>,
> Larry McVoy  <[e-mail]> wrote:
> >
> >One of the engineers here has also seen this.  The root cause is that
> >readdir() is returning a file multiple times.  We've seen it on tmpfs.
> 
> Yes.  "tmpfs" will consider the position in the dentry lists to be the
> "offset" in the file, and if you remove files from the directory as you
> do a readdir(), you can get the same file twice (or you can fail to see
> files).
> 
> If somebody has a good suggestion for what could be used as a reasonably
> efficient "cookie" for virtual filesystems like tmpfs, speak up.  In the
> meantime, one way to _mostly_ avoid this should be to give a big buffer
> to readdir(), so that you end up getting all entries in one go (which
> will be protected by the semaphore inside the kernel), rather than
> having to do multiple readdir() calls. 

Assuming the "cookie" is an ordinal position in some predictable traversal of 
a directory, e.g., storage order, then the problem can be resolved with some 
cooperation from create and delete.  For a create, the cookie should be 
incremented if the position of the create is before the cookie.  Likewise, 
for a delete, the cookie should be decremented if the delete is before the 
cookie.

> (But we don't have an EOF cookie either, so..)
> 
> The logic, in case people care is just "dcache_readdir()" in
> fs/readdir.c, and that logic is used for all virtual filesystems, so
> fixing that will fix not just tmpfs..
> 
> Now, that said it might be worthwhile to be more robust on an
> application layer by simply just sorting the directory.  As you point
> out, NFS to some servers can have the same issues, for very similar
> reasons - on many filesystems a directory "position" is not a stable
> thing if you remove or add files at the same time.
> 
> So I would consider the current tmpfs behaviour a beauty wart and
> something to be fixed, but at the same time I also think you're
> depending on behaviour that is not in any way guaranteed, and I would
> argue that the tmpfs behaviour (while bad) is not actually strictly a
> bug but more a quality-of-implementation issue. 
> 
> 			Linus

--
Daniel