mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Alexander Kabaev]

On Thu, 23 Feb 2012 18:45:29 +0530
"Desai, Kashyap" <Kashyap.Desai at lsi.com> wrote:

> 
> 
> > -----Original Message-----
> > From: Ed Schouten [mailto:ed at 80386.nl]
> > Sent: Thursday, February 23, 2012 3:16 PM
> > To: Desai, Kashyap
> > Cc: freebsd-scsi at freebsd.org; freebsd-stable; joerg at FreeBSD.org;
> > Kenneth D. Merry; McConnell, Stephen; Justin T. Gibbs
> > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> > prohibited
> > 
> > Hi Kashyap,
> > 
> > * Desai, Kashyap <Kashyap.Desai at lsi.com>, 20120222 18:51:
> > > Adding Ed Schouten and Jorg Wunsch  as I see there are author of
> > > msleep/mtx related APIs.
> > 
> > Am I? :-)
> I am new to FreeBSD and desperate to know the answer. :-). Thanks for
> your help.
> > 
> > > 1. When any irq is register with FreeBSD OS, it sets "
> > > TDP_NOSLEEPING" pflag. It means though irq in freebsd is treated
> > > as thread, We cannot sleep in IRQ because of " "TDP_NOSLEEPING "
> > > set. 2. In mps driver we have below code snippet in ISR routine.
> > >
> > >
> > >     mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
> > >     mps_lock(sc);
> > >     mps_intr_locked(data);
> > >     mps_unlock(sc);
> > >
> > > I wonder why there is no issue with above code ? Theoretical we
> > > cannot sleep in ISR. (as explained in #1) Any thoughts ?
> > 
> > The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate
> > amount of time. Locking a mutex is allowed, as it can only cause the
> > thread to be blocked for a small amount of time, waiting for another
> > thread to unlock it.
> So does this assumption that another thread will release mutex fast
> enough ? Same as msleep() this can be applicable here as well. I mean
> another thread  _can_ (if some bad drivers) take long time to release
> mutex.
> 
>
Bad drivers can just defererence wild pointer to satisfy their need for
wrongdoing. For that reason let us keep them out of conversation.

mtx locks were designed to protect small sections of code where thread
is only allowed to block waiting for other thread to release the lock
of similar class. While threads are blocked, they get benefit of
adaptive sleep and priority propagation and should take precaution of
never taking the path of code that can cause them to sleep. Assertions
are there to help code authors with that.

sleep locks are by definition unbound. There is no spinning, no
priority propagation. Holders are free to take, say, page faults and go
to long journey to disk and back, etc. Hardly the stuff _anyone_ would
want to do from interrupt handler, thread or otherwise. 

 
> > > 3. I recently added few place msleep() instead of DELAY in ISR
> > > context and I see " Trying sleep, but thread marked as sleeping
> > > prohibited".
> > 
> > Which makes sense, as msleep() can be used to sleep for
> > indefinitely.
> This part is clear. ! I agree with all experts view. 
> > 
> > --
> >  Ed Schouten <ed at 80386.nl>
> >  WWW: http://80386.nl/
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to
> "freebsd-scsi-unsubscribe at freebsd.org"


-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20120223/d0a33b06/signature.pgp