On Mon, Feb 09, 2015 at 03:42:08PM -0800, j...@joshtriplett.org wrote:
> On Sun, Feb 08, 2015 at 10:05:25AM +0100, Geert Uytterhoeven wrote:
> > Thanks for the update!
> >
> > Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org>
>
> Thanks, Geert!
>
> On Sun, Feb 08, 2015 at 08:02:17PM -0800, Paul E. McKenney wrote:
> > I presume that v4 will have your Signed-off-by. ;-)
> >
> > Testing on my rcutorture setup uncovered an additional required dependency,
> > please see patch at the end of this email. With that fix, either separately
> > or merged into your patch:
> >
> > Tested-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> >
> > One question below about moving the definition of capable(). Either way:
>
> Answer below.
And that answer makes sense to me! Might be worth a mention in the
commit log (my apologies if it was mentioned and I missed it).
> > Reviewed-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
>
> Thanks, Paul!
>
> Based on this feedback, as well as the feedback from others on prior
> versions that has since been addressed, once there's a v4 with the
> changes suggested by Paul (and the signoff and acks/reviews added), I'm
> going to let this patch start cooking in linux-next (after the currently
> active merge window closes, of course). That'll help shake out any
> other potential missing dependencies or merge issues, and leave plenty
> of time for people to discuss it further before the subsequent merge
> window.
Makes sense to me! (/me suddenly remembers to take his post-merge-window
commits out of -next...)
Thanx, Paul
> > > --- a/kernel/capability.c
> > > +++ b/kernel/capability.c
> > > @@ -35,6 +35,7 @@ static int __init file_caps_disable(char *str)
> > > }
> > > __setup("no_file_caps", file_caps_disable);
> > >
> > > +#ifdef CONFIG_MULTIUSER
> > > /*
> > > * More recent versions of libcap are available from:
> > > *
> > > @@ -386,6 +387,24 @@ bool ns_capable(struct user_namespace *ns, int cap)
> > > }
> > > EXPORT_SYMBOL(ns_capable);
> > >
> > > +
> > > +/**
> > > + * capable - Determine if the current task has a superior capability in
> > > effect
> > > + * @cap: The capability to be tested for
> > > + *
> > > + * Return true if the current task has the given superior capability
> > > currently
> > > + * available for use, false if not.
> > > + *
> > > + * This sets PF_SUPERPRIV on the task if the capability is available on
> > > the
> > > + * assumption that it's about to be used.
> > > + */
> > > +bool capable(int cap)
> > > +{
> > > + return ns_capable(&init_user_ns, cap);
> > > +}
> > > +EXPORT_SYMBOL(capable);
> > > +#endif /* CONFIG_MULTIUSER */
> > > +
> > > /**
> > > * file_ns_capable - Determine if the file's opener had a capability in
> > > effect
> > > * @file: The file we want to check
> > > @@ -412,22 +431,6 @@ bool file_ns_capable(const struct file *file, struct
> > > user_namespace *ns,
> > > EXPORT_SYMBOL(file_ns_capable);
> > >
> > > /**
> > > - * capable - Determine if the current task has a superior capability in
> > > effect
> > > - * @cap: The capability to be tested for
> > > - *
> > > - * Return true if the current task has the given superior capability
> > > currently
> > > - * available for use, false if not.
> > > - *
> > > - * This sets PF_SUPERPRIV on the task if the capability is available on
> > > the
> > > - * assumption that it's about to be used.
> > > - */
> > > -bool capable(int cap)
> > > -{
> > > - return ns_capable(&init_user_ns, cap);
> > > -}
> > > -EXPORT_SYMBOL(capable);
> > > -
> > > -/**
> >
> > OK, I'll bite... Why are we moving capable()?
>
> Consolidating from two ifdef blocks to one, based on feedback on the
> initial version suggesting simplification of the ifdeffery.
>
> - Josh Triplett
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
