Re: [PATCH 1/2] CAPABILITIES: add cap_isequal helper

[Mateusz Guzik <mguzik@redhat.com>]

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@redhat.com>
> > ---
> >  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