On (08/30/07 19:59), Peter Memishian wrote:
>
> > > * 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.
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.
this is also mostly the case for IRE_UNTRACE_REF, except for these
two exceptions:
3 tcp.c tcp_adapt_ire 2965 IRE_UNTRACE_REF(ire);
4 nattymod.c get_my_ire 337 IRE_UNTRACE_REF(ire);
which seem to be calling ire_untrace_ref directly for ire's they
are going to cache. For both of these cases, the ire was found by a
lookup done by that same thread, so the ire_untrace_ref is safe..
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
