From owner-freebsd-current@freebsd.org Thu Dec 10 15:26:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 525D79D791A for ; Thu, 10 Dec 2015 15:26:00 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 233D01D96 for ; Thu, 10 Dec 2015 15:26:00 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pacdm15 with SMTP id dm15so49256930pac.3 for ; Thu, 10 Dec 2015 07:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FTTHQyrkWI+EYCu+3oZ9tUhE3sqlQ6eQqVGGmHxbE2I=; b=aeXSkM29eIqqVhuGS75Mh2WBDulordAHYyyjZz+l9Zna9eS/RXA6HieOJpyzGnebiN mzgYKU90GVU/r6ZAfg8XNZf4Punj2XciFshkihVoz8DNox2w6HO9YmJOIoUutEVTKos1 vnMwdWuIPQHPf+K96bThdD0TXkdGl8Cokc8o8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FTTHQyrkWI+EYCu+3oZ9tUhE3sqlQ6eQqVGGmHxbE2I=; b=TiZ5tRB75h4DqOyUYWgG41/t7MXOWe2Rl+WMUAQbbLwhfYOK/qcJvBukvNAoXgELPM Q1orToAPNjIhhu+aNOF2wUgezA/LGpRBAxJj1SCiD4q7aog13k8K2YKkpF+d4B1sPju/ xFC7N8y4x/BduR1U669NeQGipEFUHO3AwAydqDqkvacL4UwuZgHe/FU92H8Wt/NcMMVK GnaxVi/pAB0mqRuJEdzKgYKDent9MqpMV4uNMtYQBtazkluyuz4GMMF9VxHS77I9A9bb rUbPJzWNoLTndedQ/vdEgECJER/LmFT9Tm0Y9KTFBfWpK/JpytjD7J6fF7znL8uUAg8W 5+TQ== X-Gm-Message-State: ALoCoQktI3atNNRRN/G1rqIfagOUK49z9UUETlPRcLWimWMuWrhYQR0nJat9xG/xSs7NMOhm/713pOnr8RDK+SR9F23c1FjUSA== X-Received: by 10.67.5.40 with SMTP id cj8mr17202864pad.98.1449761159705; Thu, 10 Dec 2015 07:25:59 -0800 (PST) Received: from [10.16.208.207] ([69.53.232.0]) by smtp.gmail.com with ESMTPSA id sg4sm19599472pac.48.2015.12.10.07.25.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 07:25:58 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic in arptimer in r289937 From: Randall Stewart In-Reply-To: <5661EF10.8060300@selasky.org> Date: Thu, 10 Dec 2015 07:25:56 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current Message-Id: <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Thu, 10 Dec 2015 16:21:39 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 15:26:00 -0000 For callout_stop/drain you get -1 =3D=3D Callout as already gone off or is not running (usually the = latter) else the caller iks not using locking properly or did not lock and check the = active() value (which would have returned not active so no stop would have been needed); 0 =3D=3D we could not stop the callout, it was in process.. 1 =3D=3D it was stopped successfully=20 For callout_reset() you get 0 =3D=3D it was started 1 =3D=3D it was restarted. There is no -1 since it is either started or restarted never left in a = not-running state... R On Dec 4, 2015, at 11:52 AM, Hans Petter Selasky = wrote: > On 12/04/15 20:34, Hans Petter Selasky wrote: >> Hi Adrian, >>=20 >> On 10/31/15 16:01, Alexander V. Chernikov wrote: >>>=20 >>>=20 >>> 31.10.2015, 16:46, "Adrian Chadd" : >>>> On 31 October 2015 at 09:34, Alexander V. Chernikov >>>> wrote: >>>>> 31.10.2015, 05:32, "Adrian Chadd" : >>>>>> Hiya, >>>>>>=20 >>>>>> Here's a panic from arptimer: >>>>> Hi Adrian, >>>>>=20 >>>>> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) >>>>> which happens after LLE_WUNLOCK(). >>>>> So, it looks like (pre-cached) ifp had been freed before locking >>>>> ifdata. >>>>> Do you have any more details on that? (e.g. was some interface >>>>> detached at that moment, is it reproducible, etc..) >>>>>=20 >>>>> =46rom a quick glance, potential use-after-free has been possible >>>>> for quite a long time, but I wonder why it hasn't been observed = before. >>>>> Probably lltable_free() changes might have triggered that. >>>>>=20 >>>>> I'll take a deeper look on that and reply. >>>>=20 >>=20 >> Observed on an idle box with projects/hps_head too: >>=20 >>> panic: bogus refcnt 0 on lle 0xfffff8016508ca00 >>> cpuid =3D 7 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe03e4e8c7e0 >>> vpanic() at vpanic+0x182/frame 0xfffffe03e4e8c860 >>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe03e4e8c8d0 >>> llentry_free() at llentry_free+0x136/frame 0xfffffe03e4e8c900 >>> arptimer() at arptimer+0x20e/frame 0xfffffe03e4e8c950 >>> softclock_call_cc() at softclock_call_cc+0x170/frame = 0xfffffe03e4e8c9c0 >>> softclock() at softclock+0x47/frame 0xfffffe03e4e8c9e0 >>> intr_event_execute_handlers() at >>> intr_event_execute_handlers+0x96/frame 0xfffffe03e4e8ca20 >>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe03e4e8ca70 >>> fork_exit() at fork_exit+0x84/frame 0xfffffe03e4e8cab0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe03e4e8cab0 >>> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >>=20 >> Looks like callout_reset() must be examined too, and was missed by: >>=20 >> https://svnweb.freebsd.org/changeset/base/290805 >>=20 >> Can you try the attached patch? >>=20 >> Randall: Can you fix this ASAP? >>=20 >> --HPS >>=20 >=20 > Hi, >=20 > Randall: >=20 > I see for 11-current, callout_reset() doesn't return -1 when the = callout is stopped like with callout_stop(). Is this a bug or a feature? = Why can't the callout_reset() and callout_stop() functions use the same = return values? >=20 > In nd6_llinfo_settimer_locked() the return value of both = callout_reset() and callout_stop() is checked for positive values, but = not in the other places mentioned by my patch. >=20 > --HPS -------- Randall Stewart rrs@netflix.com 803-317-4952