Andrew Morton <[email protected]> writes:
> Olaf Dietsche wrote:
>>
>> Ben Clifford <[email protected]> writes:
>>
>> > I still get those stack traces, though...
>>
>> I retested with CONFIG_PREEMPT=y and now I get those stack traces,
>> too. So, it seems my code is not preempt safe.
>>
>
> It's not that your code is unsafe with preemption. It's just that
> CONFIG_PREEMPT=y turns on the debugging infrastructure which allows
> us to detect things like calling kmalloc(GFP_KERNEL) inside spinlock.
Thanks for this hint. So this means kmalloc(GFP_KERNEL) inside
spinlock is not necessarily dangerous, but should be avoided if
possible? Is using a semaphore better than using spinlocks? Is
there a list of dos and don'ts for preempt kernels beside
Documentation/preempt-locking.txt?
And btw, who is "us"?
Regards, Olaf.
>>>>> "Olaf" == Olaf Dietsche <olaf.dietsche#[email protected]> writes:
Olaf> So this means kmalloc(GFP_KERNEL) inside spinlock is not
Olaf> necessarily dangerous, but should be avoided if possible? Is
Olaf> using a semaphore better than using spinlocks?
You should never kmalloc(GFP_KERNEL) while holding a spinlock, since
it is dangerous even without preempt. kmalloc(GFP_KERNEL) may sleep,
which will lead to deadlock (the code holding the spinlock gets
scheduled out because of the kmalloc, then some other code tries to
take the lock -- deadlock).
A semaphore is safer, because if you fail to get the semaphore you
will go to sleep, which allows the process that holds the semaphore to
get scheduled again and release it. However you cannot use semaphores
in interrupt handlers -- you must be in process context when you
down() the semaphore. (Note that it is OK to up() a semaphore from an
interrupt handler)
Best,
Roland
On Mon, 11 Nov 2002, Olaf Dietsche wrote:
> Thanks for this hint. So this means kmalloc(GFP_KERNEL) inside
> spinlock is not necessarily dangerous, but should be avoided if
> possible? Is using a semaphore better than using spinlocks? Is
> there a list of dos and don'ts for preempt kernels beside
> Documentation/preempt-locking.txt?
>
> And btw, who is "us"?
The Cab^Kernel developers ;)
--
function.linuxpower.ca