[Devel] Re: [PATCH 4/9] allow killing tasks in your own or child userns
Serge E. Hallyn
serge at hallyn.com
Wed Feb 23 16:48:18 PST 2011
Quoting Andrew Morton (akpm at linux-foundation.org):
> On Thu, 17 Feb 2011 15:03:25 +0000
> "Serge E. Hallyn" <serge at hallyn.com> wrote:
>
> > /*
> > + * called with RCU read lock from check_kill_permission()
> > + */
> > +static inline int kill_ok_by_cred(struct task_struct *t)
> > +{
> > + const struct cred *cred = current_cred();
> > + const struct cred *tcred = __task_cred(t);
> > +
> > + if (cred->user->user_ns == tcred->user->user_ns &&
> > + (cred->euid == tcred->suid ||
> > + cred->euid == tcred->uid ||
> > + cred->uid == tcred->suid ||
> > + cred->uid == tcred->uid))
> > + return 1;
> > +
> > + if (ns_capable(tcred->user->user_ns, CAP_KILL))
> > + return 1;
> > +
> > + return 0;
> > +}
>
> The compiler will inline this for us.
Is that simply true with everything (worth inlining) nowadays, or is
there a particular implicit hint to the compiler that'll make that
happen?
Not that I guess it's even particularly important in this case.
From: Serge E. Hallyn <serge.hallyn at canonical.com>
Date: Thu, 24 Feb 2011 00:26:02 +0000
Subject: [PATCH 1/2] userns: let compiler inline kill_ok_by_cred (per akpm)
Signed-off-by: Serge E. Hallyn <serge.hallyn at canonical.com>
---
kernel/signal.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index ffe4bdf..12702b4 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -638,7 +638,7 @@ static inline bool si_fromuser(const struct siginfo *info)
/*
* called with RCU read lock from check_kill_permission()
*/
-static inline int kill_ok_by_cred(struct task_struct *t)
+static int kill_ok_by_cred(struct task_struct *t)
{
const struct cred *cred = current_cred();
const struct cred *tcred = __task_cred(t);
--
1.7.0.4
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list