Re: seekdir/readdir patch .. Call for Review.

On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote:
> if you are interested in readdir(3), seekdir(3) and telldir(3) then 
> you should look at
>    https://reviews.freebsd.org/D2410
> 
> this patches around a problem in seekdir() that breaks Samba.
> Seekdir(3) will not work as expected when files prior to the point of 
> interest in directory have been deleted since the directory was opened.
> 
> Windows clients using Samba cause both these things to happen, causing 
> the next readdir(3) after the bad seekdir(3) to skip some entries and 
> return the wrong file.
> 
> Samba only needs to step back a single directory entry in the case 
> where it reads an entry and then discovers it can't fit it into the 
> buffer it is sending to the windows client. It turns out we can 
> reliably cater to Samba's requirement because the "last returned 
> element" is always still in memory, so with a little care, we can
> set our filepointer back to it safely. (once)
> 
> seekdir and readdir (and telldir()) need a complete rewrite along with 
> getdirentries() but that is more than a small edit like this.

Can you explain your expectations from the whole readdir() vs. parallel
directory modifications interaction ?  From what I understood so far,
there is unlocked modification of the container and parallel iterator
over the same container.  IMO, in such situation, whatever tweaks you
apply to the iterator, it is still cannot be made reliable.

Before making single-purpose changes to the libc readdir and seekdir
code, or to the kernel code, it would be useful to state exact behaviour
of the dirent machinery we want to see. No, 'make samba works in my
situation' does not sound good enough.