[BUG] [spinlock] spin_lock should imply sched_lock to avoid dead lock

[jinliangli]

Description / Steps to reproduce the issue

Task A takes a spinlock， however it may still preempted by higher priority task, that's very dangerous！ If the higher priority task acquire the same spinlock， then dead lock occurs.

spin_lock api behave like linux's spinlock， that imply preempt_disable. That's different api with spin_lock_irqsave.

If there are no objections, I will fix this bug.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

ubuntu 20.04

NuttX Version

master

Issue Architecture

[Arch: arm], [Arch: all]

Issue Area

[Area: Kernel]

Host information

No response

Verification

• I have verified before submitting the report.

[xiaoxiang781216]

@jinliangli please see the discussion here: #14578

[jinliangli]

@jinliangli please see the discussion here: #14578

well, it seems that adding sched_lock into spin_lock that will cause crash issue when spin_lock is called when bootup, because os kernel is not ready, sched_lock should not be called before os kernel init.

Shall we call spin_lock_notrace(without sched_lock) instead of spin_lock(with sched_lock) when system bootup before os kernel init ?

[avgoor]

Hi @jinliangli, I've recently started to use Raspberry's RP2350 with NuttX and in SMP configuration the ostest gets stuck during nested signals testing. It gets stuck in an endless loop inside a spinlock of g_cpu_irqlock. However when I change the CPU count to 1 but still using SMP this issue does not reproduce anymore. Does my problem look similar to the one you've found?

[jinliangli]

Hi @jinliangli, I've recently started to use Raspberry's RP2350 with NuttX and in SMP configuration the ostest gets stuck during nested signals testing. It gets stuck in an endless loop inside a spinlock of g_cpu_irqlock. However when I change the CPU count to 1 but still using SMP this issue does not reproduce anymore. Does my problem look similar to the one you've found?

The problem I described is that

1. after a low-priority task acquires a spinlock using spinlock_irqsave, it actively wakeup(e.g. sem_post) another high-priority task to compete for the lock already held by the low-priority task, which will lead to a deadlock.
2. After acquiring the spinlock, the low-priority task is preempted (Passive scheduling) by another high-priority task, and the high-priority task competes for the lock already held by the low-priority task, which will lead to a deadlock.

Notice: spinlock should not be nested used.
Please file another issue if you can reproduce with ostest in latest master branch