Thread (77 messages) 77 messages, 12 authors, 2011-05-29
STALE5467d

[PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

From: peterz@infradead.org (Peter Zijlstra)
Date: 2011-05-13 12:39:30
Also in: linux-mips, linuxppc-dev

On Fri, 2011-05-13 at 14:26 +0200, Ingo Molnar wrote:
* Peter Zijlstra [off-list ref] wrote:
quoted
On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
quoted
        err = event_vfs_getname(result);
I really think we should not do this. Events like we have them should be 
inactive, totally passive entities, only observe but not affect execution 
(other than the bare minimal time delay introduced by observance).
Well, this patchset already demonstrates that we can use a single event 
callback for a rather useful purpose.
Can and should are two distinct things.
Either it makes sense to do, in which case we should share facilities as much 
as possible, or it makes no sense, in which case we should not merge it at all.
And I'm arguing we should _not_. Observing is radically different from
Affecting, at the very least the two things should have different
permission schemes. We should not confuse these two matters.
quoted
If you want another entity that is more active, please invent a new name for 
it and create a new subsystem for them, now you could have these active 
entities also have an (automatic) passive event side, but that's some detail.
Why should we have two callbacks next to each other:

	event_vfs_getname(result);
	result = check_event_vfs_getname(result);

if one could do it all?
Did you actually read the bit where I said that check_event_* (although
I still think that name sucks) could imply a matching event_*?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help