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

[Attilio Rao]

On 7/30/12, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 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.

Yes, however I would use curthread_pflags* KPI within
THREAD_NO_SLEEPING() as this name is much more explicit.

> Also, I wonder, should you assert somehow that direct dispatch cannot block
> as well ?

Yes, it would be optimal, but I don't think we have a flag for that
right now, do we?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein