From patchwork Sat Jan 18 14:36:57 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 13944203 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 2D1D6C02187 for ; Sat, 18 Jan 2025 14:36:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5223C6B0082; Sat, 18 Jan 2025 09:36:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D2296B0083; Sat, 18 Jan 2025 09:36:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C07C6B0085; Sat, 18 Jan 2025 09:36:56 -0500 (EST) 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 1EEA76B0082 for ; Sat, 18 Jan 2025 09:36:56 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 844B0B1BFA for ; Sat, 18 Jan 2025 14:36:55 +0000 (UTC) X-FDA: 83020824390.07.07433CC Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id EC48A40008 for ; Sat, 18 Jan 2025 14:36:52 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of "SRS0=Nb98=UK=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 as permitted sender) smtp.mailfrom="SRS0=Nb98=UK=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737211013; 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: references; bh=wmwI97o/UJwq9t/ytFDwqBw3zd1TU/ba/yoRgLN/VrY=; b=ecS8IXd+EuSfABMi3o+xLCarY97k3G2LPp4YDEOpCr5Ho8dz78yX12rl8yXY52fIdsbRN9 9gb77+XNjj4AhrM8P4kw3rXuA9QvNSbOwlisbLrIIPaLqlWhSCAzkrSxNl0aGz2fXNl6Kv NPrLkQHp2OQsHRDWKctf/06t4iJuiBI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737211013; a=rsa-sha256; cv=none; b=cl3EoiDjb7RHh1KI/F2thbWzjMhgrdlihohnRebVcnAVT5EVHrhWEJk5ShN9nVZuVNm5i5 SRUG3lsl56t0EaD4XorQ44Jj3O5gd3yy7g4TfHhESF/ndrQkrBT5egTpWE5Tp5UraZxSy0 lJpiLhOfdFsfTFIhOVYT8XCXcBvH3Gw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of "SRS0=Nb98=UK=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 as permitted sender) smtp.mailfrom="SRS0=Nb98=UK=goodmis.org=rostedt@kernel.org"; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 4F150A413EE; Sat, 18 Jan 2025 14:35:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA43EC4CED1; Sat, 18 Jan 2025 14:36:50 +0000 (UTC) Date: Sat, 18 Jan 2025 09:36:57 -0500 From: Steven Rostedt To: Linus Torvalds Cc: LKML , Masami Hiramatsu , Mathieu Desnoyers , Andrew Morton , Veronika Molnarova , Suren Baghdasaryan , linux-mm@kvack.org Subject: [GIT PULL] tracing: gfp: Fix regression of GFP flags in trace events 6.13 Message-ID: <20250118093657.60fe1c2f@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Stat-Signature: wsmm6rxkboada9hc7m5t6zn3jpo9h9pw X-Rspamd-Queue-Id: EC48A40008 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1737211012-663116 X-HE-Meta: U2FsdGVkX19Rgg9J95vFS4piqGZjElIMkBQtwEvJ300N/ntj6O1qZJY9cgNKMMbuEj8JvrzQrRY6zTM43GUMKTuC5L6DBBIEXEt1C1G8/qKOznBBzFR6CILckFAlGRAuDn3ZAO/Xnid2f9qDmibONjrjpkcjVsRvX9Bl3mg6jWxcUUxxr/I+ZWcv+3S+ASnWDKREERrFwm5ESLlRik7LfwPj5bWCyIAOef+rN0UNUp39WJZclq71VBLrvUPY8eHjJsS3z0IjUM8JT6c2L/ZDQXGbeSkdwxIkjrZqvhTVuStkHVSmrvdlUusGCNHYkLEiuRomaoRgm03EdGFBa8xNGgW1M6Qz0TYbTc+sw/6o0btTmdSXchouTk5AxNJwHWyQJC9H8Z1uqLVcrJNYeq9tRN7CO4pxpJgDEFWJWGoO4xaCJddPhd9NqOJiSFlD/+9ksJmqXg3DLR5+T1qJeOgI0WOJSqPE9A2K4P/AUA8BFB9wcVT81oKadJFeyMfOEGzaDh3YTnm0uYRp+QWPp5EataWd4O7Wa/DuFW+ibgOfUGlF0NmnwpV0E1lkKDqPK/qTne0ZptoZltoeG0k5LkPNPIv8kzhUDvgrf/VMq0om4RQIm+zJ4AWJWGI6BXzZIq6WOwWIYCAGAM3sgiqlLnya0ca6uJiVu8HX8M199gATxVXzqileBK1zBRGUEAai1yghzBaxm6G6aoJQZyWse723S3oqeavuXKhkseleuKk3D9Eo4RNgRPQdaounFrTQAYxHQ+HQ4KF5z3AplTzrx8oFPqHBp7yXGIDL22FWrFGMM9WI4Koy1dQDRRUMvEArePcnnTNlJ3/EYVvxt0w5cLEmXQ5ySW+7lwDMZgG4Op/yFvU3EPOjtc6rrd2N6idBVfZBDW6NhKzN2f7tKz9+Mw9APwZmA1G1inQ293swlkcBpecweX1/aYwzOK4fPCE3HGKl4l2PumwlfufZStt/0Rt JHArSxzN lrASc0TIaKOnPRjKEvsIMUDn3pTKuKkh+jIE2scGiv0WgsIAGthfQ08us4qZWUCMHjcqT6907b9uw5MkErTiV0rIAsUYiLnIv81qf/GOyWnrqTcuuxLxihDfsEP7kp/IHAU5ATVvnC+4DpP+kzHDMl2ovFY/StOsO+s2cSYBJnvJYwrSPfc4juGZR37aXaFTH6zDES5TWrY+MHiJYAflUhwjwWhpPLgV24msNrqjUT6zwzwrZ0rQKC63a8xtdpRQaKPWP+FWkYWM0TC+ClM4gJ0mqLqb3ekcZiU7xU4JXuHQoLa0+kTst+sP3yOh/DTvxiFoR6Cghs740fFOLP22q0/NXf/8ZuyxdFPkzxiXnNwl2xO94voqnKus5LJVJpmJCyz102vR8XyyUtF5yvNzc2DUs2GpClzuVmRFHCuNSIl0wU27QTRV7pwvwEWYwtqjGsBfTom4bGhpry7Yi87yU9R1+6Oj42ur0eiXLXMd5jfqRMJ4jGuw1NbrElSwW6orTN8uWtibG0hNdLAZ6sn2/CG8iMY+IMXO7jKqpPR2i8090Xog= 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: Linus, Fix regression in GFP output in trace events It was reported that the GFP flags in trace events went from human readable to just their hex values: gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP to gfp_flags=0x140cca This was caused by a change that added the use of enums in calculating the GFP flags. As defines get translated into their values in the trace event format files, the user space tooling could easily convert the GFP flags into their symbols via the __print_flags() helper macro. The problem is that enums do not get converted, and the names of the enums show up in the format files and user space tooling cannot translate them. Add TRACE_DEFINE_ENUM() around the enums used for GFP flags which is the tracing infrastructure macro that informs the tracing subsystem what the values for enums and it can then expose that to user space. Please pull the latest trace-v6.13-rc7-2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git trace-v6.13-rc7-2 Tag SHA1: c3b4e29a5e12d9b3cc8df441a52a44cc28f66f5c Head SHA1: 60295b944ff6805e677c48ae4178532b207d43be Steven Rostedt (1): tracing: gfp: Fix the GFP enum values shown for user space tracing tools ---- include/trace/events/mmflags.h | 63 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) --------------------------- commit 60295b944ff6805e677c48ae4178532b207d43be Author: Steven Rostedt Date: Thu Jan 16 16:41:24 2025 -0500 tracing: gfp: Fix the GFP enum values shown for user space tracing tools Tracing tools like perf and trace-cmd read the /sys/kernel/tracing/events/*/*/format files to know how to parse the data and also how to print it. For the "print fmt" portion of that file, if anything uses an enum that is not exported to the tracing system, user space will not be able to parse it. The GFP flags use to be defines, and defines get translated in the print fmt sections. But now they are converted to use enums, which is not. The mm_page_alloc trace event format use to have: print fmt: "page=%p pfn=0x%lx order=%d migratetype=%d gfp_flags=%s", REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0), REC->pfn != -1UL ? REC->pfn : 0, REC->order, REC->migratetype, (REC->gfp_flags) ? __print_flags(REC->gfp_flags, "|", {( unsigned long)(((((((( gfp_t)(0x400u|0x800u)) | (( gfp_t)0x40u) | (( gfp_t)0x80u) | (( gfp_t)0x100000u)) | (( gfp_t)0x02u)) | (( gfp_t)0x08u) | (( gfp_t)0)) | (( gfp_t)0x40000u) | (( gfp_t)0x80000u) | (( gfp_t)0x2000u)) & ~(( gfp_t)(0x400u|0x800u))) | (( gfp_t)0x400u)), "GFP_TRANSHUGE"}, {( unsigned long)((((((( gfp_t)(0x400u|0x800u)) | (( gfp_t)0x40u) | (( gfp_t)0x80u) | (( gfp_t)0x100000u)) | (( gfp_t)0x02u)) | (( gfp_t)0x08u) | (( gfp_t)0)) ... Where the GFP values are shown and not their names. But after the GFP flags were converted to use enums, it has: print fmt: "page=%p pfn=0x%lx order=%d migratetype=%d gfp_flags=%s", REC->pfn != -1UL ? (vmemmap + (REC->pfn)) : ((void *)0), REC->pfn != -1UL ? REC->pfn : 0, REC->order, REC->migratetype, (REC->gfp_flags) ? __print_flags(REC->gfp_flags, "|", {( unsigned long)(((((((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT))) | (( gfp_t)((((1UL))) << (___GFP_HARDWALL_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_HIGHMEM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_MOVABLE_BIT))) | (( gfp_t)0)) | (( gfp_t)((((1UL))) << (___GFP_COMP_BIT))) ... Where the enums names like ___GFP_KSWAPD_RECLAIM_BIT are shown and not their values. User space has no way to convert these names to their values and the output will fail to parse. What is shown is now: mm_page_alloc: page=0xffffffff981685f3 pfn=0x1d1ac1 order=0 migratetype=1 gfp_flags=0x140cca The TRACE_DEFINE_ENUM() macro was created to handle enums in the print fmt files. This causes them to be replaced at boot up with the numbers, so that user space tooling can parse it. By using this macro, the output is back to the human readable: mm_page_alloc: page=0xffffffff981685f3 pfn=0x122233 order=0 migratetype=1 gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Veronika Molnarova Cc: Suren Baghdasaryan Cc: Linus Torvalds Link: https://lore.kernel.org/20250116214438.749504792@goodmis.org Reported-by: Michael Petlan Closes: https://lore.kernel.org/all/87be5f7c-1a0-dad-daa0-54e342efaea7@redhat.com/ Fixes: 772dd0342727c ("mm: enumerate all gfp flags") Signed-off-by: Steven Rostedt (Google) diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h index bb8a59c6caa2..d36c857dd249 100644 --- a/include/trace/events/mmflags.h +++ b/include/trace/events/mmflags.h @@ -13,6 +13,69 @@ * Thus most bits set go first. */ +/* These define the values that are enums (the bits) */ +#define TRACE_GFP_FLAGS_GENERAL \ + TRACE_GFP_EM(DMA) \ + TRACE_GFP_EM(HIGHMEM) \ + TRACE_GFP_EM(DMA32) \ + TRACE_GFP_EM(MOVABLE) \ + TRACE_GFP_EM(RECLAIMABLE) \ + TRACE_GFP_EM(HIGH) \ + TRACE_GFP_EM(IO) \ + TRACE_GFP_EM(FS) \ + TRACE_GFP_EM(ZERO) \ + TRACE_GFP_EM(DIRECT_RECLAIM) \ + TRACE_GFP_EM(KSWAPD_RECLAIM) \ + TRACE_GFP_EM(WRITE) \ + TRACE_GFP_EM(NOWARN) \ + TRACE_GFP_EM(RETRY_MAYFAIL) \ + TRACE_GFP_EM(NOFAIL) \ + TRACE_GFP_EM(NORETRY) \ + TRACE_GFP_EM(MEMALLOC) \ + TRACE_GFP_EM(COMP) \ + TRACE_GFP_EM(NOMEMALLOC) \ + TRACE_GFP_EM(HARDWALL) \ + TRACE_GFP_EM(THISNODE) \ + TRACE_GFP_EM(ACCOUNT) \ + TRACE_GFP_EM(ZEROTAGS) + +#ifdef CONFIG_KASAN_HW_TAGS +# define TRACE_GFP_FLAGS_KASAN \ + TRACE_GFP_EM(SKIP_ZERO) \ + TRACE_GFP_EM(SKIP_KASAN) +#else +# define TRACE_GFP_FLAGS_KASAN +#endif + +#ifdef CONFIG_LOCKDEP +# define TRACE_GFP_FLAGS_LOCKDEP \ + TRACE_GFP_EM(NOLOCKDEP) +#else +# define TRACE_GFP_FLAGS_LOCKDEP +#endif + +#ifdef CONFIG_SLAB_OBJ_EXT +# define TRACE_GFP_FLAGS_SLAB \ + TRACE_GFP_EM(NO_OBJ_EXT) +#else +# define TRACE_GFP_FLAGS_SLAB +#endif + +#define TRACE_GFP_FLAGS \ + TRACE_GFP_FLAGS_GENERAL \ + TRACE_GFP_FLAGS_KASAN \ + TRACE_GFP_FLAGS_LOCKDEP \ + TRACE_GFP_FLAGS_SLAB + +#undef TRACE_GFP_EM +#define TRACE_GFP_EM(a) TRACE_DEFINE_ENUM(___GFP_##a##_BIT); + +TRACE_GFP_FLAGS + +/* Just in case these are ever used */ +TRACE_DEFINE_ENUM(___GFP_UNUSED_BIT); +TRACE_DEFINE_ENUM(___GFP_LAST_BIT); + #define gfpflag_string(flag) {(__force unsigned long)flag, #flag} #define __def_gfpflag_names \