lkml.org 
[lkml]   [2002]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: programming for preemption (was: [PATCH] 2.5.46: accesspermission filesystem)
Date
Andrew Morton <akpm@digeo.com> writes:

> 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?
>
> It can lock an SMP kernel up. This CPU can switch to another task in the
> page allocator and then, within the context of the new task, come around
> and try to take the same lock.

Alright, this means kmalloc(GFP_KERNEL) inside spinlock is a bug.

>> Is using a semaphore better than using spinlocks?

Andrew Morton <akpm@digeo.com> writes:

> A semaphore won't have that problem. If your CPU comes around again onto
> the already-held lock it will just switch to another task.

Roland Dreier <roland@topspin.com> writes:

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

So, as a rule of thumb, I would say use semaphores, if you need some
locking. And in interrupt context, use spinlocks. Do spinlocks have
other benefits, beside being interrupt safe?

Regards, Olaf.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.043 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site