Re: [RFC,PATCH] libfs dcache_readdir() and dcache_dir_lseek() bugfix

[jblunck]

On Fri, Nov 04, Miklos Szeredi wrote:

> > As I said: "Old glibc implementations (e.g. glibc-2.2.5) are
> > lseeking after every call to getdents() ..."
> 
> Hmm, why would it do that?  This seems like it's glibc being stupid.
> 

Well, glibc is that stupid and triggers the bug.

> That said, you are right that the libfs readdir implementation is not
> strictly standards conforming.  But neither is your patch: this
> algorithm will break if the entry at the current position is removed
> and then a new entry with the same name is created.

True. Seeking to that offset should at least fail and shouldn't stop at the
new entry. But SuSV3 says that the offset given by telldir() is valid until
the next rewinddir().  This is no problem for directories that can only grow.
I tried to implement some kind of deferred dput'ing of the d_child's but that
was too hackish and was wasting memory. So the best thing I can do now is fail
if someone wants to seek to an offset of an already unlinked file.

So I can include the inode number in the hashing process somehow. Any ideas on
that one?

> Unfortunately I can't since I don't have such old glibc.

The testcase is similar to what "rm *" with the old glibc would do. It just
a testcase to show where the problem is.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/