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.129.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 9CA6915530B for ; Wed, 18 Dec 2024 20:09:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734552566; cv=none; b=pB83zF93QIRJOqKGpGOoH++7vsS7wo7fKVUY1h6sx2t+cZZlF8Z+xgd3e0Q5vYYF7uHK810cGUWbkZbFVinnHWn7ygJAdudjpiMgfcIjp0HHG5SYi/nVSUAs10LXr5k432Yovf3a8TdGb5bB51UCSkmyD/MDLU2KOVyJjdPYjMo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734552566; c=relaxed/simple; bh=cDJx6Mqb/Xc3VqSeXy6sVwNWMBY+/+KnXwN/P7qnd+E=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=A2it8T95liLzA4tjR+u3kOUR2CYAWSjhEYgfOCEUVT/eNJqeTlKGjkDgwvxCElWbYhmQgKNnIQicQ4VZ4NKvdQk4vYlwe6snZOFn4nsbm+98pji+IRpA202DYE2uDbN9Hzf2r347D0iCGaTICk0jXtv5AxgBzUmv/eqhafDvf+o= 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=L9O8Hc4j; arc=none smtp.client-ip=170.10.129.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="L9O8Hc4j" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734552563; 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=zDrl3xeiTZmR9Q8QJELD/M4AtWdLnzj/cuSvj1PpMZs=; b=L9O8Hc4jbaU13hES6jYckS9pZ9VVqCVJUKSjK3g9ctVPimeXf3PueuKl96T3cih+1jXV3B IogVN8EcUusYr8a3K8fYbiVKw5Qu8iC7d1xqEhdm6fAnq9MQZciCFIWUp1uAKqJwPIZgu4 1A11agMxqYfGz3X4nA46FuLqLWicU0c= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-393-rJ5cjj5XMJ-ooXhdLlaLww-1; Wed, 18 Dec 2024 15:09:22 -0500 X-MC-Unique: rJ5cjj5XMJ-ooXhdLlaLww-1 X-Mimecast-MFC-AGG-ID: rJ5cjj5XMJ-ooXhdLlaLww Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-7b6ee0af16dso1125093885a.3 for ; Wed, 18 Dec 2024 12:09:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734552561; x=1735157361; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zDrl3xeiTZmR9Q8QJELD/M4AtWdLnzj/cuSvj1PpMZs=; b=sSz4/ZvZvqEO3fK+sgI6VUeWfZQvTMxyoZZR7q/Ioqx6guLzVnosI0LM/QkJeZo/HF /SPXOqPzULp+0O/fjkeHnBAYL0haG2u1OTga/G7qiOmFkj+1Zmb5OwI+tkLMWYDu7WQb K+rxHtVeYBXqd6RBk0WRwsw9zjNHbtyckZ/Ui56Xk8e2gad0d3Aa0O2TSvAm290xZX17 9FoO07OhNJllNx02/WLq0I/qSaN0t2Ssw+J2dN95e9oklNO3njjksMIq66gxyG5NEHHx ytRrr+Zzu0FkDTJvFG4AzEMq2i/S8B56/UZVl1u8XX3O9DTu5ImDv1njrXOPP7jqKMLY e7aA== X-Forwarded-Encrypted: i=1; AJvYcCVG4Qun3R3mRwNRkLxrBthOq3Hg9ksE9D7svWFk4ATfE9F1Q1XDeGGoaeO0Rmr/rdywtKC+ms1BkO9AD2g=@vger.kernel.org X-Gm-Message-State: AOJu0YzMgffEVBnI/5W1j5xNEIo+ByxBz8KjD0FEHYbg2GjsUVeCxfkw bY1G8fgr3LNkioKmFLZAyaJGpQ5IJxw0TQ6tmymV74rVC5l9Bg9nXGRxOCLOGnXVn02qKtzlUuS M5YQGIQy6cB4S7wFLK5Y5p9aIETqfOIs3EP91g+zYt8MZkiBRz5pYFHO99MG7/g== X-Gm-Gg: ASbGncv/pFdhDsyZ6ml1+JhAcA1BLv4Zwa+wsLlEEOxQFkJuREqyWGsb2hB8Tqah2Jq 3uCuDICgRPYdkunWtzOa3JYciyec3G95M0+HdV+fEws3LABZtSNJPDJarW1BE2NuVzaow9KOCnc KotevmkslvkvQe1i+sa952ag4Te+2dKISylxo0bx3jkdJ2vzR7jG/p26nIHf0Rvtg5HMx/8qEYN ISTV0ZoHUZFGKDWFmtjZjDDw6btdjjK4+nEfgCOG9pZvcT9ApP8vCUWK7ZLU9w/wqavGDkgh57N jBEN6EVoK6isCtMjBdtLzvFO X-Received: by 2002:a05:620a:4108:b0:7b6:6ee8:6c06 with SMTP id af79cd13be357-7b8637550b9mr725550985a.30.1734552561368; Wed, 18 Dec 2024 12:09:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IHPsBEAEKnrR0d/adih1/3WD6FOAtRLgeHOnagYPv5szX8nLr3iiAWvUY4uvyZ8VPlLt55vKw== X-Received: by 2002:a05:620a:4108:b0:7b6:6ee8:6c06 with SMTP id af79cd13be357-7b8637550b9mr725547285a.30.1734552561076; Wed, 18 Dec 2024 12:09:21 -0800 (PST) Received: from ?IPV6:2601:188:ca00:a00:f844:fad5:7984:7bd7? ([2601:188:ca00:a00:f844:fad5:7984:7bd7]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b7048be292sm460828085a.79.2024.12.18.12.09.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Dec 2024 12:09:20 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <93eea003-052d-4a9d-b8e8-a77043f59912@redhat.com> Date: Wed, 18 Dec 2024 15:09:19 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] seqlock: Use WRITE_ONCE() when updating sequence To: paulmck@kernel.org, Waiman Long Cc: Daniel Xu , mingo@redhat.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, linux-kernel@vger.kernel.org References: <0eaea03ecc9df536649763cfecda356fc38b6938.1734477414.git.dxu@dxuuu.xyz> <6fbd26a5-615f-41bf-ad54-91114898cc2c@redhat.com> <21914c89-4f4a-4e09-97de-4d5b99a48243@paulmck-laptop> <8da9c55b-65fb-4c81-b6ea-f80892e3cff7@redhat.com> <13ba988e-15d7-4814-91d9-15b6a4cf05ef@redhat.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/18/24 1:52 PM, Paul E. McKenney wrote: >> If the compiler really uses the variable as a scratch storage, it will be a >> problem if the variable can be accessed concurrently from multiple CPUs. It >> is a new compiler optimization strategy that I am aware before. In that >> case, we may really need a way to mark these variables as not suitable for >> such advanced optimization. > These markings already exist, namely, the "volatile" keyword, READ_ONCE(), > WRITE_ONCE(), and hopefully soon INC_ONCE(). These last three use > volatile accesses internally. > > The scratch-storage possibility exists only just before a normal > C-language store, not before volatile accesses. So a compiler is > forbidden from doing that scratch-value-store trick before a volatile > store. I am aware of that in READ_ONCE() and WRITE_ONCE() and I am looking forward to have a INC_ONCE() and maybe DEC_ONCE() soon. Cheers, Longman