Hi Rajat,
I think spin_lock_irqsave() will fulfill the purpose as otherwise it may be possible that the when a data structure is accessed in process context by taking spin_lock and an interrupt comes then the ISR will remain in forever loop waiting for the process context to release the lock result in a deadlock situation for a uniprocessor system. You can also use spin_lock_bh() if the data structure is accessed in tasklet (bottom half). Please CMIIW.
--
Regards,
Gaurav Aggarwal
-----Original Message-----
From: kernelnewbies-bounce@xxxxxxxxxxxx
[mailto:kernelnewbies-bounce@xxxxxxxxxxxx]On Behalf Of Rajat Jain
Sent: Wednesday, April 04, 2007 8:57 AM
To: Arjan van de Ven
Cc: kernel mail; newbie
Subject: Re: Need for a new spinlock API?
> > We often have a case where a driver wants to access its data structure
> > in process context as well as in interrupt context (in its ISR). In
> > such scenarios, we generally use spin_lock_irqsave() to grab the lock
> > as well as disable all the local interrupts. AFAIK, disabling of local
> > interrupts is required so as to avoid running your ISR (which needs
> > the lock) while process context is holding the lock. However, this
> > also disables any other ISRs (which DO NOT need the lock) on the local
> > processor.
> >
> > Isn't this sub-optimal? Shouldn't there be a finer grained locking?
>
> actually it's optimal.
> It's fastest to delay the interrupts a little and be done with what you
> want to do under the lock quickly, and THEN take the interrupt. This
> means the lock hold time is short, which significantly reduces
> contention on this lock...
So on the same lines, if a data structure is accessed in both process
context and in a (single) driver ISR, should a driver use
spin_lock_irqsave() to get the lock in ISR? Or will a simple
spin_lock() suffice?
Thanks,
Rajat
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ