Date: Mon, 9 Apr 2012 21:46:18 +0000 From: "Li, Qing" <qing.li@bluecoat.com> To: Ryan Stone <rysto32@gmail.com> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet Message-ID: <B143A8975061C446AD5E29742C531723C648D5@pwsvl-excmbx-05.internal.cacheflow.com> In-Reply-To: <B143A8975061C446AD5E29742C531723C510D6@pwsvl-excmbx-05.internal.cacheflow.com> References: <CAFMmRNyK6RXb43kCRxZbZPSWmmGHYx-1cxsTgL1orVjoDcKYAg@mail.gmail.com> <B143A8975061C446AD5E29742C531723C4C6F8@pwsvl-excmbx-05.internal.cacheflow.com> <CAFMmRNxWUw4XmsNZZi%2BzVjZK6i-Ukisqyub2MsOY11Nb8T9ZCQ@mail.gmail.com> <B143A8975061C446AD5E29742C531723C510D6@pwsvl-excmbx-05.internal.cacheflow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
WRT the IF_AFDATA_LOCK() race condition you mentioned, I re-run the tests=20 that I used when I developed that code, but I haven't run into any issues,= =20 but that doesn't mean there isn't a bug. Could you please share with me a call path that you believe is=20 problematic, or a simple test case that uncovers the issue ? --Qing =20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Monday, April 02, 2012 10:54 AM > To: Ryan Stone > Cc: freebsd-net > Subject: RE: Removing an IPv6 address does not remove NDP entries on > that subnet >=20 > > > > On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing <qing.li@bluecoat.com> > wrote: > > >> * In a way this is a good thing as in6_lltable_prefix_free() is > > >> guaranteed to crash your kernel in two different ways, and that's > > not > > >> counting the race conditions that it's subject to. > > >> > > > > > > =A0 =A0 =A0 =A0Could you please elaborate with some details on the tw= o > > different > > > =A0 =A0 =A0 =A0ways in6_lltable_prefix_free() crashes the kernel > > definitively ? > > > > First, it calls callout_drain on lle->le_timer, but that is never > > initialized for a v6 llentry. Second, it never stops the ln_timer_ch > > callout before it frees the llentry. Third, it modifies the lltable > > without holding IF_AFDATA_LOCK(in.c has the third problem: see the > > -net discussion about kern/165863). >=20 >=20 > 1. The reference to &lle->la_timer instead of ln_timer_ch is fine > because lle_timer is defined as a union. >=20 > 2. The manpage of "callout_drain()" reads >=20 > "The function callout_drain() is identical to callout_stop() except > that it will wait for the callout to be completed if it is already > in progress." >=20 > 3. wrt IF_AFDATA_LOCK() I will check again. >=20 > --Qing >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B143A8975061C446AD5E29742C531723C648D5>