Re: [PATCH 4/9] allow killing tasks in your own or child userns

[Serge E. Hallyn]

Quoting Andrew Morton (akpm@xxxxxxxxxxxxxxxxxxxx):
> On Thu, 17 Feb 2011 15:03:25 +0000
> "Serge E. Hallyn" <serge@xxxxxxxxxx> 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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
---
 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

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