Marvell Kirkwood and the linux 7.1.5 kernel

[Arnd Bergmann]

On Mon, Aug 10, 2026, at 17:59, David Summers wrote:
> Hi All,
>
> I've an ancient nas I'm updating, that has Marvell Kirkwood core. I 
> recently updated to the 7.1.5 kernel, and now my kernel is hitting many 
> bugs, specifically:
>
>> [ 3.195064] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u4:1/49
>> [ 3.203374] caller is __flush_anon_page+0x28/0xd8
>> [ 3.208146] CPU: 0 UID: 0 PID: 49 Comm: kworker/u4:1 Not tainted 7.1.5-1-ARCH #3 PREEMPT 
>> [ 3.216370] Hardware name: Marvell Kirkwood (Flattened Device Tree)
>> [ 3.222666] Call trace: 
>> [ 3.222677] unwind_backtrace from show_stack+0x10/0x14
>> [ 3.230489] show_stack from dump_stack_lvl+0x38/0x48
>> [ 3.235573] dump_stack_lvl from check_preemption_disabled+0x104/0x118
>> [ 3.242139] check_preemption_disabled from __flush_anon_page+0x28/0xd8
>> [ 3.248791] __flush_anon_page from __get_user_pages+0x420/0x608
>> [ 3.254844] __get_user_pages from get_user_pages_remote+0xd0/0x404
>> [ 3.261148] get_user_pages_remote from get_arg_page+0x6c/0xec
>> [ 3.267025] get_arg_page from copy_string_kernel+0x98/0x194
>> [ 3.272720] copy_string_kernel from kernel_execve+0xa0/0x19c
>> [ 3.278501] kernel_execve from call_usermodehelper_exec_async+0x120/0x238
>> [ 3.285425] call_usermodehelper_exec_async from ret_from_fork+0x14/0x28
>> [ 3.292164] Exception stack(0xe0b2dfb0 to 0xe0b2dff8)
>> [ 3.297243] dfa0: 00000000 00000000 00000000 00000000
>> [ 3.305458] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> [ 3.313672] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> 
> And this bug gets hit multiple times for each command run.
>
> I've tracked smp_processor_id() to linux/arch/arm/include/asm/smp.h 
> which contains:
>
> #define raw_smp_processor_id() (current_thread_info()->cpu)

Since you confirmed that CONFIG_SMP is disabled, we can tell
that this is not the location that caused the BUG() above,
instead the warning does come from lib/smp_processor_id.c when
CONFIG_DEBUG_PREEMPT is enabled, and this happens regardless of
CONFIG_SMP.

I think this most likely comes from this function:

static inline void vivt_flush_cache_pages(struct vm_area_struct *vma,
                unsigned long user_addr, unsigned long pfn, unsigned int nr)
{
        struct mm_struct *mm = vma->vm_mm;

        if (!mm || cpumask_test_cpu(smp_processor_id(), mm_cpumask(mm))) {
                unsigned long addr = user_addr & PAGE_MASK;
                __cpuc_flush_user_range(addr, addr + nr * PAGE_SIZE,
                                vma->vm_flags);
        }
}

which only gets called on uniprocessor Armv4/Armv5 systems with an
aliasing VIPT cache, and those are relatively rare.
smp_processor_id() checks that it is called in an atomic section
because the CPU might change under it on SMP kernels otherwise,
but __get_user_pages() is definitely not an atomic context.

I checked the same code path in linux-5.15 and I don't see any
changes that would explain why you did not see the same
issue earlier.

Can you try to turn off CONFIG_DEBUG_PREEMPT? The specific
warning here looks like a false positive since you can't get
there on an SMP system, but it may be that there are other
similar issues if you see a lot of different warnings.

       Arnd