On Fri, Mar 13, 2015 at 10:02:46AM -0400, Paul Moore wrote:
> On Monday, March 09, 2015 09:35:46 PM Mateusz Guzik wrote:
> > Can be used to determine whether two given sets have the same
> > capabilities.
> >
> > Signed-off-by: Mateusz Guzik <mguzik@xxxxxxxxxx>
> > ---
> > include/linux/capability.h | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/include/linux/capability.h b/include/linux/capability.h
> > index af9f0b9..2fcf941 100644
> > --- a/include/linux/capability.h
> > +++ b/include/linux/capability.h
> > @@ -155,6 +155,16 @@ static inline int cap_isclear(const kernel_cap_t a)
> > return 1;
> > }
> >
> > +static inline int cap_isequal(const kernel_cap_t a, const kernel_cap_t b)
> > +{
> > + unsigned __capi;
> > + CAP_FOR_EACH_U32(__capi) {
> > + if (a.cap[__capi] != b.cap[__capi])
> > + return 0;
> > + }
> > + return 1;
> > +}
>
> I realize it is currently only a two pass loop so probably not that big of a
> deal, but couldn't you accomplish the same with a memcmp()? I suppose the
> above implementation might be faster than those architectures which use the
> generic memcmp() implementation, but I wonder if the arch-specific memcmp()
> implementations would be faster.
>
Well I did it this way for consistency with the rest of the file. Trying
to use memcpy with only 2 elements to compare may be a dubious
optimisation and would require providing additional macros for cap size.
As such, I would prefer to keep the loop as it is. This can be changed
should caps ever grow.
> Also, what is the main motivation for this patchset? Do you have a workload
> that is being hit hard by prepare_creds()?
>
It's just something I stumbled upon and decided to microoptimize (fwiw,
faccessat is called quite often, but not enough for this change to be
world-changing).
Given the triviality of the patch I figured it should be fine to do it.
--
Mateusz Guzik
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
