Re: Linux 2.6.36-rc7

[Eric Paris]

On Thu, 2010-10-07 at 18:15 +0100, Tvrtko Ursulin wrote:
> On Thursday 07 Oct 2010 17:10:46 Tvrtko Ursulin wrote:
> > On Wednesday 06 Oct 2010 22:45:13 Linus Torvalds wrote:

> Priority argument was dropped from the fanotify_init syscall, and since it is
> a syscall once released it is set in stone. Without the priority argument, how
> are multiple clients supposed to be ordered?
> 
> Co-existence between multiple clients was something which was supposed to be
> designed in from the start. Use cases like hierarchical storage management,
> anti-malware and content indexing should all be able to co-exist. Without a
> priority argument I do not see how it can be assured HSM sees the perm event
> before anti-malware, and content indexing after both of them? If there was any
> discussion about dropping priority I missed it. :(

Shit.  I'm trying to remember the logic.  hrmph....   You could have a
real interface issue....  Shit.  Let me think about it for an hour or
two.

Original idea of priorities was to allow multiple permissions decision
makers to co-exist without having the livelock problem of each trying to
grant and deny access to each other.  That was solved with the
O_NONOTIFY hack and I think the priority was then thought to be useless.
But you're absolutely right, it isn't useless if we consider that an HSM
might need to run first to make sure data exists on disk before an
indexer looks at the data.

I see two possibilities off the top of my head:

I could just slap an (unused) priority field onto the end of the
fanotify_init() syscall (assuming Linus doesn't murder me) so we can
build that support out with explicit priorities down the line, which I
think might be overkill, or

The other option (without breaking ABI as it stands today) is to define
some set of the fanotify_init() flags to be a priority field, we've got
32 bits and only use 2 of them so giving 4-8 bits of that as a priority
(next cycle) isn't an issue and can be easily backwards compatible.

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/