From mboxrd@z Thu Jan 1 00:00:00 1970 From: GAggarwal@IN.Safenet-inc.com Subject: RE: Need for a new spinlock API? Date: Wed, 4 Apr 2007 09:20:56 +0530 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7766C.733678E6" Return-path: Sender: kernelnewbies-bounce@nl.linux.org Errors-to: kernelnewbies-bounce@nl.linux.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: List-subscribe: List-owner: List-post: List-archive: To: rajat.noida.india@gmail.com Cc: kernelnewbies@nl.linux.org, linux-newbie@vger.kernel.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7766C.733678E6 Content-Type: text/plain; charset="iso-8859-1" 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@nl.linux.org [mailto:kernelnewbies-bounce@nl.linux.org]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@nl.linux.org 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. ------_=_NextPart_001_01C7766C.733678E6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE:=20Need=20for=20a=20new=20spinlock=20API?

Hi=20Rajat,

I=20think=20spin_= lock_irqsave()=20will=20fulfill=20the=20purpose=20as=20otherwise=20it=20ma= y=20be=20possible=20that=20the=20when=20a=20data=20structure=20is=20access= ed=20in=20process=20context=20by=20taking=20spin_lock=20and=20an=20interru= pt=20comes=20then=20the=20ISR=20will=20remain=20in=20forever=20loop=20wait= ing=20for=20the=20process=20context=20to=20release=20the=20lock=20result=20= in=20a=20deadlock=20situation=20for=20a=20uniprocessor=20system.=20You=20c= an=20also=20use=20spin_lock_bh()=20if=20the=20data=20structure=20is=20acce= ssed=20in=20tasklet=20(bottom=20half).=20Please=20CMIIW.

--
Regards,
Gaurav=20Aggarwa= l


-----Original=20Message-----
From:=20kernelnewbies-bounce@nl.linu= x.org
[mailto:kernelnewbies-bounce@nl.linux.org]On=20Beha= lf=20Of=20Rajat=20Jain
Sent:=20Wednesday,=20April=2004,=202= 007=208:57=20AM
To:=20Arjan=20van=20de=20Ven
Cc:=20kernel=20mail;=20newbie=
Subject:=20Re:=20Need=20for=20a=20ne= w=20spinlock=20API?


>=20>=20We=20often=20have=20a=20= case=20where=20a=20driver=20wants=20to=20access=20its=20data=20structure
>=20>=20in=20process=20context= =20as=20well=20as=20in=20interrupt=20context=20(in=20its=20ISR).=20In
>=20>=20such=20scenarios,=20we= =20generally=20use=20spin_lock_irqsave()=20to=20grab=20the=20lock
>=20>=20as=20well=20as=20disab= le=20all=20the=20local=20interrupts.=20AFAIK,=20disabling=20of=20local
>=20>=20interrupts=20is=20requ= ired=20so=20as=20to=20avoid=20running=20your=20ISR=20(which=20needs=
>=20>=20the=20lock)=20while=20= process=20context=20is=20holding=20the=20lock.=20However,=20this
>=20>=20also=20disables=20any=20= other=20ISRs=20(which=20DO=20NOT=20need=20the=20lock)=20on=20the=20local
>=20>=20processor.
>=20>
>=20>=20Isn't=20this=20sub-opt= imal?=20Shouldn't=20there=20be=20a=20finer=20grained=20locking?
>
>=20actually=20it's=20optimal.
>=20It's=20fastest=20to=20delay=20= the=20interrupts=20a=20little=20and=20be=20done=20with=20what=20you=
>=20want=20to=20do=20under=20the=20= lock=20quickly,=20and=20THEN=20take=20the=20interrupt.=20This
>=20means=20the=20lock=20hold=20t= ime=20is=20short,=20which=20significantly=20reduces
>=20contention=20on=20this=20lock= ...

So=20on=20the=20same=20lines,=20if=20= a=20data=20structure=20is=20accessed=20in=20both=20process
context=20and=20in=20a=20(single)=20= driver=20ISR,=20should=20a=20driver=20use
spin_lock_irqsave()=20to=20get=20the= =20lock=20in=20ISR?=20Or=20will=20a=20simple
spin_lock() =20suffice?

Thanks,

Rajat


--
To=20unsubscribe=20from=20this=20lis= t:=20send=20an=20email=20with
"unsubscribe=20kernelnewbies&qu= ot;=20to=20ecartis@nl.linux.org
Please=20read=20the=20FAQ=20at=20http://kernelnew= bies.org/FAQ


The=20information=20contained=20in=20this=20electronic=20mail=20transmissi= on=20may=20be=20privileged=20and=20confidential,=20and=20therefore,=20prot= ected=20from=20disclosure.=20If=20you=20have=20received=20this=20communica= tion=20in=20error,=20please=20notify=20us=20immediately=20by=20replying=20= to=20this=20message=20and=20deleting=20it=20from=20your=20computer=20witho= ut=20copying=20or=20disclosing=20it.
------_=_NextPart_001_01C7766C.733678E6-- -- 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