diff for duplicates of <1305294935.2466.64.camel@twins> diff --git a/a/1.txt b/N1/1.txt index 4ae82b6..1ff15fd 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,20 +2,22 @@ Cut the microblaze list since its bouncy. On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: > * Peter Zijlstra <peterz@infradead.org> wrote: -> +>=20 > > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: > > > I think the sanest semantics is to run all active callbacks as well. -> > > -> > > For example if this is used for three stacked security policies - as if 3 LSM -> > > modules were stacked at once. We'd call all three, and we'd determine that at -> > > least one failed - and we'd return a failure. -> > +> > >=20 +> > > For example if this is used for three stacked security policies - as = +if 3 LSM=20 +> > > modules were stacked at once. We'd call all three, and we'd determine= + that at=20 +> > > least one failed - and we'd return a failure.=20 +> >=20 > > But that only works for boolean functions where you can return the > > multi-bit-or of the result. What if you need to return the specific > > error code. -> +>=20 > Do you mean that one filter returns -EINVAL while the other -EACCES? -> +>=20 > Seems like a non-problem to me, we'd return the first nonzero value. Assuming the first is -EINVAL, what then is the value in computing the @@ -24,8 +26,9 @@ Assuming the first is -EINVAL, what then is the value in computing the > > Also, there's bound to be other cases where people will want to employ > > this, look at all the various notifier chain muck we've got, it already > > deals with much of this -- simply because users need it. -> -> Do you mean it would be easy to abuse it? What kind of abuse are you most +>=20 +> Do you mean it would be easy to abuse it? What kind of abuse are you most= +=20 > worried about? I'm not worried about abuse, I'm saying that going by the existing @@ -35,25 +38,27 @@ undesired. > > Then there's the whole indirection argument, if you don't need > > indirection, its often better to not use it, I myself much prefer code > > to look like: -> > +> >=20 > > foo1(bar); > > foo2(bar); > > foo3(bar); -> > +> >=20 > > Than: -> > +> >=20 > > foo_notifier(bar); -> > +> >=20 > > Simply because its much clearer who all are involved without me having > > to grep around to see who registers for foo_notifier and wth they do > > with it. It also makes it much harder to sneak in another user, whereas > > its nearly impossible to find new notifier users. -> > +> >=20 > > Its also much faster, no extra memory accesses, no indirect function > > calls, no other muck. -> -> But i suspect this question has been settled, given the fact that even pure -> observer events need and already process a chain of events? Am i missing +>=20 +> But i suspect this question has been settled, given the fact that even pu= +re=20 +> observer events need and already process a chain of events? Am i missing= +=20 > something about your argument? I'm saying that there's reasons to not use notifiers passive or active. diff --git a/a/content_digest b/N1/content_digest index c4e0a08..46f65e8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -13,63 +13,64 @@ "Subject\0Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering\0" "Date\0Fri, 13 May 2011 15:55:35 +0200\0" "To\0Ingo Molnar <mingo@elte.hu>\0" - "Cc\0James Morris <jmorris@namei.org>" - Will Drewry <wad@chromium.org> - linux-kernel@vger.kernel.org - Steven Rostedt <rostedt@goodmis.org> + "Cc\0linux-mips@linux-mips.org" + linux-sh@vger.kernel.org Frederic Weisbecker <fweisbec@gmail.com> - Eric Paris <eparis@redhat.com> - kees.cook@canonical.com - agl@chromium.org - Serge E. Hallyn <serge@hallyn.com> - Ingo Molnar <mingo@redhat.com> - Andrew Morton <akpm@linux-foundation.org> - Tejun Heo <tj@kernel.org> - Michal Marek <mmarek@suse.cz> + Heiko Carstens <heiko.carstens@de.ibm.com> Oleg Nesterov <oleg@redhat.com> - Roland McGrath <roland@redhat.com> - Jiri Slaby <jslaby@suse.cz> David Howells <dhowells@redhat.com> - Russell King <linux@arm.linux.org.uk> - Michal Simek <monstr@monstr.eu> - Ralf Baechle <ralf@linux-mips.org> - Benjamin Herrenschmidt <benh@kernel.crashing.org> Paul Mackerras <paulus@samba.org> - Martin Schwidefsky <schwidefsky@de.ibm.com> - Heiko Carstens <heiko.carstens@de.ibm.com> - linux390@de.ibm.com - Paul Mundt <lethal@linux-sh.org> - David S. Miller <davem@davemloft.net> - Thomas Gleixner <tglx@linutronix.de> + Eric Paris <eparis@redhat.com> H. Peter Anvin <hpa@zytor.com> + sparclinux@vger.kernel.org + Jiri Slaby <jslaby@suse.cz> + linux-s390@vger.kernel.org + Russell King <linux@arm.linux.org.uk> x86@kernel.org + James Morris <jmorris@namei.org> + Linus Torvalds <torvalds@linux-foundation.org> + Ingo Molnar <mingo@redhat.com> linux-arm-kernel <linux-arm-kernel@lists.infradead.org> - linux-mips@linux-mips.org + kees.cook@canonical.com + Serge E. Hallyn <serge@hallyn.com> + Steven Rostedt <rostedt@goodmis.org> + Martin Schwidefsky <schwidefsky@de.ibm.com> + Thomas Gleixner <tglx@linutronix.de> + Roland McGrath <roland@redhat.com> + Michal Marek <mmarek@suse.cz> + Michal Simek <monstr@monstr.eu> + Will Drewry <wad@chromium.org> linuxppc-dev@lists.ozlabs.org - linux-s390@vger.kernel.org - linux-sh@vger.kernel.org - sparclinux@vger.kernel.org - " Linus Torvalds <torvalds@linux-foundation.org>\0" + linux-kernel@vger.kernel.org + Ralf Baechle <ralf@linux-mips.org> + Paul Mundt <lethal@linux-sh.org> + Tejun Heo <tj@kernel.org> + linux390@de.ibm.com + Andrew Morton <akpm@linux-foundation.org> + agl@chromium.org + " David S. Miller <davem@davemloft.net>\0" "\00:1\0" "b\0" "Cut the microblaze list since its bouncy.\n" "\n" "On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:\n" "> * Peter Zijlstra <peterz@infradead.org> wrote:\n" - "> \n" + ">=20\n" "> > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:\n" "> > > I think the sanest semantics is to run all active callbacks as well.\n" - "> > > \n" - "> > > For example if this is used for three stacked security policies - as if 3 LSM \n" - "> > > modules were stacked at once. We'd call all three, and we'd determine that at \n" - "> > > least one failed - and we'd return a failure. \n" - "> > \n" + "> > >=20\n" + "> > > For example if this is used for three stacked security policies - as =\n" + "if 3 LSM=20\n" + "> > > modules were stacked at once. We'd call all three, and we'd determine=\n" + " that at=20\n" + "> > > least one failed - and we'd return a failure.=20\n" + "> >=20\n" "> > But that only works for boolean functions where you can return the\n" "> > multi-bit-or of the result. What if you need to return the specific\n" "> > error code.\n" - "> \n" + ">=20\n" "> Do you mean that one filter returns -EINVAL while the other -EACCES?\n" - "> \n" + ">=20\n" "> Seems like a non-problem to me, we'd return the first nonzero value.\n" "\n" "Assuming the first is -EINVAL, what then is the value in computing the\n" @@ -78,8 +79,9 @@ "> > Also, there's bound to be other cases where people will want to employ\n" "> > this, look at all the various notifier chain muck we've got, it already\n" "> > deals with much of this -- simply because users need it.\n" - "> \n" - "> Do you mean it would be easy to abuse it? What kind of abuse are you most \n" + ">=20\n" + "> Do you mean it would be easy to abuse it? What kind of abuse are you most=\n" + "=20\n" "> worried about?\n" "\n" "I'm not worried about abuse, I'm saying that going by the existing\n" @@ -89,25 +91,27 @@ "> > Then there's the whole indirection argument, if you don't need\n" "> > indirection, its often better to not use it, I myself much prefer code\n" "> > to look like:\n" - "> > \n" + "> >=20\n" "> > foo1(bar);\n" "> > foo2(bar);\n" "> > foo3(bar);\n" - "> > \n" + "> >=20\n" "> > Than:\n" - "> > \n" + "> >=20\n" "> > foo_notifier(bar);\n" - "> > \n" + "> >=20\n" "> > Simply because its much clearer who all are involved without me having\n" "> > to grep around to see who registers for foo_notifier and wth they do\n" "> > with it. It also makes it much harder to sneak in another user, whereas\n" "> > its nearly impossible to find new notifier users.\n" - "> > \n" + "> >=20\n" "> > Its also much faster, no extra memory accesses, no indirect function\n" "> > calls, no other muck.\n" - "> \n" - "> But i suspect this question has been settled, given the fact that even pure \n" - "> observer events need and already process a chain of events? Am i missing \n" + ">=20\n" + "> But i suspect this question has been settled, given the fact that even pu=\n" + "re=20\n" + "> observer events need and already process a chain of events? Am i missing=\n" + "=20\n" "> something about your argument?\n" "\n" "I'm saying that there's reasons to not use notifiers passive or active.\n" @@ -121,4 +125,4 @@ "\n" Anyway, I oppose for the existing events to gain an active role. -f2b938957cb16b3b07ad4d7664516337aca9a01b837545f394eafdff4c810c4f +8cb70a3ef046625125097ff90cec90d2ef305927c7b3ae1d2eb1e16d5eada35b
diff --git a/a/content_digest b/N2/content_digest index c4e0a08..0e0a14b 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -9,47 +9,10 @@ "ref\020110513125452.GD3924@elte.hu\0" "ref\01305292132.2466.26.camel@twins\0" "ref\020110513131800.GA7883@elte.hu\0" - "From\0Peter Zijlstra <peterz@infradead.org>\0" - "Subject\0Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering\0" + "From\0peterz@infradead.org (Peter Zijlstra)\0" + "Subject\0[PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering\0" "Date\0Fri, 13 May 2011 15:55:35 +0200\0" - "To\0Ingo Molnar <mingo@elte.hu>\0" - "Cc\0James Morris <jmorris@namei.org>" - Will Drewry <wad@chromium.org> - linux-kernel@vger.kernel.org - Steven Rostedt <rostedt@goodmis.org> - Frederic Weisbecker <fweisbec@gmail.com> - Eric Paris <eparis@redhat.com> - kees.cook@canonical.com - agl@chromium.org - Serge E. Hallyn <serge@hallyn.com> - Ingo Molnar <mingo@redhat.com> - Andrew Morton <akpm@linux-foundation.org> - Tejun Heo <tj@kernel.org> - Michal Marek <mmarek@suse.cz> - Oleg Nesterov <oleg@redhat.com> - Roland McGrath <roland@redhat.com> - Jiri Slaby <jslaby@suse.cz> - David Howells <dhowells@redhat.com> - Russell King <linux@arm.linux.org.uk> - Michal Simek <monstr@monstr.eu> - Ralf Baechle <ralf@linux-mips.org> - Benjamin Herrenschmidt <benh@kernel.crashing.org> - Paul Mackerras <paulus@samba.org> - Martin Schwidefsky <schwidefsky@de.ibm.com> - Heiko Carstens <heiko.carstens@de.ibm.com> - linux390@de.ibm.com - Paul Mundt <lethal@linux-sh.org> - David S. Miller <davem@davemloft.net> - Thomas Gleixner <tglx@linutronix.de> - H. Peter Anvin <hpa@zytor.com> - x86@kernel.org - linux-arm-kernel <linux-arm-kernel@lists.infradead.org> - linux-mips@linux-mips.org - linuxppc-dev@lists.ozlabs.org - linux-s390@vger.kernel.org - linux-sh@vger.kernel.org - sparclinux@vger.kernel.org - " Linus Torvalds <torvalds@linux-foundation.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Cut the microblaze list since its bouncy.\n" @@ -121,4 +84,4 @@ "\n" Anyway, I oppose for the existing events to gain an active role. -f2b938957cb16b3b07ad4d7664516337aca9a01b837545f394eafdff4c810c4f +3c0874802e9acfc4e933c81fd06cef80e525d4bb72d22fbdaa4945785af28f5e
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.