NetBSD Problem Report #58140

From www@netbsd.org  Thu Apr 11 14:05:09 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A30E91A923B
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 11 Apr 2024 14:05:09 +0000 (UTC)
Message-Id: <20240411140508.109FD1A923C@mollari.NetBSD.org>
Date: Thu, 11 Apr 2024 14:05:08 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: _ucas_32/64 has unclear memory ordering contract
X-Send-Pr-Version: www-1.0

>Number:         58140
>Category:       kern
>Synopsis:       _ucas_32/64 has unclear memory ordering contract
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 11 14:10:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10
>Organization:
The NetUCAS Membardation
>Environment:
>Description:
The machine-dependent _ucas_32 and _ucas_64 functions, to perform a compare-and-swap on a word in user address space, are used by futex(9) for thread and process synchronization.

The operation is obviously intended to be globally atomic on all CPUs.  But it's not clear what ordering it is supposed to impose on surrounding memory operations.

Here are two possibilities:

(a) Any memory ordering is the caller's responsibility.

    In this case:

    1. We need to audit sys_futex.c to ensure it is using the barriers it needs.  (Possibly none: it may be 100% userland's responsibility.)
    2. mips lock_stubs_llsc.S can skip the SYNC_REL and SYNC_ACQ.

(b) _ucas_32/64 must imply some memory ordering.

    In this case:

    1. We need to determine what ordering it implies, and make sure it works for futex(9).  My guess is either release/acquire ordering (more likely), or sequential consistency ordering (less likely).
    2. aarch64 needs to use LDAXR/STLXR, or DMB ISH if we need seq cst
    3. alpha needs to use MB
    4. arm needs to use DMB
    5. mips lock_stubs_llsc.S needs to use sync if seq cst
    6. powerpc do_ucas_32/64 in locore_subr.S needs to use lwsync/b/isync, or sync/sync if seq cst
    7. riscv needs to use lr.aq and sc.rl, or something else if seq cst
    8. sparc64 probably needs an audit anyway, way too many bizarro membars sprinkled around to eyeball for correctness

In either case:

0. This needs to be documented clearly in the ucas(9) man page.
>How-To-Repeat:
code inspection
>Fix:
Yes, please!

Home	PR Database Search