avoiding stat() races (Was: RE: Samba login)

Kenichi Okuyama okuyamak at dd.iij4u.or.jp
Fri Nov 10 02:53:59 GMT 2000

Dear Timothy,

>>>>> "CTD" == Cole, Timothy D <timothy_d_cole at md.northgrum.com> writes:
CTD> 	The essential problem here is that the verification of the statcache
CTD> entry and the intended action really ought to be atomic (as you point out)
CTD> -- but to do that, the statcache is going to need to "know" what needs to be
CTD> done with the file once it is found.

Why try to keep interface so less?

"statcache" is really some sort of  OBJECT. It have data of their
own, and since so, have multiple way of accessing them. What you're
trying to do is give parameter to the Object so that interface will
call different method. That's what you're really doing.



and let each parameter be same as that of dos_open etc. that we're
using now ( well, you can add one extra parameter, "pointer to
statcache" as means of object, if you wish ).

Let "StatCache" take care of all the validness. Let him only return
the valid information( like valid file descriptor, valid stat
information, etc ). StatCache can now do lazy closing, sharing
information among processes, etc, without effecting what's outside.

These doesn't mean we should use OO-Language( to tell the truth, I
hate HARD OO Language with which requires compilation. I think that
hard OO works, but only when you're using interpreter, and when you
can accept that. Hard OO is easy in use, but will not give you code
performance ). But idea of Object Oriented * is quite useful in this
case, for encapsolation.

CTD> 	Incidentally, regarding the need you indicated for increased
CTD> resolution timestamps -- increasing timestamp resolution would only serve to
CTD> "shrink" the window wherein the stat information can be erroneously
CTD> identified as still valid.

You should rather say, current timestamp only serve to give you
information of "INVALIDNESS", like hash function.

CTD> 	Since this would be mucking about with the kernel and filesystem
CTD> layout anyway, I think an e.g. 32-bit "generation count" (not in the NFS
CTD> sense) on the inode, incremented with every modification would be a
CTD> preferable (although still not ideal) solution.

Well, what I ment as pico-sec is same thing. If you have accuracy of
pico-second, and if access to file is being serialized somewhere,
and as long as we do not have Peta-Hz order accessable HDD, we'll not
have same valud for any accession, at least, for changing.

What I belieave is, that we should have 256bits for timestamp.  128
for describing over dot seconds, 128bit for under dot second.  If
system time does not have accuracy of 128bits, like ... 30 bits for
example ... use 128-30=98bits for reference counter within that time

#32bits was not enough for over dot seconds. nano-sec is within our
# hand. So, we need at least 64 bits for over dots, and 64bits for 
# under dots, this is minimum. Biggest problem is that,
# accuracy of time is increasing in 10bits every 15 year or so.
# ( not as accurate as moore's law though )
# So, if we are to face that fact, 128bit as total for time
# treatment is not enough.

best regards,
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.

More information about the samba-technical mailing list