Messages in this thread | | | From | Olaf Dietsche <olaf.dietsche#> | Subject | Re: programming for preemption (was: [PATCH] 2.5.46: accesspermission filesystem) | Date | Tue, 12 Nov 2002 00:19:34 +0100 |
| |
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/
| |