Re: [PATCH v3] err.h: allow IS_ERR_VALUE to handle properly more types

[Arnd Bergmann]

On Thursday 04 February 2016 10:59:31 Andrew Morton wrote:
> On Thu, 04 Feb 2016 13:40:38 +0100 Arnd Bergmann <arnd@xxxxxxxx> wrote:
> 
> > diff --git a/include/linux/err.h b/include/linux/err.h
> > index b7d4a9ff6342..bd4936a2c352 100644
> > --- a/include/linux/err.h
> > +++ b/include/linux/err.h
> > @@ -18,9 +18,7 @@
> >  
> >  #ifndef __ASSEMBLY__
> >  
> > -#define IS_ERR_VALUE(x) ((typeof(x))(-1) <= 0 \
> > -                             ? unlikely((x) <= -1) \
> > -                             : unlikely((x) >= (typeof(x))-MAX_ERRNO))
> > +#define IS_ERR_VALUE(x)      (unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
> >  
> >  static inline void * __must_check ERR_PTR(long error)
> >  {
> > 
> > 
> > I'm not sure if the cast to 'unsigned long long' might cause less
> > efficient code to be generated by gcc. I would hope that it is smart
> > enough to not actually extend shorter variables to 64 bit before
> > doing the comparison but I have not checked yet.
> 
> I did a quick test with i386 on drivers/nvmem/core.o.  The patch takes
> the text size from 9098 bytes to 9133.  That file has 11 instances of
> IS_ERR_VALUE().  

This seems to be because it brings back the logic to what it was before
in case of 'int' arguments. I checked the assembly output and found mine
to be identical to v4.4 in this case:

	 text    data     bss     dec     hex filename
v4.4	 9942    1872    2856   14670    394e drivers/nvmem/core.o
a.hajda  9922    1872    2856   14650    393a drivers/nvmem/core.o
arnd	 9942    1872    2856   14670    394e drivers/nvmem/core.o

Andrzej's version is a little shorter on ARM because in case of signed numbers
it only checks for negative values, rather than checking for values in the
[-MAX_ERRNO..-1] range. I think the original behavior is more logical
in this case, and my version restores it.

Looking at drivers/char/mem.o, which had an actual bug that was fixed by
Andrzej's patch, the output with my version and his is identical (failing
an lseek on /dev/mem to offset 0xfffffffffffffe00 or higher, instead of
failing for offset 0x00000000fffffe00-0x00000000ffffffff).

	Arnd