From nobody Mon Jan 26 18:13:55 2026 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f0Grc6y4Kz6PNyV for ; Mon, 26 Jan 2026 18:14:08 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0Grc3WKcz3bVJ for ; Mon, 26 Jan 2026 18:14:08 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-6581af9c94aso9338993a12.1 for ; Mon, 26 Jan 2026 10:14:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769451247; x=1770056047; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=y9a7pOZ6SLsfE1nMivGBkK07ptUS1fN1a7+CBRNahS0=; b=JHmkU9mHGJsmZ7i28jctoCTME23kK6mNdy6RYQzCqt4ZRyKxxFggpgXNr9rfjX7KrM ox/1IskfORCfD0w7PAESzqJeqOIhktKpq3U5/Wq07/ZQ1UiLW10+26vagYZCZ3JZegFi 5indNFMJXXNwE+glgicCOqd/PXKpljlgwbFawhMICfpRmsB9AjAkBDNt6e979FtO+s4x egPotEL4dsk331dX+iaEU47vl+DyX0jtHRdUY/UJg34kq7kxxRh0ZABSPqC1SmJKlAP5 N8xKAr225WeWJgOdwVs1SNkYcUYoHHSUgY6FurRJzSQXaZBwHwaIlmPVniiuip/hIzxF 9CqQ== X-Forwarded-Encrypted: i=1; AJvYcCVKl+7xdkMTN64esmehjuZONnyXHPPFBB3dZNBpMIwUjqLh5Mz5LMhKQYR3QttX2JGWn90257UU5Mu6EEX/1PznJ+6nHQ==@freebsd.org X-Gm-Message-State: AOJu0YyaRNxrz5C9Nd+Ar0yEO6o/YKvl4xi0/3wiacUSHGfRHiGsMJlJ clJGx02PIPI4LxPL7cliFOp34Rbm/C1kXqzVrt98lIr0FCD7+tYrIkt46dEq8cholv8= X-Gm-Gg: AZuq6aL0A/yYlZcG1WncFRvwPlhnuBxV0xYLMgkgoB74nFWIxABxQ5/xH3jAjNtRRzz toLrQJunfwAiF5dvt1d9py5rOXr56XqcPA5Ff2M0llR/bpCnlQFhDbsHOgnd0kn8UR/bfm4H3wG 2rCNNzxGz0k0gG+F+ylODZIa02eB3qr47btsyoWcky/50gRbJmHGqJDlDrwH6RB/tCX+oAZPUHK tm6Q3wFXkzC8BMfPLOCCduov2/g1LFPztxYkTQnTNYnhqMo1wZYR3qyyDBeQ1I9k8ePsRQ2cTV5 WaJfcYx8H0ktbxuSDTuTLk/jLW6KRJcheeS1VcQQSexZPkJhAHwa45YyURGQ99yxOnn/4D1/J0S nTlx0jJmLOiqs0fn+anta+BOeIZ6UhiwiD+gfGFYUs7bnnmhljzxB+srj2yqG+GEPhKxT4GmcK9 IkpZoW2KnOzYuVqO+Y/ll7r/PfP2uLtmx0ihu7Gve876CSGVOaTvJ2bZ1xIggg0DZhUw== X-Received: by 2002:a17:907:782:b0:b87:965:9079 with SMTP id a640c23a62f3a-b8d0a739e7emr330092266b.3.1769451246794; Mon, 26 Jan 2026 10:14:06 -0800 (PST) Received: from smtpclient.apple (nat-184-41.net.cam.ac.uk. [131.111.184.41]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b7b1a7fsm662056666b.58.2026.01.26.10.14.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2026 10:14:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: git: e769bc771843 - main - sym(4): Employ memory barriers also on x86 From: Jessica Clarke In-Reply-To: Date: Mon, 26 Jan 2026 18:13:55 +0000 Cc: Marius Strobl , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <69778ef9.39b4d.5c480abe@gitrepo.freebsd.org> To: Konstantin Belousov X-Mailer: Apple Mail (2.3864.300.41.1.7) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f0Grc3WKcz3bVJ On 26 Jan 2026, at 16:34, Konstantin Belousov = wrote: > On Mon, Jan 26, 2026 at 03:57:45PM +0000, Marius Strobl wrote: >> The branch main has been updated by marius: >>=20 >> URL: = https://cgit.FreeBSD.org/src/commit/?id=3De769bc77184312b6137a9b180c97b87c= 0760b849 >>=20 >> commit e769bc77184312b6137a9b180c97b87c0760b849 >> Author: Marius Strobl >> AuthorDate: 2026-01-26 13:58:57 +0000 >> Commit: Marius Strobl >> CommitDate: 2026-01-26 15:54:48 +0000 >>=20 >> sym(4): Employ memory barriers also on x86 >>=20 >> In an MP world, it doesn't hold that x86 requires no memory = barriers. > It does hold. x86 is much more strongly ordered than all other arches > we currently support. >=20 > That said, the use of the barriers in drivers is usually not justified > (I did not looked at this specific case). >=20 > Even if needed, please stop using rmb/wmb etc. Use = atomic_thread_fence() > of appropriate kind, see atomic(9). Then on x86 it does the right = thing. atomic_thread_fence() isn=E2=80=99t appropriate when dealing with MMIO = devices. Ideally all this would use bus_space_* and that would handle everything. Jessica >> This change should also fix panics due to out-of-sync data seen = with >> FreeBSD VMs on top of OpenStack and HBAs of type lsiLogic. [1] >>=20 >> While at it: >> - Improve the granularity somewhat by distinguishing between read = and >> write memory barriers as well as refer to existing *mb(9) = functions >> instead of duplicating these [2], unless IO barriers are also = used. >> - Nuke the unused SYM_DRIVER_NAME macro. >>=20 >> PR: 270816 [1] >> Obtained from: BSD-licensed Linux sym53c8xx driver [2] >> MFC after: 1 week >> --- >> sys/dev/sym/sym_hipd.c | 42 = +++++++++++++++--------------------------- >> 1 file changed, 15 insertions(+), 27 deletions(-) >>=20 >> diff --git a/sys/dev/sym/sym_hipd.c b/sys/dev/sym/sym_hipd.c >> index 0e51607fb07a..f78d595a73ce 100644 >> --- a/sys/dev/sym/sym_hipd.c >> +++ b/sys/dev/sym/sym_hipd.c >> @@ -58,7 +58,6 @@ >> */ >>=20 >> #include >> -#define SYM_DRIVER_NAME "sym-1.6.5-20000902" >>=20 >> /* #define SYM_DEBUG_GENERIC_SUPPORT */ >>=20 >> @@ -114,27 +113,16 @@ typedef u_int32_t u32; >> #include >>=20 >> /* >> - * IA32 architecture does not reorder STORES and prevents >> - * LOADS from passing STORES. It is called `program order' >> - * by Intel and allows device drivers to deal with memory >> - * ordering by only ensuring that the code is not reordered >> - * by the compiler when ordering is required. >> - * Other architectures implement a weaker ordering that >> - * requires memory barriers (and also IO barriers when they >> - * make sense) to be used. >> - */ >> -#if defined __i386__ || defined __amd64__ >> -#define MEMORY_BARRIER() do { ; } while(0) >> -#elif defined __powerpc__ >> -#define MEMORY_BARRIER() __asm__ volatile("eieio; sync" : : : = "memory") >> -#elif defined __arm__ >> -#define MEMORY_BARRIER() dmb() >> -#elif defined __aarch64__ >> -#define MEMORY_BARRIER() dmb(sy) >> -#elif defined __riscv >> -#define MEMORY_BARRIER() fence() >> + * Architectures may implement weak ordering that requires memory = barriers >> + * to be used for LOADS and STORES to become globally visible (and = also IO >> + * barriers when they make sense). >> + */ >> +#ifdef __powerpc__ >> +#define MEMORY_READ_BARRIER() __asm__ volatile("eieio; sync" : : : = "memory") >> +#define MEMORY_WRITE_BARRIER() MEMORY_READ_BARRIER() >> #else >> -#error "Not supported platform" >> +#define MEMORY_READ_BARRIER() rmb() >> +#define MEMORY_WRITE_BARRIER() wmb() >> #endif >>=20 >> /* >> @@ -892,13 +880,13 @@ struct sym_nvram { >> */ >> #define OUTL_DSP(v) \ >> do { \ >> - MEMORY_BARRIER(); \ >> + MEMORY_WRITE_BARRIER(); \ >> OUTL (nc_dsp, (v)); \ >> } while (0) >>=20 >> #define OUTONB_STD() \ >> do { \ >> - MEMORY_BARRIER(); \ >> + MEMORY_WRITE_BARRIER(); \ >> OUTONB (nc_dcntl, (STD|NOCOM)); \ >> } while (0) >>=20 >> @@ -2908,7 +2896,7 @@ static void sym_put_start_queue(hcb_p np, ccb_p = cp) >> if (qidx >=3D MAX_QUEUE*2) qidx =3D 0; >>=20 >> np->squeue [qidx] =3D cpu_to_scr(np->idletask_ba); >> - MEMORY_BARRIER(); >> + MEMORY_WRITE_BARRIER(); >> np->squeue [np->squeueput] =3D cpu_to_scr(cp->ccb_ba); >>=20 >> np->squeueput =3D qidx; >> @@ -2920,7 +2908,7 @@ static void sym_put_start_queue(hcb_p np, ccb_p = cp) >> * Script processor may be waiting for reselect. >> * Wake it up. >> */ >> - MEMORY_BARRIER(); >> + MEMORY_WRITE_BARRIER(); >> OUTB (nc_istat, SIGP|np->istat_sem); >> } >>=20 >> @@ -3061,7 +3049,7 @@ static int sym_wakeup_done (hcb_p np) >>=20 >> cp =3D sym_ccb_from_dsa(np, dsa); >> if (cp) { >> - MEMORY_BARRIER(); >> + MEMORY_READ_BARRIER(); >> sym_complete_ok (np, cp); >> ++n; >> } else >> @@ -3859,7 +3847,7 @@ static void sym_intr1 (hcb_p np) >> * On paper, a memory barrier may be needed here. >> * And since we are paranoid ... :) >> */ >> - MEMORY_BARRIER(); >> + MEMORY_READ_BARRIER(); >>=20 >> /* >> * First, interrupts we want to service cleanly. >=20