svn commit: r254846 - projects/camlock/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[John Baldwin]

On Tuesday, October 15, 2013 4:17:00 am Alexander Motin wrote:
> On 26.08.2013 21:25, John Baldwin wrote:
> > On Sunday, August 25, 2013 9:29:06 am Alexander Motin wrote:
> >> On 25.08.2013 15:48, Adrian Chadd wrote:
> >>> Surely there's a better way to check whether a thread can sleep besides
> >>> digging around in curthread->td_no_sleeping ? What about adding an
> >>> accessor macro along side THREAD_SLEEPING_OK and THREAD_NO_SLEEPING ?
> >>
> >> That sounds good to me. I was also surprised such macros are not there
> >> yet when found some code doing these checks just the same way as I did.
> >
> > It was never intended to be public, only as a debugging aid for assertions. :(
> > I had hoped that the calling code would know when it was in an ithread or not
> > and call different routines as needed (i.e. that the programmer would
> > intentionally think about the context they were in).  Perhaps this is not
> > realistic?  Are you really queueing new I/O from ithreads and/or timers?
> 
> I've found potential case where it is not realistic. Requests are 
> normally completed from the interrupt threads. Completion caller does 
> know that it is impossible to sleep in that context. But it holds no 
> locks, it is re-enterable, and so it allows direct completion. Request 
> goes up the stack and at some point on the call chain this completion 
> triggers another request to be sent down (may be even to some different 
> device), but again directly. This new request sender knows nothing about 
> interrupt context and the fact it can't sleep.
> 
> Can you propose some other way to deal with such case other then using 
> per-thread flag/counter?  I could use separate per-thread counter, 
> incremented during up call, but I don't see much benefits form it. If 
> you don't want it to be system-wide accessible to not relax people too 
> much, I could create GEOM-specific wrapper for it.

I don't really have a better option than using it.  Please at least make a
wrapper macro as Adrian suggested around td_no_sleeping.

-- 
John Baldwin