Date: Wed, 13 Jul 2016 10:49:47 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= <royger@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r302350 - in head: share/man/man9 sys/kern sys/sys Message-ID: <20160713084947.a4nfb6obr475pah6@mac> In-Reply-To: <201607051847.u65IlIYf000901@repo.freebsd.org>
index | next in thread | previous in thread | raw e-mail
On Tue, Jul 05, 2016 at 06:47:18PM +0000, Gleb Smirnoff wrote: > Author: glebius > Date: Tue Jul 5 18:47:17 2016 > New Revision: 302350 > URL: https://svnweb.freebsd.org/changeset/base/302350 > > Log: > The paradigm of a callout is that it has three consequent states: > not scheduled -> scheduled -> running -> not scheduled. The API and the > manual page assume that, some comments in the code assume that, and looks > like some contributors to the code also did. The problem is that this > paradigm isn't true. A callout can be scheduled and running at the same > time, which makes API description ambigouous. In such case callout_stop() > family of functions/macros should return 1 and 0 at the same time, since it > successfully unscheduled future callout but the current one is running. > Before this change we returned 1 in such a case, with an exception that > if running callout was migrating we returned 0, unless CS_MIGRBLOCK was > specified. > > With this change, we now return 0 in case if future callout was unscheduled, > but another one is still in action, indicating to API users that resources > are not yet safe to be freed. > > However, the sleepqueue code relies on getting 1 return code in that case, > and there already was CS_MIGRBLOCK flag, that covered one of the edge cases. > In the new return path we will also use this flag, to keep sleepqueue safe. > > Since the flag CS_MIGRBLOCK doesn't block migration and now isn't limited to > migration edge case, rename it to CS_EXECUTING. > > This change fixes panics on a high loaded TCP server. > > Reviewed by: jch, hselasky, rrs, kib > Approved by: re (gjb) > Differential Revision: https://reviews.freebsd.org/D7042 This change triggers a KASSERT when resuming a Xen VM from suspension: panic: bogus refcnt 0 on lle 0xfffff800035b9c00 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa800 vpanic() at vpanic+0x182/frame 0xfffffe001d2fa880 kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa8f0 llentry_free() at llentry_free+0x136/frame 0xfffffe001d2fa920 in_lltable_free_entry() at in_lltable_free_entry+0xb0/frame 0xfffffe001d2fa950 arp_ifinit() at arp_ifinit+0x54/frame 0xfffffe001d2fa980 netfront_backend_changed() at netfront_backend_changed+0x154/frame 0xfffffe001d2faa50 xenwatch_thread() at xenwatch_thread+0x1a2/frame 0xfffffe001d2faa70 fork_exit() at fork_exit+0x84/frame 0xfffffe001d2faab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe001d2faab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- This seems to be caused by the following snipped in xen-netfront, which is used by netfront in order to send a gratuitous ARP after recovering from migration, in order for the bridge in the host to cache the MAC of the domain. TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family == AF_INET) { arp_ifinit(ifp, ifa); } } FWIW, this was working fine before this change, so I'm afraid this change triggered some kind of bug in the lle entries. Roger.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160713084947.a4nfb6obr475pah6>