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

[Miklos Szeredi <miklos@szeredi.hu>]

> > > 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.

Seems to me, the simple solution is to upgrade your glibc.

> > 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.

No it should _not_ fail, it should continue from the next _existing_
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?

No good.  Same problem if you move out then move back the entry.

> 
> > 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.

I understand, but I have glibc-2.3.5 which apparently doesn't seek
after readdir().

Miklos

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