Peter Memishian writes:
>
> > > * The *_untrace_ref() functions seem to assume that the thread
> > > doing the untrace will already be known to the tracing
> > > framework (or we'll panic). I don't see what guarantees this.
> >
> > The refholds/releases on ipif/ill are purely localized, held and
> > released by the same thread across a small section of code. (unlike the
> > case of ire/nce). So that should guarantee the above, right ?
>
> My comment also applies to {ire,nce}_untrace_ref(), though.
The original code also assumed exactly this and would panic otherwise:
th_trace = th_trace_ire_lookup(ire);
ASSERT(th_trace != NULL && th_trace->th_refcnt > 0);
th_trace_rrecord(th_trace);
I'm not saying that it's necessarily _right_ but that it's not a new
requirement at all.
[EMAIL PROTECTED] writes:
> On (08/30/07 19:59), Peter Memishian wrote:
> > My comment also applies to {ire,nce}_untrace_ref(), though.
>
> nce_trace_unref is only called from NCE_REFRELE, which is expected
> to be called only when the nce was ref'ed using NCE_REFHOLD (i.e., with
> a matching nce_trace_ref for the thread)... so the thread assumption is
> true.
Yes; that's my understanding as well.
Peter Memishian writes:
> > Which is why we have the (admittedly ugly) the _NOTR variants for
> > ire/nce. Jim hasn't changed any of that, I think.
>
> I didn't realize that was the justification for the NOTR() variants.
> With Jim's new design, it doesn't seem like it would be hard to support
> this case and remove the NOTR() stuff. Am I missing something?
I'm still tracking per-thread, so I think it'd be hard to do that.
Thirumalai Srinivasan writes:
> [EMAIL PROTECTED] wrote:
> >I'm not sure how Jim's design changes that basic assumption behind
> >the trace_refs.
> >
> >
> no, it doesn't.
Correct.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
