Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

[Dave Martin]

On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
> Hi Dave,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on arm64/for-next/core]
> [also build test WARNING on v4.20-rc6 next-20181214]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Dave-Martin/arm64-sve-UAPI-Disentangle-ptrace-h-from-sigcontext-h/20181214-225154
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.2.0 make.cross ARCH=arm64 
> 
> All warnings (new ones prefixed by >>):
> 
> >> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>

Since the new header is not meant to be included directly (and has a
guard to that effect), we don't strictly need to do anything here.

The way to include <asm/sve_context.h> in userspace is via
<asm/sigcontext.h> or <asm/ptrace.h>, both of which include
<linux/types.h> first.


Ironically, the type casts in sve_context.h that necessitate this
#include are probably not needed either.  I misunderstood the C
standard as indicating that if vq is a 16-bit type (which is the case
in some places) then the result of multiplying it by something may be
truncated to 16 bits.  This is not the case: the operands of * are
promoted at least to int first, and int is large enough to hold the
result of these multiplication for all valid vq values.

Removing the cast causes some otherwise __u32 expressions to become
ints (albeit with the same numeric value).

This affects semantics and code generation, so it's probably safest
not to touch these casts now given that they have already been exposed
as UAPI.

We should probably add the #include for cleanliness, but nothing should
break if we don't.

Cheers
---Dave