On Sun, Aug 24, 2008 at 10:20:52AM -0700, Linus Torvalds wrote: > > > On Sun, 24 Aug 2008, Al Viro wrote: > > > > One obvious note: that'll break old_readdir() on coda. There you need to > > change the existing check (you need to check buf.result, then ignore error > > unless buf.result ended up 0). > > Hmm? old_readdir() was the only one that I didn't change, because it > didn't need changing. It already ignores the return value of > "vfs_readdir()" entirely if it is positive or zero, and takes it from > buf.result. > > So old_readdir() literally doesn't care at all (and never has) whether a > ->readdir() function returns zero or a positive number. So changing coda > readdir() it to return zero _instead_ of a positive number makes > absolutely zero difference: old_readdir() will do the same thing > regardless. > > What am I missing? The fact that coda_readdir() will _not_ be returning 0 with your change when called with the arguments old_readdir() gives it? You'll get ret from filldir, i.e. what you'll normally see will be -EINVAL in case of fillonedir as callback. The normal sequence for old_readdir() is * call fillonedir on the current entry * have it bump ->result from 0 to 1 and return 0 * advance f_pos to the next entry * call fillonedir for it * have it see ->result != 0 and immediately bail out with -EINVAL * seeing a negative from the callback, foo_readdir does *not* advance f_pos this time and returns 0 (or at least something non-negative) * old_readdir() sees non-negative from vfs_readdir() and returns buf->result (i.e. 1) Now you've got vfs_readdir() returning -EINVAL in that scenario. See why old_readdir() needs an update too? It doesn't have the "OK, we'd already called its filldir, so bugger whatever had happened afterwards" logics - and it'll need it now. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
