Hi!
What is it that in_atomic counts? Obviously spinlocks and
get_cpu/put_cpu. Anything else?
Is there easy way to find out which spinlock causes "scheduling in
atomic" warning? [It happens a *lot* in swsusp].
I'm doing spin_lock_irqsave() then in another function
spin_unlock_irqrestore. Is that okay? If no, can it cause "scheduling
in atomic"?
Pavel
--
When do you have heart between your knees?
> What is it that in_atomic counts? Obviously spinlocks and
> get_cpu/put_cpu. Anything else?
>
preempt_disable(), local_irq_disable(), local_bh_disable().
> I'm doing spin_lock_irqsave() then in another function
> spin_unlock_irqrestore. Is that okay? If no, can it cause "scheduling
> in atomic"?
It's not okay, but shouldn't cause scheduling in atomic messages.
The problem is sparc: the 'unsigned long flags' parameter used by
_irqsave and _irqrestore contains the stack frame, which means that you
cannot pass it between functions.
--
Manfred
On Sun, 2002-10-13 at 14:38, Pavel Machek wrote:
> I'm doing spin_lock_irqsave() then in another function
> spin_unlock_irqrestore. Is that okay? If no, can it cause "scheduling
> in atomic"?
It is not OK if the function is run by a different process. Then one
process will have a preempt_count one larger than it should and one
would have a preempt_count one smaller.
The task with the one smaller preempt_count will probably cause a crash
when it preemptively reschedules erroneously.
In other words, you have:
Process A Process B
preempt_count++
preempt_count--
When both of those routines need to be done by the same process.
Also, you cannot use spin_lock_irqsave() in different functions at all
on sparc as it contains stack information.
Robert Love