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
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
