From owner-freebsd-net@FreeBSD.ORG  Mon Apr  2 17:53:39 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 73EDF106566B
	for <freebsd-net@freebsd.org>; Mon,  2 Apr 2012 17:53:39 +0000 (UTC)
	(envelope-from qing.li@bluecoat.com)
Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com
	[199.91.133.12])
	by mx1.freebsd.org (Postfix) with ESMTP id 361548FC08
	for <freebsd-net@freebsd.org>; Mon,  2 Apr 2012 17:53:39 +0000 (UTC)
Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122])
	by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 6EBE0200CF;
	Mon,  2 Apr 2012 10:32:48 -0700 (PDT)
Received: from pwsvl-excmbx-05.internal.cacheflow.com
	([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com
	([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001;
	Mon, 2 Apr 2012 10:53:37 -0700
From: "Li, Qing" <qing.li@bluecoat.com>
To: Ryan Stone <rysto32@gmail.com>
Thread-Topic: Removing an IPv6 address does not remove NDP entries on that
	subnet
Thread-Index: AQHNDnkgJRkO9YzfY0abvrST7SLcoJaH0pmQ
Date: Mon, 2 Apr 2012 17:53:36 +0000
Message-ID: <B143A8975061C446AD5E29742C531723C510D6@pwsvl-excmbx-05.internal.cacheflow.com>
References: <CAFMmRNyK6RXb43kCRxZbZPSWmmGHYx-1cxsTgL1orVjoDcKYAg@mail.gmail.com>
	<B143A8975061C446AD5E29742C531723C4C6F8@pwsvl-excmbx-05.internal.cacheflow.com>
	<CAFMmRNxWUw4XmsNZZi+zVjZK6i-Ukisqyub2MsOY11Nb8T9ZCQ@mail.gmail.com>
In-Reply-To: <CAFMmRNxWUw4XmsNZZi+zVjZK6i-Ukisqyub2MsOY11Nb8T9ZCQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.2.2.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: freebsd-net <freebsd-net@freebsd.org>
Subject: RE: Removing an IPv6 address does not remove NDP entries on that
 subnet
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 17:53:39 -0000

>=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 two
> different
> > =A0 =A0 =A0 =A0ways in6_lltable_prefix_free() crashes the kernel
> definitively ?
>=20
> 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).


1. The reference to &lle->la_timer instead of ln_timer_ch is fine=20
   because lle_timer is defined as a union.


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."

3. wrt IF_AFDATA_LOCK() I will check again.


--Qing