> > > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
