Date: Fri, 1 May 2015 19:17:42 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: seekdir/readdir patch .. Call for Review. Message-ID: <20150501161742.GW2390@kib.kiev.ua> In-Reply-To: <55432593.6050709@freebsd.org> References: <55432593.6050709@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150501161742.GW2390>