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 14C38C3DA6D for ; Mon, 19 May 2025 06:32:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F18C46B0085; Mon, 19 May 2025 02:31:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA1D46B0088; Mon, 19 May 2025 02:31:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D416C6B0089; Mon, 19 May 2025 02:31:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A88686B0085 for ; Mon, 19 May 2025 02:31:58 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AC2E8C13D1 for ; Mon, 19 May 2025 06:32:02 +0000 (UTC) X-FDA: 83458687284.10.8897CD6 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf22.hostedemail.com (Postfix) with ESMTP id DE130C0004 for ; Mon, 19 May 2025 06:32:00 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=obBozUuY; spf=pass (imf22.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=obBozUuY; spf=pass (imf22.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.179 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=1747636321; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=qhwfp4EBzg3RNOWbJvbUL8OkMdkVj45Lqv1H1O9YUck=; b=4uPIYpbCXJG3+cV4e6NVFhi0r5DQqCUOqjQSNwEJXl7yY1bzqCUBphXGLA+9sn9lqKKc0p lr6zOHJLOIm27L2HeWUbUhA0ZoLpiyfzhfw+vJ04KkAtXXgtlTZna16UWglWvJJuxBilIS 4Jez21+BCQJF3muhQ/uyIuscsmfHcYE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747636321; a=rsa-sha256; cv=none; b=UcKuPEHOkDmalr2+BmfutVqRP5gLPKJ6S0a9N2fozQwS3yRT1fWsMrvfMrRmZlZq+gNPpe R2vkP0XECaCGnEnO5lGb5w+a2lMPAmRX8QQp7KS4ywlZRKQ5WfeJ2RS08y+HQQWQM2MTk3 +HwZk1qFlk87OzBN0bxcFUm1pMMvKTs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747636317; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qhwfp4EBzg3RNOWbJvbUL8OkMdkVj45Lqv1H1O9YUck=; b=obBozUuYgXdLhdigMtpTnfWbC/7w0awskie0wRvHeJkMInnYpWmeuUGZ+VZdXe8Negeb1V zcVVgf+s6Pa/xxAC+r2hLVPQfy2IAHTzZQ6ecYLgHQC4KLxeqLPDfXiX4iMdzgnn1gxDyG LuBYRBi7IhifT+NU73qxjSkfP3Clsh4= From: Shakeel Butt To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Vlastimil Babka , Alexei Starovoitov , Sebastian Andrzej Siewior , Harry Yoo , Yosry Ahmed , Peter Zijlstra , Mathieu Desnoyers , Tejun Heo , bpf@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: [PATCH v4 0/5] memcg: nmi-safe kmem charging Date: Sun, 18 May 2025 23:31:37 -0700 Message-ID: <20250519063142.111219-1-shakeel.butt@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DE130C0004 X-Stat-Signature: atw73neusei58bye4ra7ueusp8picbw7 X-Rspam-User: X-HE-Tag: 1747636320-974519 X-HE-Meta: U2FsdGVkX1+qSa5oxYtNcBnP0rNIRCtmQCFedp80tBKNvU551ZQfTaj4T2PJqdq3uSSspHeG8fHvwYNvZHoyFUnUC7sKEqyhwDnoSaZtpfVhUOM5wG0Mar7YpL0fN84za6TFzynhr5Ave3NHKwXnH1pmESHNJ6gVgTWl0SAggMvJm5WzUdQrZsG3oYdN0LCVv2fN6qpTb+/nndfzfEFVMamC+g6p5IS7I3ELSl3TQYMByFtTbUZQUTA2NztNz2PaagY45ZUzSEDlqosYqaAzGD4QyZb8G5m3dUYo71bH5Be3vblVPxHUOPbJainpbekz4pwe2vDNVe+ovOeUV9uXPa31kEg+1bZT17MsHXy4d8UjCSJjASUq7BLJCwtfA+KApT3wwGkO1Dm3TQAX60rXlXiKVasrh8c93B8ESd73Ckcd1+jbp5i/WJIbeZgBnOMxLdjv22O+mPvtFMj9sOu7kAcEXTPtun7GlmyOxMgobu7ajgWfxTVBJhD1j/6lLI8JNwKrXGWOI8Bv2srdIrnTk/LC0B8N0ELfDZhd1UL/681O/kjEaD86hLBnJq5Psh6/DF8v0XaunqZyvWh6a9tRwQ/7Z13QiMhwchysS1uaPWCWATofjNsjjWVP5qa5tr3J3wigCitE9ISWe+CYMY4ytIrkaV8ZwXG1o8x+N1H00h911L1m6Q8EDkGwd9Qv/0azUfnSYOMsWcWiK158dRXNwi324orOrr9Wkg3nRgpAq2MEm0j46AcvRa4aFGoNOv5JA0QoRtppnjuQW1Q5BCXhwegB7gXRTrS1pJvgVyJFj18BDqAlXiIWEC73nfxOZvaZE5asAENbMXNnjfoH1ey59JzdPC6gQFpQs2IBg3kx2WvM75BgbMEMidf+Q8klS1kP6ru35x58YWG4jSbmMT/wYv6XCx/rY5isr2hrgor3xxXaGZJMzwKsfO+JJpkSSBU2LluzSuKT0K+orHEYB+9 +8zo+U9Z sJ5yZEEC0XqGPE9mx59GXjIrnS2gopdi9uNs33Bi1va+KwPa3WGVY4b0DCgA6ezr52Ln0uXrz3zzBS2GTGNjbvDjP22yO3GAjDmvMTDZ73uO2wJvnt7TT5HKqbVxCzoVO2usmsPodWwDRWy3O6bYSZvv3tkr0DHf4+8m8tS9XVl30e3A= 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: Users can attached their BPF programs at arbitrary execution points in the kernel and such BPF programs may run in nmi context. In addition, these programs can trigger memcg charged kernel allocations in the nmi context. However memcg charging infra for kernel memory is not equipped to handle nmi context for all architectures. This series removes the hurdles to enable kmem charging in the nmi context for most of the archs. For archs without CONFIG_HAVE_NMI, this series is a noop. For archs with NMI support and have CONFIG_ARCH_HAS_NMI_SAFE_THIS_CPU_OPS, the previous work to make memcg stats re-entrant is sufficient for allowing kmem charging in nmi context. For archs with NMI support but without CONFIG_ARCH_HAS_NMI_SAFE_THIS_CPU_OPS and with ARCH_HAVE_NMI_SAFE_CMPXCHG, this series added infra to support kmem charging in nmi context. Lastly those archs with NMI support but without CONFIG_ARCH_HAS_NMI_SAFE_THIS_CPU_OPS and ARCH_HAVE_NMI_SAFE_CMPXCHG, kmem charging in nmi context is not supported at all. Mostly used archs have support for CONFIG_ARCH_HAS_NMI_SAFE_THIS_CPU_OPS and this series should be almost a noop (other than making memcg_rstat_updated nmi safe) for such archs. Changes since v3: - Use internal config symbols for nmi unsafe configs as suggested by Johannes. Changes since v2: - Rearrange in_nmi() check as suggested by Vlastimil - Fix commit messag of patch 5 as suggested by Vlastimil Changes since v1: - The main change was to explicitly differentiate between archs which have sane NMI support from others and make the series almost a noop for such archs. (Suggested by Vlastimil) - This version very explicitly describes where kmem charging in nmi context is supported and where it is not. Shakeel Butt (5): memcg: disable kmem charging in nmi for unsupported arch memcg: nmi safe memcg stats for specific archs memcg: add nmi-safe update for MEMCG_KMEM memcg: nmi-safe slab stats updates memcg: make memcg_rstat_updated nmi safe include/linux/memcontrol.h | 21 ++++++ mm/memcontrol.c | 136 +++++++++++++++++++++++++++++++++---- 2 files changed, 145 insertions(+), 12 deletions(-) -- 2.47.1