Re: Marvell Kirkwood and the linux 7.1.5 kernel

Re: 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

Re: Marvell Kirkwood and the linux 7.1.5 kernel

[David Summers]

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.

Re: Marvell Kirkwood and the linux 7.1.5 kernel

[Andrew Lunn]

> 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).

mvebu_v5_defconfig has everything needed to get the disk working, at
least with with ext3/4. So anything which is Y in mvebu_v5_defconfig
but M in your configuration you should take a closer look at.

	Andrew