From owner-svn-src-head@freebsd.org Wed Jul 13 08:49:55 2016 Return-Path: Delivered-To: svn-src-head@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 5393FB93C36; Wed, 13 Jul 2016 08:49:55 +0000 (UTC) (envelope-from royger@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 D3D78180E; Wed, 13 Jul 2016 08:49:54 +0000 (UTC) (envelope-from royger@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id o80so58018109wme.1; Wed, 13 Jul 2016 01:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=o8pb+CR3TMgdP2WCCAjLYnvRYdovsLwjqEJILrWClf8=; b=vqIDOiYGOQewU8a+bSV+6MQCKeFR17tV8MX+qzpo0HAtQHar0tRzwIz2mY5GzTMTaq sesH6TL46km0M31DoyfWx+e49rNf2n4fubnXp1of97btD9woIhpu/Pd3FteZiDL2E7OY KhV/rKE5QykCHmGWPek68VsuGPh0S0PhD8XviECMqy/heY09jgOvxz4dNw1i/pBVzMO0 bDaxmxSMDp3KVzYkhdzVnZ4xy564pQk+at4m3QCIId5V/1zsyB65XK4btmpoQWayDKmd jkewJYzWB/FVIwESY7NvQUzh98gtwfYXnSQaU8UeL0iFk6AUfzCRTtc7kulOTPuN6vO3 ouaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=o8pb+CR3TMgdP2WCCAjLYnvRYdovsLwjqEJILrWClf8=; b=KqnhfWtkblcdAWeO3d5azvXr+U5HksTsOxySB0/8nwrbNbD4bB7TkhzmBthMk+yjGr +ZgD1sbuFa9GNL03dhwatFzjj02hoHJijFHbup9Mh84NvmStepXNbhlpioimIZnYSCG/ uVUMRkxejuwOUUh3oMHaYBnq+s8u+KUY+Xr1Q0bpQf9YIB88Eb5evtqrjoNv9LilgKS3 i6v5A57xvHgFx8m4U6O+aKb6AYRweY1uGWN4UBeKYAOTtqBmwimBYx+INQNsdu5xKNWe nG5Qq5nqNHjLZ7jZ83CGNHWb1KOwgioVY6DlIhRxOba+nlkxaOuWHApN1HVUNk1/hPZn 3tug== X-Gm-Message-State: ALyK8tIt11oihfGZJqhp/g3ZPU1zGCqbGNUc0DoakBrpAO4fYPZR14xc0H4BEfccxonjlg== X-Received: by 10.28.199.205 with SMTP id x196mr8626816wmf.96.1468399792822; Wed, 13 Jul 2016 01:49:52 -0700 (PDT) Received: from localhost (126.red-79-152-23.dynamicip.rima-tde.net. [79.152.23.126]) by smtp.gmail.com with ESMTPSA id o142sm35184629wme.20.2016.07.13.01.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 01:49:52 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Date: Wed, 13 Jul 2016 10:49:47 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Gleb Smirnoff 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> References: <201607051847.u65IlIYf000901@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201607051847.u65IlIYf000901@repo.freebsd.org> User-Agent: Mutt/1.6.2-neo (2016-06-11) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 08:49:55 -0000 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.