From nobody Thu Oct 2 22:48:46 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 8E12F33A00C; Tue, 9 Sep 2025 12:42:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757421761; cv=none; b=NFFJGXyyU2n4VH1NkDI70V2qRRPbOh4S7vxqB4/nhBNqS2mT1jLV+VvrqZJflLj/EA+IVGvbHJVY/Gr/KQUO5OaxZ4sU74Ja+mOwyN2FcZLJIbBDjhVNsWkM2/d09UqmUtqc3CiRNqRxkaOt4lI1FxGQI3pmyCLBJ4882R2DmgQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757421761; c=relaxed/simple; bh=nyivRvoUeQGaRx+MBdk7W2K+tf1UkUWsqGHfGsHD3hc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nYXW1kGjQYgD1pNv2bXogaKh7BgTAaplFjKVc4I/r1V0OCFM2rLULO7I84eCd0XcgxhRmWr/Qq08zP2eH2E6UHv9xAJF7igBEbROSPfjM++ABfeF3fBpUC/woHwTik6fZ1auj6ql6A2PhcXKH+EaHm+5tUBgUwepOVjv6jAoDws= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=hecm/bRw; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="hecm/bRw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1757421760; x=1788957760; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nyivRvoUeQGaRx+MBdk7W2K+tf1UkUWsqGHfGsHD3hc=; b=hecm/bRwOi4B/kFWwva5YJdJhIG0RIcDyHbml+ZGldiGbOcVjCda5RUA mI4jlaXa64YxIJNBd5J6NkQuz6H2Wvo/QkJYg1K2r107CM2s2uo9q0Ka1 qQk49aOcGETHPpsqlxeYddohVETUPJB3xdpqsZ0tCnCwKyZIlX/kpDda4 CH46uNST4+qN5QkdVtz6R+FwOpnxa0InSeRyCntt1OYMgqYVK7cFJM5La h11SNnZ9vUlU6EW8ndC3SWKXrH23Z6bpYr9fuO070qXxrFLmq6yoNd5wT E2pI4QPO5/HuUnD/n1/xE9zeYjx9mq/oK6F0ipNSJVSMkVML/H/HdCFgW A==; X-CSE-ConnectionGUID: 6PI059jgT1GEsQhoX1lrJg== X-CSE-MsgGUID: QOYo/xCbS3mEID8VM7hDbA== X-IronPort-AV: E=McAfee;i="6800,10657,11547"; a="70399542" X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; d="scan'208";a="70399542" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 05:42:39 -0700 X-CSE-ConnectionGUID: 21ZjgzN4Tp2M3aEDsx0rWg== X-CSE-MsgGUID: QPtgvQS+RC+uripbR6KwCA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; d="scan'208";a="172667422" Received: from abityuts-desk.ger.corp.intel.com (HELO localhost.localdomain) ([10.245.244.84]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 05:42:35 -0700 From: Adrian Hunter To: Peter Zijlstra Cc: Ingo Molnar , Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , Namhyung Kim , Mark Rutland , Ian Rogers , Kan Liang , Mathieu Poirier , Miklos Szeredi , Alexander Viro , Christian Brauner , Amir Goldstein , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: [PATCH 1/3] perf/core: Fix address filter match with backing files Date: Tue, 9 Sep 2025 15:42:20 +0300 Message-ID: <20250909124222.222945-2-adrian.hunter@intel.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250909124222.222945-1-adrian.hunter@intel.com> References: <20250909124222.222945-1-adrian.hunter@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Finland Oy, Registered Address: c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It was reported that Intel PT address filters do not work in Docker containers. That relates to the use of overlayfs. overlayfs records the backing file in struct vm_area_struct vm_file, instead of the user file that the user mmapped. In order for an address filter to match, it must compare to the user file inode. There is an existing helper file_user_inode() for that situation. Use file_user_inode() instead of file_inode() to get the inode for address filter matching. Example: Setup: # cd /root # mkdir test ; cd test ; mkdir lower upper work merged # cp `which cat` lower # mount -t overlay overlay -olowerdir=3Dlower,upperdir=3Dupper,workdir= =3Dwork merged # perf record --buildid-mmap -e intel_pt//u --filter 'filter * @ /root/= test/merged/cat' -- /root/test/merged/cat /proc/self/maps ... 55d61d246000-55d61d2e1000 r-xp 00018000 00:1a 3418 = /root/test/merged/cat ... [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.015 MB perf.data ] # perf buildid-cache --add /root/test/merged/cat Before: Address filter does not match so there are no control flow packets # perf script --itrace=3De # perf script --itrace=3Db | wc -l 0 # perf script -D | grep 'TIP.PGE' | wc -l 0 # After: Address filter does match so there are control flow packets # perf script --itrace=3De # perf script --itrace=3Db | wc -l 235 # perf script -D | grep 'TIP.PGE' | wc -l 57 # With respect to stable kernels, overlayfs mmap function ovl_mmap() was added in v4.19 but file_user_inode() was not added until v6.8 and never back-ported to stable kernels. FMODE_BACKING that it depends on was added in v6.5. This issue has gone largely unnoticed, so back-porting before v6.8 is probably not worth it, so put 6.8 as the stable kernel prerequisite version, although in practice the next long term kernel is 6.12. Reported-by: Edd Barrett Closes: https://lore.kernel.org/linux-perf-users/aBCwoq7w8ohBRQCh@fremen.lan Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Adrian Hunter Acked-by: Amir Goldstein --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index fb1eae762044..184f3dc7b03b 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9492,7 +9492,7 @@ static bool perf_addr_filter_match(struct perf_addr_f= ilter *filter, if (!filter->path.dentry) return false; =20 - if (d_inode(filter->path.dentry) !=3D file_inode(file)) + if (d_inode(filter->path.dentry) !=3D file_user_inode(file)) return false; =20 if (filter->offset > offset + size) --=20 2.48.1 From nobody Thu Oct 2 22:48:46 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 B3DE3334722; Tue, 9 Sep 2025 12:42:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757421765; cv=none; b=DILGcTf6t6o49bqa6N4KYiUqhD8TqQNmcgW6bbD/Y1oT/3EyoHTVvSfHYCXYkt+0EYF2UZVxyvxhUXNmj0usY0dSj4mXX7SCVXecGl8Nk9gWlohyLHjD1xn1rGQId7O7ljrYw0QMlBl+rXmvFj66JPmV+ousJ9zdHK/jIMHUC1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757421765; c=relaxed/simple; bh=HXMhf8VGncxYHCwDK/v+GA73/bpOnN36hTkT2QbX1Oc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VvD+BaVkCVPa07ImoT4Ez1vpnWP4h9hZnRK2ZqGoKcFcCQYUnPcw14Mv1/W1JghQJRI/p1dxVxhrgQuHuxjpCDxP7Hn7Cn26I3NIDY/Abwz9uL0kq2kFHHyCah7UbM8WWY3QSZPAxYnA1n6s0V/WtfSwsQ+zEcsMnoS5dnZ8RT8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Fmj69ral; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Fmj69ral" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1757421764; x=1788957764; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HXMhf8VGncxYHCwDK/v+GA73/bpOnN36hTkT2QbX1Oc=; b=Fmj69ralNgucutJUTPnCXvNSzXfy8PqSdDirEw66g08yxGnNyq5bzX1w dQlEuHZvV8zP2d8DYXgm9lQBAlZjUXxI3/e97JxeZsskt+BhqLEXs1VNR 86ykPWH3CMVkhqXiRjRyYLF7KBbA7FmdYNa9cKzTUeijk7zQpziMD4RQl xnRqGtAd7v8l9X6WaY/gmGWy/2hj8IPAYtf4pGGkbV5NIEReDbI/ugF/2 wCqXbibheLuseJkI5+68j2AZ7dcBnYevEhL2tHSllyOLjkY0bq2SKj9Ve iEtIEy3HRSxELz/N1kNpnnaBHgchqyrIqsvHE0AlKTKsKlUnxIlJnxObj g==; X-CSE-ConnectionGUID: HZ2e26RfTp+KtM5x/i4yxQ== X-CSE-MsgGUID: q0glqhm0QkuiIK3SEpYe3Q== X-IronPort-AV: E=McAfee;i="6800,10657,11547"; a="70399556" X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; d="scan'208";a="70399556" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 05:42:43 -0700 X-CSE-ConnectionGUID: c+vPT1/MSpm46JdSgeOfJw== X-CSE-MsgGUID: 0n1u8bFiRYW6T/2X/rpE2w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; d="scan'208";a="172667451" Received: from abityuts-desk.ger.corp.intel.com (HELO localhost.localdomain) ([10.245.244.84]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 05:42:39 -0700 From: Adrian Hunter To: Peter Zijlstra Cc: Ingo Molnar , Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , Namhyung Kim , Mark Rutland , Ian Rogers , Kan Liang , Mathieu Poirier , Miklos Szeredi , Alexander Viro , Christian Brauner , Amir Goldstein , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: [PATCH 2/3] perf/core: Fix MMAP event path names with backing files Date: Tue, 9 Sep 2025 15:42:21 +0300 Message-ID: <20250909124222.222945-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250909124222.222945-1-adrian.hunter@intel.com> References: <20250909124222.222945-1-adrian.hunter@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Finland Oy, Registered Address: c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Some file systems like FUSE-based ones or overlayfs may record the backing file in struct vm_area_struct vm_file, instead of the user file that the user mmapped. Since commit def3ae83da02f ("fs: store real path instead of fake path in backing file f_path"), file_path() no longer returns the user file path when applied to a backing file. There is an existing helper file_user_path() for that situation. Use file_user_path() instead of file_path() to get the path for MMAP and MMAP2 events. Example: Setup: # cd /root # mkdir test ; cd test ; mkdir lower upper work merged # cp `which cat` lower # mount -t overlay overlay -olowerdir=3Dlower,upperdir=3Dupper,workdir= =3Dwork merged # perf record -e intel_pt//u -- /root/test/merged/cat /proc/self/maps ... 55b0ba399000-55b0ba434000 r-xp 00018000 00:1a 3419 = /root/test/merged/cat ... [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.060 MB perf.data ] # Before: File name is wrong (/cat), so decoding fails: # perf script --no-itrace --show-mmap-events cat 367 [016] 100.491492: PERF_RECORD_MMAP2 367/367: [0x= 55b0ba399000(0x9b000) @ 0x18000 00:02 3419 489959280]: r-xp /cat ... # perf script --itrace=3De | wc -l Warning: 19 instruction trace errors 19 # After: File name is correct (/root/test/merged/cat), so decoding is ok: # perf script --no-itrace --show-mmap-events cat 364 [016] 72.153006: PERF_RECORD_MMAP2 364/364:= [0x55ce4003d000(0x9b000) @ 0x18000 00:02 3419 3132534314]: r-xp /root/test= /merged/cat # perf script --itrace=3De # perf script --itrace=3De | wc -l 0 # Fixes: def3ae83da02f ("fs: store real path instead of fake path in backing = file f_path") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Acked-by: Amir Goldstein --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 184f3dc7b03b..e203b8d90fd2 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9416,7 +9416,7 @@ static void perf_event_mmap_event(struct perf_mmap_ev= ent *mmap_event) * need to add enough zero bytes after the string to handle * the 64bit alignment we do later. */ - name =3D file_path(file, buf, PATH_MAX - sizeof(u64)); + name =3D d_path(file_user_path(file), buf, PATH_MAX - sizeof(u64)); if (IS_ERR(name)) { name =3D "//toolong"; goto cpy_name; --=20 2.48.1 From nobody Thu Oct 2 22:48:46 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 DA62833EB12; Tue, 9 Sep 2025 12:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757421769; cv=none; b=C+roZeinYzmcrPvWRGhv/pkgTiU4eJ29OTp4oItPh2/KtwRd88ICvJr7orw1TCPe0ojOEZcUHsZBLmk0sI2KLBvwdkDD/m24mqWCYLLe5zUzPnuyrzwImY2tBZfbHx3jdzLEkl0L6wEWp9+3wt3ODQ2NDcy8H3B+71LTxuaQdw0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757421769; c=relaxed/simple; bh=Pt6R1lXQxECu96oquYdgEIA0VrhXv/RzniYpUbGqgSI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BfSvBPLZcjKrFofMzvHnsxnSQMbuoQEATGoYUnFMfnPuxSp8rez1gvXMPIlouhiIXhgR2LzfRjHH58QAe+a8ckkfJZVcq1sjaEnXycC3upwvOY2x3DktKmfoL2hWUVlepkWSK3dmpRQem0XTFwTewf3VF5xl6M11aZ5Uj0qYr78= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=edZhkqCg; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="edZhkqCg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1757421768; x=1788957768; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Pt6R1lXQxECu96oquYdgEIA0VrhXv/RzniYpUbGqgSI=; b=edZhkqCgIGwrMRURj45eT/Vlax5qHr/z3Y5bu1BApbRSoeWt+N2kx3i0 yTlQ+WTc5coGb5kZDFw4CwzilgnVKC5Mllh+Ht0lNkIIXtSnYkVWg4WFk u4YyCfGcl1wwG2EWPg1R9qDVxj2xa1LqZ5O3ISFPutfRHna99FllhkBw2 tl3qzkPM9JksxrFwJnzB8ZSaB2x3C9uDpABj3UC0ljkNkI8+kpOgCM+8B b+QfI4358wLBIR1ERALyMvM7W1ys/133hxGX+Fn82G4y1KQb0DOoGiJdA u3fQ93WkflEOHII4qm207/QvB7PBs9kxdKw/qE3vUvNoRF0JnO7lv1omC w==; X-CSE-ConnectionGUID: rH2CTtoTSt2oQYL43tHPZA== X-CSE-MsgGUID: rEpL8Fb2S++G/TkNCk70ew== X-IronPort-AV: E=McAfee;i="6800,10657,11547"; a="70399573" X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; d="scan'208";a="70399573" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 05:42:48 -0700 X-CSE-ConnectionGUID: uGyzRG44TECZQRgYsqdZqg== X-CSE-MsgGUID: K7rh66MDRg2kow9aXEBTTw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; d="scan'208";a="172667483" Received: from abityuts-desk.ger.corp.intel.com (HELO localhost.localdomain) ([10.245.244.84]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 05:42:43 -0700 From: Adrian Hunter To: Peter Zijlstra Cc: Ingo Molnar , Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , Namhyung Kim , Mark Rutland , Ian Rogers , Kan Liang , Mathieu Poirier , Miklos Szeredi , Alexander Viro , Christian Brauner , Amir Goldstein , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: [PATCH 3/3] perf/core: Fix MMAP2 event device with backing files Date: Tue, 9 Sep 2025 15:42:22 +0300 Message-ID: <20250909124222.222945-4-adrian.hunter@intel.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250909124222.222945-1-adrian.hunter@intel.com> References: <20250909124222.222945-1-adrian.hunter@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Finland Oy, Registered Address: c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Some file systems like FUSE-based ones or overlayfs may record the backing file in struct vm_area_struct vm_file, instead of the user file that the user mmapped. That causes perf to misreport the device major/minor numbers of the file system of the file, and the generation of the file, and potentially other inode details. There is an existing helper file_user_inode() for that situation. Use file_user_inode() instead of file_inode() to get the inode for MMAP2 events. Example: Setup: # cd /root # mkdir test ; cd test ; mkdir lower upper work merged # cp `which cat` lower # mount -t overlay overlay -olowerdir=3Dlower,upperdir=3Dupper,workdir= =3Dwork merged # perf record -e cycles:u -- /root/test/merged/cat /proc/self/maps ... 55b2c91d0000-55b2c926b000 r-xp 00018000 00:1a 3419 = /root/test/merged/cat ... [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.004 MB perf.data (5 samples) ] # # stat /root/test/merged/cat File: /root/test/merged/cat Size: 1127792 Blocks: 2208 IO Block: 4096 regular file Device: 0,26 Inode: 3419 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-09-08 12:23:59.453309624 +0000 Modify: 2025-09-08 12:23:59.454309624 +0000 Change: 2025-09-08 12:23:59.454309624 +0000 Birth: 2025-09-08 12:23:59.453309624 +0000 Before: Device reported 00:02 differs from stat output and /proc/self/maps # perf script --show-mmap-events | grep /root/test/merged/cat cat 377 [-01] 243.078558: PERF_RECORD_MMAP2 377/377: [0x= 55b2c91d0000(0x9b000) @ 0x18000 00:02 3419 2068525940]: r-xp /root/test/mer= ged/cat After: Device reported 00:1a is the same as stat output and /proc/self/maps # perf script --show-mmap-events | grep /root/test/merged/cat cat 362 [-01] 127.755167: PERF_RECORD_MMAP2 362/362: [0x= 55ba6e781000(0x9b000) @ 0x18000 00:1a 3419 0]: r-xp /root/test/merged/cat With respect to stable kernels, overlayfs mmap function ovl_mmap() was added in v4.19 but file_user_inode() was not added until v6.8 and never back-ported to stable kernels. FMODE_BACKING that it depends on was added in v6.5. This issue has gone largely unnoticed, so back-porting before v6.8 is probably not worth it, so put 6.8 as the stable kernel prerequisite version, although in practice the next long term kernel is 6.12. Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Adrian Hunter Acked-by: Amir Goldstein --- kernel/events/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index e203b8d90fd2..9d281785b99e 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9403,7 +9403,7 @@ static void perf_event_mmap_event(struct perf_mmap_ev= ent *mmap_event) flags |=3D MAP_HUGETLB; =20 if (file) { - struct inode *inode; + const struct inode *inode; dev_t dev; =20 buf =3D kmalloc(PATH_MAX, GFP_KERNEL); @@ -9421,7 +9421,7 @@ static void perf_event_mmap_event(struct perf_mmap_ev= ent *mmap_event) name =3D "//toolong"; goto cpy_name; } - inode =3D file_inode(vma->vm_file); + inode =3D file_user_inode(vma->vm_file); dev =3D inode->i_sb->s_dev; ino =3D inode->i_ino; gen =3D inode->i_generation; --=20 2.48.1