[PATCH] profiling: fix sampling step on 64-bit big-endian systems

[PATCH] profiling: fix sampling step on 64-bit big-endian systems

[Avi Weiss]

read_profile() stores the sampling step in an unsigned long
but copies only four bytes to userspace. On 64-bit
big-endian systems (not common obviously), this copies
the upper 32 bits and discards teh rest, causing
/proc/profile to report zero for normal shift values.

Cast to unsigned int so we get the correct 4 bytes, while
keeping the shift calculation in unsigned long.

A small C reproducer under qemu-s390x reproduced this and
proved the fix works for prof_shift=2.

Fixes: 2d186afd04d6 ("profiling: fix shift-out-of-bounds bugs")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
---

 kernel/profile.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/profile.c b/kernel/profile.c
index 1fcf1adcf4eb0..e7defa90a34c9 100644
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -156,7 +156,7 @@ read_profile(struct file *file, char __user *buf, size_t count, loff_t *ppos)
 	unsigned long p = *ppos;
 	ssize_t read;
 	char *pnt;
-	unsigned long sample_step = 1UL << prof_shift;
+	unsigned int sample_step = (unsigned int)(1UL << prof_shift);
 
 	if (p >= (prof_len+1)*sizeof(unsigned int))
 		return 0;
-- 
2.43.0

Re: [PATCH] profiling: fix sampling step on 64-bit big-endian systems

[Bradley Morgan]

On 20 October 2026 11:12:24 BST, Avi Weiss <thnkslprpt@gmail.com> wrote:
>read_profile() stores the sampling step in an unsigned long
>but copies only four bytes to userspace. On 64-bit
>big-endian systems (not common obviously), this copies
>the upper 32 bits and discards teh rest, causing
>/proc/profile to report zero for normal shift values.
>
>Cast to unsigned int so we get the correct 4 bytes, while
>keeping the shift calculation in unsigned long.
>
>A small C reproducer under qemu-s390x reproduced this and
>proved the fix works for prof_shift=2.

If you wanna be 100% sure that this is regression free, you could test
building on all arches. Sometimes linking fails in cases.

>
>Fixes: 2d186afd04d6 ("profiling: fix shift-out-of-bounds bugs")
>Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
>---
>
> kernel/profile.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/kernel/profile.c b/kernel/profile.c
>index 1fcf1adcf4eb0..e7defa90a34c9 100644
>--- a/kernel/profile.c
>+++ b/kernel/profile.c
>@@ -156,7 +156,7 @@ read_profile(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> 	unsigned long p = *ppos;
> 	ssize_t read;
> 	char *pnt;
>-	unsigned long sample_step = 1UL << prof_shift;
>+	unsigned int sample_step = (unsigned int)(1UL << prof_shift);

But this would compile anyway.

Reviewed-by: Bradley Morgan <brads@mainlining.org>


> 
> 	if (p >= (prof_len+1)*sizeof(unsigned int))
> 		return 0;
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: [PATCH] profiling: fix sampling step on 64-bit big-endian systems

[Avi Weiss]

I'm happy to try it anyway - just so I know how for future patches.
I'll see how many I can run through before my laptop gives up ;-)

On Tue, 20 Oct 2026 at 18:07, Bradley Morgan <brads@mainlining.org> wrote:
>
> On 20 October 2026 11:12:24 BST, Avi Weiss <thnkslprpt@gmail.com> wrote:
> >read_profile() stores the sampling step in an unsigned long
> >but copies only four bytes to userspace. On 64-bit
> >big-endian systems (not common obviously), this copies
> >the upper 32 bits and discards teh rest, causing
> >/proc/profile to report zero for normal shift values.
> >
> >Cast to unsigned int so we get the correct 4 bytes, while
> >keeping the shift calculation in unsigned long.
> >
> >A small C reproducer under qemu-s390x reproduced this and
> >proved the fix works for prof_shift=2.
>
> If you wanna be 100% sure that this is regression free, you could test
> building on all arches. Sometimes linking fails in cases.
>
> >
> >Fixes: 2d186afd04d6 ("profiling: fix shift-out-of-bounds bugs")
> >Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
> >---
> >
> > kernel/profile.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/kernel/profile.c b/kernel/profile.c
> >index 1fcf1adcf4eb0..e7defa90a34c9 100644
> >--- a/kernel/profile.c
> >+++ b/kernel/profile.c
> >@@ -156,7 +156,7 @@ read_profile(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> >       unsigned long p = *ppos;
> >       ssize_t read;
> >       char *pnt;
> >-      unsigned long sample_step = 1UL << prof_shift;
> >+      unsigned int sample_step = (unsigned int)(1UL << prof_shift);
>
> But this would compile anyway.
>
> Reviewed-by: Bradley Morgan <brads@mainlining.org>
>
>
> >
> >       if (p >= (prof_len+1)*sizeof(unsigned int))
> >               return 0;
> >
>
> --- Thanks!
> "I'm not a very positive person" - Linus torvalds

Re: [PATCH] profiling: fix sampling step on 64-bit big-endian systems

[Bradley Morgan]

On 20 October 2026 17:47:22 BST, Avi Weiss <thnkslprpt@gmail.com> wrote:
>I'm happy to try it anyway - just so I know how for future patches.
>I'll see how many I can run through before my laptop gives up ;-)

sometimes the crux is for these kinds of patches something in some cryptic
arch gets messed up in vmlinux stage, odd right?

This *makes sense* for me, off the top of my head and thinking hard id say
this *shouldn't* do anything bad to a cryptic architecture, but I've been
shocked in the past.

>
>On Tue, 20 Oct 2026 at 18:07, Bradley Morgan <brads@mainlining.org> wrote:
>>
>> On 20 October 2026 11:12:24 BST, Avi Weiss <thnkslprpt@gmail.com> wrote:
>> >read_profile() stores the sampling step in an unsigned long
>> >but copies only four bytes to userspace. On 64-bit
>> >big-endian systems (not common obviously), this copies
>> >the upper 32 bits and discards teh rest, causing
>> >/proc/profile to report zero for normal shift values.
>> >
>> >Cast to unsigned int so we get the correct 4 bytes, while
>> >keeping the shift calculation in unsigned long.
>> >
>> >A small C reproducer under qemu-s390x reproduced this and
>> >proved the fix works for prof_shift=2.
>>
>> If you wanna be 100% sure that this is regression free, you could test
>> building on all arches. Sometimes linking fails in cases.
>>
>> >
>> >Fixes: 2d186afd04d6 ("profiling: fix shift-out-of-bounds bugs")
>> >Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
>> >---
>> >
>> > kernel/profile.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> >diff --git a/kernel/profile.c b/kernel/profile.c
>> >index 1fcf1adcf4eb0..e7defa90a34c9 100644
>> >--- a/kernel/profile.c
>> >+++ b/kernel/profile.c
>> >@@ -156,7 +156,7 @@ read_profile(struct file *file, char __user *buf,
>size_t count, loff_t *ppos)
>> >       unsigned long p = *ppos;
>> >       ssize_t read;
>> >       char *pnt;
>> >-      unsigned long sample_step = 1UL << prof_shift;
>> >+      unsigned int sample_step = (unsigned int)(1UL << prof_shift);
>>
>> But this would compile anyway.
>>
>> Reviewed-by: Bradley Morgan <brads@mainlining.org>
>>
>>
>> >
>> >       if (p >= (prof_len+1)*sizeof(unsigned int))
>> >               return 0;
>> >
>>
>> --- Thanks!
>> "I'm not a very positive person" - Linus torvalds
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: [PATCH] profiling: fix sampling step on 64-bit big-endian systems

[Andrew Morton]

On Tue, 20 Oct 2026 17:50:24 +0100 Bradley Morgan <brads@mainlining.org> wrote:

> On 20 October 2026 17:47:22 BST, Avi Weiss <thnkslprpt@gmail.com> wrote:
> >I'm happy to try it anyway - just so I know how for future patches.
> >I'll see how many I can run through before my laptop gives up ;-)
> 
> sometimes the crux is for these kinds of patches something in some cryptic
> arch gets messed up in vmlinux stage, odd right?
> 
> This *makes sense* for me, off the top of my head and thinking hard id say
> this *shouldn't* do anything bad to a cryptic architecture, but I've been
> shocked in the past.

OK, read_profile() makes me question my career choices.

It starts out with totally inappropriate type choices then bandaids
over that by typecasting just about every damn thing in there.  None of
it is commented, natch.

I'll grab Avi's fix for this merge window.  I persuaded the
coin-operated coding machine to generate a couple of patches to fix a
pre-existing thing and to clean up that code.  I'll send them
separately so Sashiko takes a look.  Please review.

Re: [PATCH] profiling: fix sampling step on 64-bit big-endian systems

[Avi Weiss]

FYI Bradley I left it running overnight and got these to compile successfully:
s390x
sparc64
powerpc64-be
x86_64
arm64
i386
powerpc64-le
mips
riscv64
loongarch
armhf
armel
alpha
arc
microblaze
xtensa
csky
um
nios2

These I couldn't get the toolchain settings right so they never started:
parisc64
m68k
sh
hexagon

On Wed, 21 Oct 2026 at 03:46, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 20 Oct 2026 17:50:24 +0100 Bradley Morgan <brads@mainlining.org> wrote:
>
> > On 20 October 2026 17:47:22 BST, Avi Weiss <thnkslprpt@gmail.com> wrote:
> > >I'm happy to try it anyway - just so I know how for future patches.
> > >I'll see how many I can run through before my laptop gives up ;-)
> >
> > sometimes the crux is for these kinds of patches something in some cryptic
> > arch gets messed up in vmlinux stage, odd right?
> >
> > This *makes sense* for me, off the top of my head and thinking hard id say
> > this *shouldn't* do anything bad to a cryptic architecture, but I've been
> > shocked in the past.
>
> OK, read_profile() makes me question my career choices.
>
> It starts out with totally inappropriate type choices then bandaids
> over that by typecasting just about every damn thing in there.  None of
> it is commented, natch.
>
> I'll grab Avi's fix for this merge window.  I persuaded the
> coin-operated coding machine to generate a couple of patches to fix a
> pre-existing thing and to clean up that code.  I'll send them
> separately so Sashiko takes a look.  Please review.