Jan Hudec <bulb@ucw.cz> writes:
> On Wed, Jun 09, 2004 at 15:30:46 -0700, Greg KH wrote:
>> On Thu, Jun 10, 2004 at 12:21:18AM +0200, Jan Hudec wrote:
>> >
>> > It is also imperative, that the flags for irqsave/irqrestore live on the
>> > stack!
>>
>> I don't think this is true anymore for 2.6, but for any previous kernel
>> it is true.
>
> Well, it does not have to live on the stack. It never really had to. But
> it must be assured, that each pair invoked has it's own flags. And it's
> far easiest by using automatic local variable.
>
> As to the definition, it still did not change. It is still:
>
> local_irq_save:
> pushfl
> popl %0
> cli
>
> local_irq_restore:
> pushl %0
> popfl
>
> And spin_lock_irqsave is local_irq_save + spin_lock.
Can anybody point out a specific problem with the (2.4) code below?
When I saw it, it made me uneasy because I'd heard somewhat vague
warnings against doing stuff like this. I can't see how the x86
implementation could have a problem, but maybe some other architecture
would?
static struct mylock {
spinlock_t lock;
unsigned long flags;
} mylock;
void lock(struct mylock *p)
{
spin_lock_irqsave(&p->lock, p->flags);
}
void unlock(struct mylock *p)
{
spin_lock_irqrestore(&p->lock, p->flags);
}
void demonstration(void)
{
lock(&mylock);
/* do stuff that doesn't sleep */
unlock(&mylock);
}
--
--Ed L Cashin | PGP public key:
ecashin@uga.edu | http://noserose.net/e/pgp/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
