From owner-svn-src-all@freebsd.org Thu Jun 8 21:49:49 2017 Return-Path: Delivered-To: svn-src-all@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 201A9D84887; Thu, 8 Jun 2017 21:49:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF382730E7; Thu, 8 Jun 2017 21:49:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 4FD6F10AFA2; Thu, 8 Jun 2017 17:49:46 -0400 (EDT) From: John Baldwin To: "Jonathan T. Looney" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r319720 - head/sys/dev/vt Date: Thu, 08 Jun 2017 14:49:43 -0700 Message-ID: <7306919.ixyIA96xWQ@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <201706082047.v58KlI51079003@repo.freebsd.org> References: <201706082047.v58KlI51079003@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 08 Jun 2017 17:49:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 21:49:49 -0000 On Thursday, June 08, 2017 08:47:18 PM Jonathan T. Looney wrote: > Author: jtl > Date: Thu Jun 8 20:47:18 2017 > New Revision: 319720 > URL: https://svnweb.freebsd.org/changeset/base/319720 > > Log: > With EARLY_AP_STARTUP enabled, we are seeing crashes in softclock_call_cc() > during bootup. Debugging information shows that softclock_call_cc() is > trying to execute the vt_consdev.vd_timer callout, and the callout > structure contains a NULL c_func. > > This appears to be due to a race between vt_upgrade() running > callout_reset() and vt_resume_flush_timer() calling callout_schedule(). > > Fix the race by ensuring that vd_timer_armed is always set before > attempting to (re)schedule the callout. > > Discussed with: emaste > MFC after: 2 weeks > Sponsored by: Netflix > Differential Revision: https://reviews.freebsd.org/D9828 This should probably be using atomic_thread_fence_foo() in conjunction with a simple 'vd->vd_timer_armed = 1' assignment instead of abusing atomic_add_acq_int(). Unfortunately atomic_thread_fence_*() aren't yet documented in atomic(9). :( The commit message that added them is below though: ------------------------------------------------------------------------ r285283 | kib | 2015-07-08 11:12:24 -0700 (Wed, 08 Jul 2015) | 22 lines Add the atomic_thread_fence() family of functions with intent to provide a semantic defined by the C11 fences with corresponding memory_order. atomic_thread_fence_acq() gives r | r, w, where r and w are read and write accesses, and | denotes the fence itself. atomic_thread_fence_rel() is r, w | w. atomic_thread_fence_acq_rel() is the combination of the acquire and release in single operation. Note that reads after the acq+rel fence could be made visible before writes preceeding the fence. atomic_thread_fence_seq_cst() orders all accesses before/after the fence, and the fence itself is globally ordered against other sequentially consistent atomic operations. Reviewed by: alc Discussed with: bde Sponsored by: The FreeBSD Foundation MFC after: 3 weeks ------------------------------------------------------------------------ That said, it is hard to see how a bare acquire barrier is really sufficient for anything. Acquire barriers generally must be paired with a release barrier in order to provide sychronization. -- John Baldwin