On Fri, 28 May 2010 13:35:07 +0200, James Carlson <carls...@workingcode.com> 

> On 05/28/10 04:57, Frank Batschulat (Home) wrote:
>> On Fri, 28 May 2010 10:43:22 +0200, <eiji....@oracle.com> wrote:
>>> getzoneid() can return a correct value even if it's called in a taskq thread
>>> (kernel context) and/or in an interrupt handler (interrupt context)?
>> I suppose so, look its not doing anything earth shattering:
>>    2496 getzoneid(void)
>>    2497 {
>>    2498      return (curproc->p_zone->zone_id);
>>    2499 }
>> no locking involved, no allocations done, nothing considered
>> harmfull in an interrupt context or taskq thread.
>> only question is to what proc your taskq/interrupt thread will bind to.
> It sounds like we might need more information about what the original
> poster is attempting to do.
> Interrupts themselves aren't features of non-global zones, so they're
> not normally attributed to any particular zone.  In theory, if there
> were devices dedicated to individual zones, you could use the device's
> state structure to find the zoneid associated.
> If you just use getzoneid() in that context, you'll get the zoneid of
> the zone whose thread happens to be pinned down by the interrupt.  In
> other words, it's an arbitrary and almost certainly wrong answer.
> I think something's amiss if you're asking about zoneid outside the
> context of direct system call processing.  The answers there vary quite
> a bit.  For example, with STREAMS, the correct answer is to fetch the
> cred_t attached to the dblk_t, and get the zoneid from the cred_t.
> It's not unusual at all for interrupts and taskqs to do work on behalf
> of many different zones, and for them to need to track this information
> separately.

yepp, my bad ! and of course interrupt threads are always bound to p0 when they
are created (-> thread_create_intr())

zones-discuss mailing list

Reply via email to