From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81A75C83030 for ; Fri, 4 Jul 2025 01:54:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C76F8E0018; Thu, 3 Jul 2025 21:54:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79EFA8E0009; Thu, 3 Jul 2025 21:54:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DBA08E0018; Thu, 3 Jul 2025 21:54:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5A2EA8E0009 for ; Thu, 3 Jul 2025 21:54:21 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 281FD1081D4 for ; Fri, 4 Jul 2025 01:54:20 +0000 (UTC) X-FDA: 83624912280.22.DA2A8FD Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf11.hostedemail.com (Postfix) with ESMTP id D218E40002 for ; Fri, 4 Jul 2025 01:54:17 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NLB16W4S; spf=pass (imf11.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751594058; h=from:from:sender: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:dkim-signature; bh=5zUFgNGFp2OU4bUfryivIV0PkBSaxkBjWLGPlV+/kxg=; b=cdzqe5I1y4Y2Nn8zT3rMkwfbvP571J5V8hZwCgCLpPDoLNZ1nGRMpKTD0JiIKcC5KEt9Fk 3rzEX0DzAGzMYAXrBopXOj4SEg8gytoalyF8+XqX+uePDlLcqVgwRHAg+63dKwm6HOk3Cy 0Z2eTBGLMlj9ybZZsHGztGq3LirO7TQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751594058; a=rsa-sha256; cv=none; b=h3ZjafXpnnaKi/npEokDyCpd+D9Fw9DkCcQMUL3QRXYlaIXt3UA6208ekVLE40oQIzkXiZ eBdIcqkF+D+y4nApRxPAmd1M3AZp6uPtkcwk0tZ101xaWk+m/bzslJU6/AVDu5tClx33Tg Wx3W8cXo0UPJzQBZRCZQj32lf1p/Dv0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NLB16W4S; spf=pass (imf11.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Forwarded-Encrypted: i=1; AJvYcCW2pUnoVD72DxhRBP2VNkvQp7kR40ap4O45Z0Vr0MiSPHlCV8RS8QmdFecn6aJAfWzrd3oZmHPnFA==@kvack.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1751594055; 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=5zUFgNGFp2OU4bUfryivIV0PkBSaxkBjWLGPlV+/kxg=; b=NLB16W4SwlmLhdLXAkfD7y/MtWP1PCgRegPFhVrIvzU6oj7epAaM0KUy+MQwLY5Llc0vzS mm0Mzkq+7HxC2Hn9cCNPoEiSvHoRyGxUzcrik8HKXTkB2hE6jA5kE5lbx6WGGqI0my+81s iIm5aU9qjBUpPfXB/7i8GSI/EUMTukM= X-Gm-Message-State: AOJu0YxVwGcO3tqD48RMucwURdxnI5DeZDhFoZK6w8o1ETQjjqk8S5I3 BB1FNwHI3U+jMLwAJuIU5ilGU/GDNCN7T9DVXC6JkC3sEbE2ExMSszDuYGV0BOpjarvE0y4+j7e Ph3sHSwMOv18zafPUNdKSuaRcWNKMfA0= X-Google-Smtp-Source: AGHT+IHRp6cTYv2ZHhR/OqEQNvtHD+Kd9XEFyWCdJBjr2fL9kfV74hSEp+yyV6sRdSRdWq6c0+lR+1sTP0wHrzTW07E= X-Received: by 2002:a05:6102:6c1:b0:4ec:b2cc:de60 with SMTP id ada2fe7eead31-4f2f1ebdc71mr162883137.11.1751594053446; Thu, 03 Jul 2025 18:54:13 -0700 (PDT) MIME-Version: 1.0 References: <20250703200012.3734798-1-shakeel.butt@linux.dev> <20250703200012.3734798-2-shakeel.butt@linux.dev> In-Reply-To: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt Date: Thu, 3 Jul 2025 18:54:02 -0700 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXx-lZjWHd45ZSUnauMrY3R7tVAdMQDZfFbYy-kqIPMaM-Muufg8oe5W5TU Message-ID: Subject: Re: [PATCH 2/2] cgroup: explain the race between updater and flusher To: paulmck@kernel.org Cc: Tejun Heo , Andrew Morton , JP Kobryn , Johannes Weiner , Ying Huang , Vlastimil Babka , Alexei Starovoitov , Sebastian Andrzej Siewior , =?UTF-8?Q?Michal_Koutn=C3=BD?= , bpf@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D218E40002 X-Stat-Signature: 8xy47brzjdxj5mmipekodh6teb86na8y X-HE-Tag: 1751594057-912428 X-HE-Meta: U2FsdGVkX19J/K5tt3P+IPM3un+cZqxnRpmJTbbEFXN5i2BB/VNXHUGoHmwVZHJQqPYGsUWqawZ/G/6Jb8mL8aCHh8ndiZIAVtQzvPpzx6bH4CLr5G8v1RboOVlnHaD14kjx9iilovBz+jOMrOzOwDkCKWRqApVFqMWmhW4pKESxezzBecniqfPmDJN2H9M/cvA4gy1a79EZciZlDl0XY3ACZr0082Dvt/Dxrwh7R507JacDaA1i9uGwrA0P01SSNy3PoZ93+Fh3o8bklyeFAI7fQy6n1k8wzb55E6FdCPLulVCdFU51cHjjEuivqBWf5lbvOr67+DhyUdPTOSAlkNa+0Xi8NH/6+eeC/Pb9mDFQCvQWIr55g0Cx5rqxNOVUnqKQ8BuEY4TKq4gNJhOmiB3k+jkwt48rJVVCGpG8E14MnRrJyW7Xbnm7t0vpiTeBEZe6pDzGMhOJmv6J6sfGaD3fNQCzANfKhxNcn4/5Gce9y0uUs7v9bwk5mmAWnmrkMmJGC3ZS7rl7HK7UHE8H4+2X0739qUUkz115cnwP29GEcGQ61tPAv8EAFh1eUSQX0HCABPTlwi4u6CnGsDnQPwu5ilvITlrIc3oGoRusFxJ7Yf+PMYJ++fqt4KqmDQe4LSoJ1540qNQasUXLpxpbpflXDmqdxydrAR65QeP67oMFVZnckc9QquS2naPplhWX7vNDNfSJcb+2BQlkMKacS4yQuS8ge0oAqmaAujOcCZeLjoNCtLKj1JSXWNXU+/ZggH4yIWQ9GjqzMhgyrZcRRYWJah3JPHoGH94IPVr5lG1g53ik7r+kkt70ZMboER6ZhK2J4VbfQ3J1YDn2ct/XWRJUFQkkc8Xo4TQpAgaXM/Uz5jMBHxZ4LKxAoG1vsAdYoSeDi2PK4nJYsN+oqVKNWF6QvnLPPW2Ib4KlL+vN2xdrITgxljg9Doz4yhQ7WiNrF06fXvszidZd65kTWS1 RiqG7dCT 69Fp3KCy99Byc4OONKivXAQJqaFsnHFOdJGmrlNpxbGGMVavbpiJgd0ZK5Z+bJpefVsa3O49C3d7Dg3CZFdqMJiROwvV8sM84cgK5NZpcQFkCF2ITMJJsKf0kr8ZrDgL50RDY51+7wfQ/kt2grWvhvxns73NpraUkY+yoGDzQ1GsbD8f7nJe5kxfCf2Y0NPRUd60cCJOE+0o5Sj5GW9Rf3tJeyVt0xMZR/EAPUxhwPxpWXGz1GKx/O5plRrNKSSd60EWZOKRwU7PELGzbdiRPRHHk9Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jul 3, 2025 at 4:53=E2=80=AFPM Paul E. McKenney wrote: > > On Thu, Jul 03, 2025 at 03:46:07PM -0700, Shakeel Butt wrote: [...] > > Let me answer this one first. The previous patch actually made > > init_llist_node() do WRITE_ONCE(). > > > > So the actual question is why do we need > > data_race([READ|WRITE]_ONCE()) instead of just [READ|WRITE]_ONCE()? > > You should *almost* always use [READ|WRITE]_ONCE() instead of data_race()= . > > > Actually I had the similar question myself and found the following > > comment in include/linux/compiler.h: > > > > /** > > * data_race - mark an expression as containing intentional data races > > * > > * This data_race() macro is useful for situations in which data races > > * should be forgiven. One example is diagnostic code that accesses > > * shared variables but is not a part of the core synchronization desig= n. > > * For example, if accesses to a given variable are protected by a lock= , > > * except for diagnostic code, then the accesses under the lock should > > * be plain C-language accesses and those in the diagnostic code should > > * use data_race(). This way, KCSAN will complain if buggy lockless > > * accesses to that variable are introduced, even if the buggy accesses > > * are protected by READ_ONCE() or WRITE_ONCE(). > > * > > * This macro *does not* affect normal code generation, but is a hint > > * to tooling that data races here are to be ignored. If the access mu= st > > * be atomic *and* KCSAN should ignore the access, use both data_race() > > * and READ_ONCE(), for example, data_race(READ_ONCE(x)). > > */ > > > > IIUC correctly, I need to protect llist_node against tearing and as wel= l > > as tell KCSAN to ignore the access for race then I should use both. > > Though I think KCSAN treat [READ|WRITE]_ONCE similar to data_race(), so > > it kind of seem redundant but I think at least I want to convey that we > > need protection against tearing and ignore KCSAN and using both conveys > > that. Let me know if you think otherwise. > > > > thanks a lot for taking a look. > > The thing to remember is that data_race() does not affect the > generated code (except of course when running KCSAN), and thus does > absolutely nothing to prevent load/store tearing. You need things like > [READ|WRITE]_ONCE() to prevent tearing. > > So if it does not affect the generated code, what is the point of > data_race()? > > One answer to this question is for diagnostics where you want KCSAN > to check the main algorithm, but you don't want KCSAN to be confused > by the diagnostic accesses. For example, you might use something like > ASSERT_EXCLUSIVE_ACCESS() as in __list_splice_init_rcu(), and not want > your diagnostic accesses to result in false-positive KCSAN reports > due to interactions with ASSERT_EXCLUSIVE_ACCESS() on some particular > memory location. And if you were to use READ_ONCE() to access that same > memory location in your diagnostics, KCSAN would complain if they ran > concurrently with that ASSERT_EXCLUSIVE_ACCESS(). So you would instead > use data_race() to suppress such complaints. > > Does that make sense? > Thanks a lot Paul for the awesome explanation. Do you think keeping data_race() here would be harmful in a sense that it might cause confusion in future?