Re: TALPA - a threat model? well sorta.

[Eric Paris <eparis@redhat.com>]

On Wed, 2008-08-13 at 14:39 -0700, Arjan van de Ven wrote:
> On Wed, 13 Aug 2008 14:57:44 -0400
> Eric Paris <eparis@redhat.com> wrote:
> 
> > > for the open() case, I would argue that you don't need synchronous
> > > behavior as long as the read() case is synchronous. I can imagine
> > > that open() kicks off an async scan, and if it's done by the time
> > > the first read() happens, no blocking at all happens.
> > 
> > An interesting addition.  Trying to keep these queues of events gets
> > much more complex, but if people really think the open to read race is
> > that important I've always said it wasn't impossible to close.
> 
> it's not "just" about open-to-read race.
> it's about open being non-blocking, and if read is not immediate, never
> hitting the latency at all.
> 
> The real point is that "read" is the actual point  you want to
> intercept, not "open" (you even wrote that in your description).. so
> why not just do that ?
>  The open case then is just a performance optimization.

I've been thinking about this more over night.  I really like the idea
for perf reasons but I'm scared of programs not expecting and thus
poorly handling -EACCESS from read.  Every program ever is going to
expect that back from open, but once you have the fd open its not
common.  

The idea of multiple concurrent outstanding async notifications is going
to be much more difficult to code, but hey, who am I to complain.  We
could have outstanding async scanning requests for any number of writes,
any number of closes, and any number of opens all at the same time.  The
current interface believes that every request out requires a response
but this type of interface basically requires some sort of coalescing.

Would you be opposed to a first patch round that did blocking
enforcement on open like we have today and do sync scanning (blocking or
return EWOULDBLOCK) on read if needed due to concurrent writes?