Re: programming for preemption (was: [PATCH] 2.5.46: accesspermission filesystem)

[Andrew Morton <akpm@digeo.com>]

Olaf Dietsche wrote:
> 
> Andrew Morton <akpm@digeo.com> writes:
> 
> > Olaf Dietsche wrote:
> >>
> >> Ben Clifford <benc@hawaga.org.uk> 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?

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.

> Is using a semaphore better than using spinlocks?

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.

> Is
> there a list of dos and don'ts for preempt kernels beside
> Documentation/preempt-locking.txt?

Not that I'm aware of.  (This is not preempt-related though.  Generally,
correct SMP coding is correct preempt coding)
 
> And btw, who is "us"?
> 

It is a broad term for "those who code on the kernel".