From owner-svn-src-all@freebsd.org Thu Apr 25 04:08:28 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 804C6158B3B8; Thu, 25 Apr 2019 04:08:28 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BCC08ED99; Thu, 25 Apr 2019 04:08:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl1-x644.google.com with SMTP id e92so8591572plb.6; Wed, 24 Apr 2019 21:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=p8jbiuyxaplEvCnupBR5vHGr5oPJxeMrOPaiyUBQtkU=; b=gWt/kJ0uTajqf/X81TNMc4oMtTNWVAgwHKJqkuROP+b9UjrJbXgpVmUPKfRpB87LL5 Xdj1g0Gn+1DehdMC+UsK8XSxESiJ+MPlt8uKruj1lFAehcR8XcdMhC2Js9E0VSoorod7 qCDyqytu1QcW/xy+BupmKmumcquErtGvUTfw3qnqatIBgpbDPnfUSHZJTBF7yrLcU5z3 XwToe/TYzcYeD/7aw5zyYqWSg5Ia2Ww41MsxwWf4/PZaO+dtxUFSD6/HXqAsw/IefttO ONZwd39ZiJ0T1FOQnteJaQC21HL4qYYZgncWlSS70z4f20Wc5ZubS0DbN4XEFFHWSSqH 7fPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=p8jbiuyxaplEvCnupBR5vHGr5oPJxeMrOPaiyUBQtkU=; b=DX5Ffg5v5HudFulNWYGvYOFOJAyGi37uPy4aWqUhg4ITtr7ixfE4JJanGHO5LRQsjA 7nXmke1HYnNhGwNz6hIkji/vhZajJvagw7h38KVVNRvZnsW5Caa9ofLnyNH0vHd3MLhk LCxk1DhAm3k/Bwt1WMdN2CuMPoTpFG8YIXXRyDnDqANM+64khI6LlnaGzga1dTPGJf4S nVa+uRM+9HS1jYqH5eerGhjfaFGLBiaLluXu8gBA0Kj9HfO0s9aZVl04g3RQLz4ysuNG LWMkRQE49cwsiV+mpfPrJ785346Abjxq4OihSDh07WOqiA7KHyOKMJas1imdhtrM/D6z Te9w== X-Gm-Message-State: APjAAAX0bdAcl65qeX0nk6IaGvw2BETQ3rk6n+cXKJA+8rz+mAWeyM9k BdqiL6WKaPGMixLuwXdZcSt+svoq X-Google-Smtp-Source: APXvYqzerPyAuR0783n/aSAHriAZhgsBlwOubA+3vXnVg0cf3OBhE+QoW6qtQx44XSBYIiMdtq2Prg== X-Received: by 2002:a17:902:b481:: with SMTP id y1mr36988969plr.161.1556165304761; Wed, 24 Apr 2019 21:08:24 -0700 (PDT) Received: from spy (122-117-120-220.HINET-IP.hinet.net. [122.117.120.220]) by smtp.gmail.com with ESMTPSA id j22sm689678pfi.139.2019.04.24.21.08.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Apr 2019 21:08:23 -0700 (PDT) Sender: Mark Johnston Date: Thu, 25 Apr 2019 00:08:17 -0400 From: Mark Johnston To: Wojciech Macek Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r346593 - head/sys/sys Message-ID: <20190425040817.GA3789@spy> References: <201904230636.x3N6aWQK057863@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201904230636.x3N6aWQK057863@repo.freebsd.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 1BCC08ED99 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=gWt/kJ0u; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::644 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.28 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[4.4.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.78)[-0.777,0]; IP_SCORE(-0.79)[ip: (1.50), ipnet: 2607:f8b0::/32(-3.13), asn: 15169(-2.26), country: US(-0.06)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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, 25 Apr 2019 04:08:28 -0000 On Tue, Apr 23, 2019 at 06:36:32AM +0000, Wojciech Macek wrote: > Author: wma > Date: Tue Apr 23 06:36:32 2019 > New Revision: 346593 > URL: https://svnweb.freebsd.org/changeset/base/346593 > > Log: > This patch offers a workaround to buf_ring reordering > visible on armv7 and armv8. Similar issue to rS302292. > > Obtained from: Semihalf > Authored by: Michal Krawczyk > Approved by: wma > Differential Revision: https://reviews.freebsd.org/D19932 > > Modified: > head/sys/sys/buf_ring.h > > Modified: head/sys/sys/buf_ring.h > ============================================================================== > --- head/sys/sys/buf_ring.h Tue Apr 23 04:06:26 2019 (r346592) > +++ head/sys/sys/buf_ring.h Tue Apr 23 06:36:32 2019 (r346593) > @@ -310,14 +310,23 @@ buf_ring_peek_clear_sc(struct buf_ring *br) > if (!mtx_owned(br->br_lock)) > panic("lock not held on single consumer dequeue"); > #endif > - /* > - * I believe it is safe to not have a memory barrier > - * here because we control cons and tail is worst case > - * a lagging indicator so we worst case we might > - * return NULL immediately after a buffer has been enqueued > - */ > + > if (br->br_cons_head == br->br_prod_tail) > return (NULL); > + > +#if defined(__arm__) || defined(__aarch64__) > + /* > + * The barrier is required there on ARM and ARM64 to ensure, that > + * br->br_ring[br->br_cons_head] will not be fetched before the above > + * condition is checked. > + * Without the barrier, it is possible, that buffer will be fetched > + * before the enqueue will put mbuf into br, then, in the meantime, the > + * enqueue will update the array and the br_prod_tail, and the > + * conditional check will be true, so we will return previously fetched > + * (and invalid) buffer. > + */ > + atomic_thread_fence_acq(); > +#endif Why is it specific to ARM?