From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9294C194A73 for ; Thu, 19 Dec 2024 16:45:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734626742; cv=none; b=XhsydjavrSnoNy+Ms2wk2Exzx/NEMsPcK5VsPH7yXNiYI08cgQ1iclx4rN2AsQ0YWaItSqVyZFnKtznCjkZpnaTiO4VihslGARYh+dRaq+UaNI6r4gGVfFYU9XZlOsH+vmAPRgWxHAnjPri2r9Xd7980qm5IWRYM4rQz1GCqq50= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734626742; c=relaxed/simple; bh=yrIrfOC6j2286jnpL7n3tkwpxRhkeBG+qIwc5+49gC0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ZcMFsQeCwREZUlA91oncRFvytIhY5FM+GTIPqIlEcZ+g5x+yAB43YDx2CAS0b5sK/sg9SqkEy9FRQ5I6TLP69QqJViKVd0YmdLiX++rnBCQ8W8r9cisUfusYPrboUJHjTsO5d1Q1roMiqd8C+0d45vt6I3Ynuuz2ZnuEZbwyouE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QeDfUcAc; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QeDfUcAc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734626739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wSA4RnXFYPEtm6gk2293X+dgNZrk1xJp7WiMMlW7QDM=; b=QeDfUcAcLB3UGLHd8zHqrHLvo9tNTOzXOqN+++EkatMPBnHN0WI+/gsKyNsWoIQqiOrQKE sy6Uv+XRfZM4h3CY5d3kwrAFu/A5f+2rMPwCPKf2mFFem8vqsszgqxbJEIN8/G3uhGnzlx wcJU9Daj92kprB+hPmrHOs4aYtJLZ6s= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-16-RyfyMLOqPRSt60p-u5GyOg-1; Thu, 19 Dec 2024 11:45:34 -0500 X-MC-Unique: RyfyMLOqPRSt60p-u5GyOg-1 X-Mimecast-MFC-AGG-ID: RyfyMLOqPRSt60p-u5GyOg Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EBF2919112EF; Thu, 19 Dec 2024 16:45:23 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.21]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DF72D19560A2; Thu, 19 Dec 2024 16:45:18 +0000 (UTC) From: Florian Weimer To: "Paul E. McKenney" Cc: Peter Zijlstra , Daniel Xu , mingo@redhat.com, will@kernel.org, longman@redhat.com, boqun.feng@gmail.com, linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org Subject: Re: [PATCH] seqlock: Use WRITE_ONCE() when updating sequence In-Reply-To: (Paul E. McKenney's message of "Thu, 19 Dec 2024 08:10:55 -0800") References: <0eaea03ecc9df536649763cfecda356fc38b6938.1734477414.git.dxu@dxuuu.xyz> <20241218103000.GK11133@noisy.programming.kicks-ass.net> <20241218162325.GH2354@noisy.programming.kicks-ass.net> <20241218162934.GJ12500@noisy.programming.kicks-ass.net> <9b6d585a-c17f-4dd1-9518-b28ac2dfd855@paulmck-laptop> <20241218171241.GN2354@noisy.programming.kicks-ass.net> <87v7vgzrxk.fsf@oldenburg.str.redhat.com> Date: Thu, 19 Dec 2024 17:45:15 +0100 Message-ID: <87v7vfwrj8.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 * Paul E. McKenney: > On Wed, Dec 18, 2024 at 08:56:07PM +0100, Florian Weimer wrote: >> * Peter Zijlstra: >>=20 >> > +linux-toolchains >> > >> > On Wed, Dec 18, 2024 at 08:59:47AM -0800, Paul E. McKenney wrote: >> > >> >> > Perhaps something like: (*(volatile unsigned int *)&s->sequence)++;= ? >> >> > I'd have to check what the compiler makes of that. >> >> >=20 >> >> > /me mucks about with godbolt for a bit... >> >> >=20 >> >> > GCC doesn't optimize that, but Clang does. >> >> >=20 >> >> > I would still very much refrain from making this change until both >> >> > compilers can generate sane code for it. >> >>=20 >> >> Is GCC on track to do this, or do we need to encourage them? >> > >> > I have no clue; probably wise to offer encouragement. >>=20 >> What do you consider sane code? > > Peter's "(*(volatile unsigned int *)&s->sequence)++;" qualifies as sane. I think the reference was originally to machine code. >> Clang's choice to generate an incl instruction (on x86-64 at least) is a >> bit surprising. Curiously, the C11 abstract machine has a value-less >> increment-in-place operation, so it's probably not in violation of the >> volatile rules. (C doesn't specify x++ in terms of ++x and x +=3D 1.) > > Very good! Should I do something like file a bug somewhere to help > this along? I don't know. It seems that Clang/LLVM is cheating. It's doing this optimization even for i =3D i + 1; with a volatile i. That doesn't look like =E2=80=9Cstrictly according to t= he abstract machine=E2=80=9D anymore. A proper implementation would need expl= icit representation of volatile increment/decrement in the IR. Given that volatile increment/decrement is deprecated, that seems quite a bit of effort. Thanks, Florian