Tejun Heo <[EMAIL PROTECTED]> writes: > Hello, > > Eric W. Biederman wrote: >>> More specifically, d_off field. It's a bit twisted. For the last >>> entry, filp->f_pos gets written into the field and gets wrapped while >>> being copied out to userland or in glibc. >> >> That could do it, and glibc is crunching it. Oh well, it is >> easy enough to avoid as long as our inode numbers are small which >> the idr allocator seems to ensure. > > Yeah, now I think about it. glibc throws out entries which don't fit in > the data structure specified by the called API, so it probably threw out > the last entry which has UINT_MAX in d_off which doesn't fit in the > readdir() return structure. Using INT_MAX should be just fine as IDA > always allocates the first empty slot. We can add paranoia check in ino > allocation path.
Sounds reasonable. Annoying but reasonable. Eric - 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/
