On Tue, 2008-08-05 at 11:27 -0700, Arjan van de Ven wrote:
Thankfully my implementation will invalidate that close time check and
caching result. It does the invalidating the same place we update mtime
and my understanding is that mmap has been updating mtime for quite a
while now. So again, it might not be perfect, but that situation should
get caught the next time around. I see close time checking as more of a
performance win and as a way to help close some of the length bad
information could exist than anything since its done in a non-blocking
path.
I think we all agree that open is the most interesting time for scanning
operations, but as Jonathan points out there is some value (even if not
perfect value) in looking at closes as well.
I actually already have an async non-blocking close notification built
in. Instead of waiting for a userspace response we just queue the close
notification and move along. When userspace gets around to it scanning
and allow/deny caching can then take place at a later time.
-Eric
--
