Re: [PATCH] spi: Fix per-cpu stats access on 32 bit systems

From: Nícolas F. R. A. Prado
Date: Thu Jun 09 2022 - 17:08:33 EST


On Thu, Jun 09, 2022 at 02:13:34PM +0200, David Jander wrote:
> On 32 bit systems, the following kernel BUG is hit:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
> caller is debug_smp_processor_id+0x18/0x24
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc1-00001-g6ae0aec8a366 #181
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Backtrace:
> dump_backtrace from show_stack+0x20/0x24
> r7:81024ffd r6:00000000 r5:81024ffd r4:60000013
> show_stack from dump_stack_lvl+0x60/0x78
> dump_stack_lvl from dump_stack+0x14/0x1c
> r7:81024ffd r6:80f652de r5:80bec180 r4:819a2500
> dump_stack from check_preemption_disabled+0xc8/0xf0
> check_preemption_disabled from debug_smp_processor_id+0x18/0x24
> r8:8119b7e0 r7:81205534 r6:819f5c00 r5:819f4c00 r4:c083d724
> debug_smp_processor_id from __spi_sync+0x78/0x220
> __spi_sync from spi_sync+0x34/0x4c
> r10:bb7bf4e0 r9:c083d724 r8:00000007 r7:81a068c0 r6:822a83c0 r5:c083d724
> r4:819f4c00
> spi_sync from spi_mem_exec_op+0x338/0x370
> r5:000000b4 r4:c083d910
> spi_mem_exec_op from spi_nor_read_id+0x98/0xdc
> r10:bb7bf4e0 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:82358040
> r4:819f7c40
> spi_nor_read_id from spi_nor_detect+0x38/0x114
> r7:82358040 r6:00000000 r5:819f7c40 r4:819f7c40
> spi_nor_detect from spi_nor_scan+0x11c/0xbec
> r10:bb7bf4e0 r9:00000000 r8:00000000 r7:c083da4c r6:00000000 r5:00010101
> r4:819f7c40
> spi_nor_scan from spi_nor_probe+0x10c/0x2d0
> r10:bb7bf4e0 r9:bb7bf4d0 r8:00000000 r7:819f4c00 r6:00000000 r5:00000000
> r4:819f7c40
>
> per-cpu access needs to be guarded against preemption.
>
> Fixes: 6598b91b5ac3 ("spi: spi.c: Convert statistics to per-cpu u64_stats_t")
> Reported-by: Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx>
> Signed-off-by: David Jander <david@xxxxxxxxxxx>

Hi, the issue isn't 32-bit specific. I'm seeing it on an aarch64 machine
(mt8192-asurada-spherion) running next-20220609.

The fix did work for me, so

Tested-by: Nícolas F. R. A. Prado <nfraprado@xxxxxxxxxxxxx>

Thanks!
Nícolas