Marvell Kirkwood and the linux 7.1.5 kernel
David Summers
kirkwood at davidjohnsummers.uk
Tue Aug 11 00:31:26 PDT 2026
On 10/08/2026 20:54, Arnd Bergmann wrote:
> 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
Ah yes - I do indeed have CONFIG_DEBUG_PREEMPT set to - and
interestingly that was set in the 5.15 kernel (last one I was running)
and that didn't produce the bug.
I'll try this when I get back on the machine - am currently stuck in
the initramfs, and having problems bringing the HDD up (think the
initramfs doesn't have the module it needs to access hdd via the
kirkwood CPU, I though I'd made this be always in the kernel rather than
a module ... but its not working).
Anyway I'll set up a system on a USB disk - and boot off that - Then I
can access the hdd, and make the changes.
Thanks for the help.
More information about the linux-arm-kernel
mailing list