Re: arch/arm64/kernel/signal.c:1046:36: sparse: sparse: cast removes address space '__user' of expression

[Mark Brown]

On Mon, Dec 09, 2024 at 03:37:23PM +0000, Catalin Marinas wrote:
> On Mon, Dec 09, 2024 at 12:47:33PM +0800, kernel test robot wrote:

> > eaf62ce1563b85 Mark Brown      2024-10-01  1014       unsigned long __user *gcspr_el0;
> 
> I think we should keep this as u64 since it's a sysreg.

Do you mean pointer to u64 or plain u64?  The value we get from the
sysreg is a pointer so it makes the uses of the value clearer if we keep
it as a pointer in C code, it seems to be defeating the point of doing
static analysis to discard the pointerness to make it happier.

> > eaf62ce1563b85 Mark Brown      2024-10-01  1050  	put_user_gcs(0, (__user void*)gcspr_el0, &ret);

> We need a cast here if we are to go with u64 gcspr_el0 (it wasn't needed
> before, not sure why it was cast to void *).

It'll have been cast to void * to add the __user at some point before
the __user annotation got added to the variable declaration.

> > eaf62ce1563b85 Mark Brown      2024-10-01  1051  	if (ret != 0)
> > eaf62ce1563b85 Mark Brown      2024-10-01  1052  		return -EFAULT;
> > eaf62ce1563b85 Mark Brown      2024-10-01  1053  
> > eaf62ce1563b85 Mark Brown      2024-10-01  1054  	write_sysreg_s(gcspr_el0 + 1, SYS_GCSPR_EL0);

> And this would be +8 I guess.

The variable is a pointer so we're doing pointer arithmetic here not
working directly with the value, unless we change the value to be purely
a u64 with no pointer in which case we would need the case above.  The
whole shambles with u64 vs unsigned long and pointer vs absolute numbers
in all the code that deals with userspace is really unhelpful :(

Attachment: signature.asc
Description: PGP signature