On Fri, 18 Jul 2025 at 15:48, Linus Torvalds torvalds@linux-foundation.org wrote:
And while looking at this, I think we have a similar mis-feature / bug on x86 too: the unsafe_put_user() macro does exactly that cast:
#define unsafe_put_user(x, ptr, label) \ __put_user_size((__typeof__(*(ptr)))(x), ..
and I think that cast is wrong.
I wonder if it's actively hiding some issue with unsafe_put_user(), or if I'm just missing something.
... and I decided to try to look into it by just removing the cast.
And yes indeed, there's a reason for the cast - or at least it's hiding problems:
arch/x86/kernel/signal_64.c:128: unsafe_put_user(fpstate, (unsigned long __user *)&sc->fpstate, Efault);
arch/x86/kernel/signal_64.c:188: unsafe_put_user(ksig->ka.sa.sa_restorer, &frame->pretcode, Efault);
arch/x86/kernel/signal_64.c:332: unsafe_put_user(restorer, (unsigned long __user *)&frame->pretcode, Efault);
The one on line 188 at least makes some sense. The other ones are literally hiding the fact that we explicitly cast things to the wrong pointer.
I suspect it's just very old historical "we have been lazy and mixing 'unsigned long' and 'pointer value'" issues.
Oh well. None of these are actual *bugs*, they are more just ugly. And the cast that is hiding this ugliness might be hiding other things.
Not worth the churn at least late in the release cycle, but one of those "this might be worth cleaning up some day" issues.
Linus