mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Desai, Kashyap]

> -----Original Message-----
> From: Alexander Kabaev [mailto:kabaev at gmail.com]
> Sent: Thursday, February 23, 2012 8:42 PM
> To: Desai, Kashyap
> Cc: Ed Schouten; freebsd-stable; joerg at FreeBSD.org; Kenneth D. Merry;
> freebsd-scsi at freebsd.org; Justin T. Gibbs; McConnell, Stephen
> Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> prohibited
> 
> 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.


OK. 

> 
> 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.

I understood your above lines.
> Hardly the stuff _anyone_ would want to
> do from interrupt handler, thread or otherwise.

So the way mps driver does in interrupt handler is as below.

mps_lock(sc);
mps_intr_locked(data);
mps_unlock(sc);

We hold the mtx lock in Interrupt handler and do whole bunch of work(this is bit lengthy work) under that. 
It looks mps driver is miss using mtx_lock. Are we ?

~ Kashyap

> 
> 
> > > > 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