Is below code race free?

void process_context_function(void)
{
    /* interrupts enabled here */
    spin_lock(&lock);
    modify_critical_section_list();
    spin_unlock(&lock);
}

irqreturn_t a2091_intr (int irq, void *_instance)
{
    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?

Regards
Lal

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

[ message continues ]

Hi Lal,

Replying to all this time....




On a uniprocessor machine spin_lock is a no-op (unless spinlock

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

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@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

[ message continues ]

Ironically, it is safe on SMP, but not on UP !

As the other poster noted, spin_lock is a NOOP on
UP kernels, which means that the irq handler could
be called during your modify_critical_section_list()
call in process context.

The other poster also provided the solution - using
spin_lock_irq & spin_unlock_irq in the process context



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

[ message continues ]

Hi Lal,

Looks like you have a critical section between process context and interrupt
context, right?
Then why not just use spin_lock_irq () ? You will not need trylock in that
case.

Here is the similar discussion where your approach is discussed,

http://www.geeksofpune.in/drupal/?q=node/75

From comments, looks like it is not correct to use trylock on UP.

Please refer famous article here,
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html#MINIMUM-L...

[ message continues ]

Hi,

Is there any easy-ish way to implement a wall-like functionality in a
kernel module? For example, if I wanted to load my hypothetical module,
could I get something similar to the following output?

stephen@icipher:~% insmod ./broadcaster.ko
Broadcast message from kernel module "broadcaster":
    I was loaded!

stephen@icipher:~%

Thanks in advance,
Stephen

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

[ message continues ]

No, I don't want a printk() call, I want to broadcast to all open
terminals, much like the 'wall' command does.

Cheers,
Stephen



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

[ message continues ]

Cool, that's what I was looking for, thanks :)



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

[ message continues ]

Please don't top post :)

Yes,it is printk() you need....use highest priority level...most
likely the message will be dumped right on the screen..instead of
being catched by syslogd. And assuming that your X is running
something similar to "syslog", it will be printed to X too. I remember
seeing this kind of thing in KDE 3.x

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

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

[ message continues ]

Someone can clarify my understanding?

From the above "Unreliable guide to locking", assuming it is reasonably
reliable :-), how do u read the column "User COntext A"?  (ie, what does no
entries means?)



-- 
Regards,
Peter Teoh
[ message continues ]

Have u ever considered mutex?   Spinlocks are fast and efficient, but
anything after the spinlock MUST NOT SLEEP, but, or risk being scheduled OUT
of being processed by the CPU.   Generally, in my present understanding, any
locks inside the interrupt context should use spinlocks, and process context
should use mutex locks, and race condition always appeared whenever the one
running in process context is competing for resources with those in
interrupt context - ie, avoid having locks that is cross-used in both
context.

Sorry if I am wrong, comment welcomed :-).

-- 
Regards,
Peter Teoh
[ message continues ]

Let me be the first one to comment on myself:

the answer (I suspect) is - yes....both SMP and UP.   Conventional wisedom
always say used the irqsave version, to protect against use of the spin
locks inside the interrupt handler.   And after reading all the posters, it
is amply summarized in this doc as well:

http://www.mjmwired.net/kernel/Documentation/spinlocks.txt

But it is exactly the same concerns which Linus mentioned inside - the
spinlocks occuring in the same CPU that give rise to deadlock - which is
addressed by the use of trylock()!!! Correct?   To rephrase my
(mis)understanding again:

If the spinlock happened on different CPU - no deadlock, as after some time
the owner will complete the job, and the waiter takes over.

If the spinlock happened on the same CPU - the interrupt-handler's issued a
trylock first, so if it is in use.....no problem...it will not spinlock.
but if the spinlock is not in use, then the interrupt handler will spinlock
and unlock - and even if assuming in between intercepted by another
interrupt (embedded interrupt - Intel x86 allowed up to 2 level)...still no
problem......

So ultimately I really cannot see any problem arising from your
implementation.   Against conventional wisedom....but it works ..... or am I



-- 
Regards,
Peter Teoh
[ message continues ]