lkml.org 
[lkml]   [2008]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TALPA - a threat model? well sorta.
On Thu, 14 Aug 2008 10:12:13 -0400
Eric Paris <eparis@redhat.com> wrote:

> 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.

you could stretch things and report -EIO.

>
> The idea of multiple concurrent outstanding async notifications is
> going to be much more difficult to code, but hey, who am I to

well... do you really need a response?
you could just write it to a netlink socket...

> 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.

or fire-and-forget.
>
> 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?

I think we need to sort the interface issue on this for sure, and
probably from the start...

>


--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org


\
 
 \ /
  Last update: 2008-08-14 17:59    [W:0.124 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site