From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B4C7286417 for ; Thu, 21 May 2026 02:37:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779331040; cv=none; b=nanSwSzfbe9IhWC1+j+mIXtvkRJL0z05zvc1Wqb9VSjKdaWTio2c9aF9Vh6OX5eSVs1oGLlm6QgqVH2Y7ZUmrw/wk2Jn6U74mLZwjZh3/HegAWXFeh4TkDnFgq/XYNi6kRgibk8hh2GnLACgUSuxhRFX7xhKpsgEAUgnn8+E6F0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779331040; c=relaxed/simple; bh=hvP+zx5nDdySfGXoXc3/DIIrPxhFWJ7VUfVTgfDPrRo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type:Content-Disposition; b=k5mTMKxgzEdGYIeQlN9f3mUhMKHs5mG5XkobAuFPc5AX4QUYkGWB+I6LfV4wx+Jc9ha0oApiVB348UYyPcrrBUM+yQ29u8w19Urq7QgRL3oLgIUENFE5iZYDyH+dphSpHqVLOtS60zyr+AUeID74+bwTYmp+oKaO3/WwQyKhU1k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=onsgQubU; arc=none smtp.client-ip=209.85.216.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="onsgQubU" Received: by mail-pj1-f67.google.com with SMTP id 98e67ed59e1d1-369002b26f4so3044819a91.3 for ; Wed, 20 May 2026 19:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779331039; x=1779935839; darn=vger.kernel.org; h=content-transfer-encoding:content-disposition:mime-version :mail-followup-to:references:in-reply-to:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=e3VXZEZTkDJvE/SCtCoJk4/cTfgLUHmkSXPo8xqseOk=; b=onsgQubU/kgx/G2DdUwFlrg/t3/ANUs6CPop6n4AuuDfyKhhZzjWppPRxAcU1zEgnv /qSKKz3lrbGOs5k7n+UqZJ1rF9+bQkbRZo4S7yWHceQjcYYJbiOt28B7uI7hMbN7Pk6p UyluhnRSVjEiAVr7TCeXeHmccH+nOVev5y3cqAhFEcejyI3Vd6IqclJWzi/fHZr6H1sl /GIAYufA9oShXNR5PzAjPNBLLBPsT+tuTumqc1U0D6ayxA4Fhk0FB6OpmN5KnoFSwr7d uyslNqr7tDYUfJ98JNiS9xYhAvU+L9jwwj6je8gzOcAExsOCnnob+XSgsU260e0mUAHm uzGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779331039; x=1779935839; h=content-transfer-encoding:content-disposition:mime-version :mail-followup-to:references:in-reply-to:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e3VXZEZTkDJvE/SCtCoJk4/cTfgLUHmkSXPo8xqseOk=; b=lQ8cGFmLiOpRCh7q7Ofx2uUFizm4SpdE9A+GLjhbkO/4f77eG4qurPPx1iG+ZioDCA jhmuE+Y6fLdt0QAUpCXcp/wCEJwJNXg81sG+597hUNnY0aoL9jucGU1uOdmZz+xjaneY qf48wxTGWTUSZAk0k5Y4dj1aCovPXliEOIYaB3nNcu7JmgCn7p7M5mDfzrhK0UwlpYNR DVrAhgpT/2Dpq18wtqn9HUCjso+XN975TxUddU/JMnrlnbTsEVQrQIlHg5wtyfpJr0Dh BhtlrXFQOP9WAcW7ww2JyiukZV/YsAb5PfTmBDsm4W8VfBhGR9BGuM8UgdJKddIuRyek v8mg== X-Forwarded-Encrypted: i=1; AFNElJ9fotgiiQhIdwf2UgOObn/U1LLjrxeTy/UhYxYA3K+xL+TTaSZDrADRiJzM4VvqrvQDrBSnSRIJ1cbFITk=@vger.kernel.org X-Gm-Message-State: AOJu0YySY6RN6svm2gx1mLnhINAJSEgC2Fk2IbPls+IDutRUv6W4kgPS IOpj0/vTZln/ETNCZEYl2MPnpWHgq7t08vvZFXqZPbF5u4/lUeFM/Thy X-Gm-Gg: Acq92OEJVMgWTQrGxU/wbu/22QJ5AmEpzkdviQCp4puD8B5YqawRIRoRekeRnMAuVi2 CXNbwi8OZ1xltrYZLM7D3YruFyUu4+NE5VsQTKi+oOXoJI4R01ziQTRGXNDLOCRI+big8bC2NkW 0gNKwl7WmGNFjrub1ZsCIsxycEpjJeWmRwvWYAO4lZQBZ51f+9m9i9H3DE6k+N9sMAWjDCEUidy oYs9SOeuNmjXEQZqW+fI+HkJefcmGaqxjtLcGfM7leL/cUvDYNaIOLoprvdbFc1Cp7i8b7C2Vb8 Aps/ZWF168WlMSSEvfDhtaUjwZteOFUjNyEbpz4qdAFzyUIxxYl3tWd6yngAghRd4E9mCMtmzEy nV3sTKIZWG73tVNzgazl6OuJkVUO9yF3MdhUAOR8nSRJ/9E565J04XwT/NKid9rmv2euFHZ8Bzi L0oXppgfnMttv6gDkF5WXrd3+nzRk3u7kSkTj2 X-Received: by 2002:a17:902:d591:b0:2be:3dbc:eee5 with SMTP id d9443c01a7336-2bea2fcfd85mr7414165ad.2.1779331038883; Wed, 20 May 2026 19:37:18 -0700 (PDT) Received: from localhost.localdomain ([116.80.91.208]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bd5d0f9155sm245183765ad.59.2026.05.20.19.37.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 19:37:18 -0700 (PDT) From: Cunlong Li To: Shakeel Butt Cc: Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cgroup: rstat: relax NMI guard after switch to try_cmpxchg Date: Thu, 21 May 2026 10:37:12 +0800 Message-Id: X-Mailer: git-send-email 2.30.2 In-Reply-To: References: <20260520-nmi-v1-1-f2c8f08e4a2b@gmail.com> Mail-Followup-To: Cunlong Li , Shakeel Butt , Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org 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=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, May 20, 2026 at 03:41:02PM -0700, Shakeel Butt wrote: > On Wed, May 20, 2026 at 11:30:54AM +0800, Cunlong Li wrote: > > Commit 36df6e3dbd7e ("cgroup: make css_rstat_updated nmi safe") used > > this_cpu_cmpxchg() for the lockless insertion, and therefore required > > both ARCH_HAVE_NMI_SAFE_CMPXCHG and ARCH_HAS_NMI_SAFE_THIS_CPU_OPS in > > the NMI guard: on archs without the latter, this_cpu_cmpxchg() falls > > back to "local_irq_save() + plain cmpxchg", and local_irq_save() > > cannot mask NMIs. > > > > Commit 3309b63a2281 ("cgroup: rstat: use LOCK CMPXCHG in > > css_rstat_updated") later replaced this_cpu_cmpxchg() with plain > > try_cmpxchg() to fix cross-CPU lockless-list corruption, but left the > > NMI guard untouched. After that switch, css_rstat_updated() no longer > > performs any this_cpu_*() RMW operations and only relies on the arch > > having NMI-safe cmpxchg, so ARCH_HAS_NMI_SAFE_THIS_CPU_OPS is no > > longer required in the guard. > > > > Relax the guard accordingly so that archs which have HAVE_NMI and > > ARCH_HAVE_NMI_SAFE_CMPXCHG but not ARCH_HAS_NMI_SAFE_THIS_CPU_OPS > > (e.g. sparc, powerpc on PPC64/BOOK3S) can benefit from the existing > > CONFIG_MEMCG_NMI_SAFETY_REQUIRES_ATOMIC path. Without this, the css > > is never queued in NMI on those archs, and the atomics staged by > > account_{slab,kmem}_nmi_safe() are not drained by flush_nmi_stats(). > > > > Fixes: 3309b63a2281 ("cgroup: rstat: use LOCK CMPXCHG in css_rstat_updated") > > Signed-off-by: Cunlong Li > > Looks fine but how did you find this? AI? > > Acked-by: Shakeel Butt > Yes, AI-assisted. I'm new to kernel development and was studying the memcg code. When I came across the guard in css_rstat_updated(): if ((!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) || !IS_ENABLED(CONFIG_ARCH_HAS_NMI_SAFE_THIS_CPU_OPS)) && in_nmi()) return; I asked Opus what those two CONFIGs mean and why the function returns when in_nmi(). It suggested ARCH_HAS_NMI_SAFE_THIS_CPU_OPS may no longer be required after the switch from this_cpu_cmpxchg() to try_cmpxchg(). I then went through the related commit history and confirmed the analysis. Thanks for the ack!