Date: Thu, 10 Dec 2015 07:25:56 -0800 From: Randall Stewart <rrs@netflix.com> To: Hans Petter Selasky <hps@selasky.org> Cc: "Alexander V. Chernikov" <melifaro@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, freebsd-net <freebsd-net@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: panic in arptimer in r289937 Message-ID: <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> In-Reply-To: <5661EF10.8060300@selasky.org> References: <CAJ-VmonvVyTNuYv_as41yPCFdfR5T3FE45DP9MKAc-eyzXzPUg@mail.gmail.com> <2739461446298483@web2h.yandex.ru> <CAJ-Vmo=JjHonDqOYK%2BJDaf9581dRU5_KoaSTnY27JnzQm0v56w@mail.gmail.com> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <hps@selasky.org> =
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" <adrian@freebsd.org>:
>>>> On 31 October 2015 at 09:34, Alexander V. Chernikov
>>>> <melifaro@freebsd.org> wrote:
>>>>> 31.10.2015, 05:32, "Adrian Chadd" <adrian@freebsd.org>:
>>>>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96B619F6-489C-4931-B306-1E1DE03F09B4>