Julian Elischer wrote:
Julian Elischer wrote:
In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up
rewriting it to do what I thought it was trying to do..
this stops the panics some people have seen, but allows the system to
stay up long enough to see some other problem..
anyhow this si the patch:
comments?
I was thinking about this a bit.
rt_check_fib() drops the lock on the given rtentry in order to be able
to get a lock on another rtentry that MIGHT be the same rtentry.
while it is doing this, another processor could free the original
rtentry. The only safw way to get around this is to hold an additional
reference on the first rtentry (we don't already have one) while it is
unlocked so that we can be sure that it is not actually freed if this
happens.
to do this safely I'd have to add a couple of new items into route.h:
#define RT_TEMP_UNLOCK(_rt) do { \
RT_ADDREF(_rt); \
RT_UNLOCK(_rt); \
} while (0)
#define RT_RELOCK(_rt) do { \
RT_LOCK(_rt) \
if ((_rt)->rt_refcnt <= 1) \
rtfree(_rt); \
_rt = 0; /* signal that it went away */ \
else { \
RT_REMREF(_rt); \
RT_UNLOCK(_rt);
duh remove that line!
\
/* note that _rt is still valid */ \
} \
} while (0)
the new version of rt_check is attached.....
------------------------------------------------------------------------
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
