svn commit: r238907 - projects/calloutng/sys/kern

[Konstantin Belousov]

On Mon, Jul 30, 2012 at 03:24:26PM +0100, Attilio Rao wrote:
> On 7/30/12, Davide Italiano <davide at freebsd.org> wrote:
> > On Mon, Jul 30, 2012 at 4:02 PM, Attilio Rao <attilio at freebsd.org> wrote:
> > Thanks for the comment, Attilio.
> > Yes, it's exactly what you thought. If direct flag is equal to one
> > you're sure you're processing a callout which runs directly from
> > hardware interrupt context. In this case, the running thread cannot
> > sleep and it's likely you have TDP_NOSLEEPING flags set, failing the
> > KASSERT() in THREAD_NO_SLEEPING() and leading to panic if kernel is
> > compiled with INVARIANTS.
> > In case you're running from SWI context (direct equals to zero) code
> > remains the same as before.
> > I think what I'm doing works due the assumption thread running never
> > sleeps. Do you suggest some other way to handle this?
> 
> Possibly the quicker way to do this is to have a way to deal with the
> TDP_NOSLEEPING flag in recursed way, thus implement the same logic as
> VFS_LOCK_GIANT() does, for example.
> You will need to change the few callers of THREAD_NO_SLEEPING(), but
> the patch should be no longer than 10/15 lines.

There are already curthread_pflags_set/restore KPI designed exactly to handle
nested private thread flags.

Also, I wonder, should you assert somehow that direct dispatch cannot block
as well ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20120730/6231c89f/attachment.pgp