Re: Deferred freeing of kauth_cred_ts

[Elad Efrat <elad%NetBSD.org@localhost>]

On Fri, Dec 25, 2009 at 3:46 PM, Mindaugas Rasiukevicius
<rmind%netbsd.org@localhost> wrote:
> Hello,
>
> Elad Efrat <elad%NetBSD.org@localhost> wrote:
>> One thing that prevents us from attaching credentials to sockets is an
>> issue where these might be freed from interrupt context.
>>
>> What I have in mind is being able to tell when we can sleep or not,
>> and if not, add the credentials to a queue that an independent thread
>> will take care of freeing.
>>
>> If this is sensible, my first step will be extracting the guts of
>> assert_sleepable() to is_sleepable() so we don't always trip a panic()
>> if we can't sleep.
>
> Using is_sleepable() for decision making would be wrong.  As Adam mentioned,
> garbage collecting in a separate thread can be a solution, however it is not
> desirable.  It can be deferred to some transition point in kernel, though.

What do you mean "deferred to some transition point in the kernel"?
Are there any examples of such things? (I'm a bit behind on the new
interfaces we have...)

> The question is - why freeing is performed from interrupt context?

No idea, that just turned up to be the case...

Thanks,

-e.