Re: spin_lock & spin_trylock race

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Lal,

Replying to all this time....

On Tue, Aug 24, 2010 at 10:18 PM, Lal wrote:
> Is below code race free?
>
> void process_context_function(void)
> {
>    /* interrupts enabled here */

You need to call spin_lock_irqsave
>    spin_lock(&lock);


>    modify_critical_section_list();

And spin_lock_irqrestore here.
>    spin_unlock(&lock);

On a uniprocessor machine spin_lock is a no-op (unless spinlock
debugging is enabled).

> }
>
> irqreturn_t a2091_intr (int irq, void *_instance)
> {

Why us trylock? Why not just use spin_lock? If the only interrupt
which modifies the critical section list is this one, then you can use
plain spin_lock/unlock, otherwise you may need to use
spin_lock_irqsave/restore (depends on how the call to request_irq is
made).

>    if(spin_trylock(&lock)) {
>        modify_critical_section_list();
>        spin_unlock(&lock);
>    }
>    else {
>       /* skip */
>    }
>
>    return IRQ_HANDLED;
> }

> More specifically, can spin_lock & spin_trylock have race?

Anything can have a race. The trick is to figure out if you're
protected against the race. Just because you use spin_lock's doesn't
mean that something will be racy or that you won't have any races.
Unfortunately, it's a case of how they're used.

--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux