From patchwork Tue Jan 23 03:08:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 190699 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2553:b0:103:945f:af90 with SMTP id p19csp95596dyi; Mon, 22 Jan 2024 19:14:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IGvEFPC5K56xtnSEXRM9iDmu4HMOqdOXXndSRQpBIGe3EZvt01Wi7zonvy/93Te9mv3AU/q X-Received: by 2002:a05:651c:624:b0:2cd:3e51:8d85 with SMTP id k36-20020a05651c062400b002cd3e518d85mr2130167lje.70.1705979659181; Mon, 22 Jan 2024 19:14:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705979659; cv=pass; d=google.com; s=arc-20160816; b=hs92A0Z0GRGr16Pgn+dXzgJ/9renVqBDBLcVWrREeou4jjUthFHif08XUOT+yrVbtG IuNuAp3s/4RXIwbhIShFd8FBLuQ03148etCP5HOhSy9GKdHHmb7nR9EC2GaEiQnVDkRe D+2MtWxlXRAR1qTmhUSzi3yVJpxWpcmsDdt04e2WvXI76++5R97bS2fRRIxrE0VYKkrv pJrfkCMBkdbzCmgCVgU708RjBRDhGnKut9HTau34SBEESCVy+cVeqZPij/HixMTrjS2P k9mQ3fsbMvmunZGWJA9oDgC2Qx4Duks0Wu2CBAcrwJzXQVA04WK3ehzsf9vyAFInA7yR PX3Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:subject:cc:to:from:date:user-agent:message-id; bh=635Twg5/LYMAEWYYqum6IDk0aSUJSZvSQR0RMo5STMY=; fh=+JWNhj/z0v2f8zQ4/nmLfw6wuMAkMfBgh7AVjJgFxwU=; b=pWc3ms44cz9ROgEnb6zdFiwTI9xF9+QU4nm0fOV34cyUUyG++H+QKZhHZ9tHw8ol0K 5hZEsrNtQ5NwLv3ApX6l+OCatAQg3e/QrdkmjGqrfo0aIm+4c0Rr/WgUPyomI5X1KzIU 0lbA7Vx52IWnaannzt9ZdNjMWd35ecU0vyoLX8LxXSpyzM6+SzW4IpkDDPFQ4qPihaEt 3oZOGolUkFVvHCKpUDt1zQLe7c0pujRoVQXxze6W00nJugXBX5U9NRQ/gvcAet5e4t4D PLiq7JtmOPpdUmjrhAG6b1eeB5KB30lUedmkvOd6V03MtoUciK9YBezbR6X7anI0ehzr xrHw== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-34671-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34671-ouuuleilei=gmail.com@vger.kernel.org" Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id cb4-20020a0564020b6400b0055a49598eafsi4430213edb.381.2024.01.22.19.14.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 19:14:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-34671-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-34671-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34671-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 882761F27546 for ; Tue, 23 Jan 2024 03:14:18 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 081B92F4A; Tue, 23 Jan 2024 03:13:25 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1FBC0A2D for ; Tue, 23 Jan 2024 03:13:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705979603; cv=none; b=rWQMwqBbmsx6Yszs9TMAm30oO/2lajhCvopQ4RLb/pVK0d7AsTMBDCZsZlEohlQoTyhC5Q+SOj0rMgJpUqtEK5+z6T/BQ/xZlNQaR753tbeT6hpHZg3iQ1cCaICN34Ke5BOBDJIIbMyWWmd6/5zMCsNZgb+0XPpWPQ1yw++k8H4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705979603; c=relaxed/simple; bh=tlLAY6EO02qx1b+oRH7VARDvczbq9v+as7OlbaqoAos=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=skFrvnaa6TdVZ1+Fay6YiVZnXodAxkBu27m0aIK/TboNHsMm9F8jLy5zRZ/x5dWDecwpJcuF9Boi2QHkSbqkEoIB/blgKeRo+4YNHWZL5dzm7C+Au2lXHL85+7pKV64+w5x29RehyDKyqXVs3+ACjT4XtRK4QUUp9jWlNXpOn/I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3437C433C7; Tue, 23 Jan 2024 03:13:22 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.97) (envelope-from ) id 1rS7FU-00000002i8w-3Oab; Mon, 22 Jan 2024 22:14:52 -0500 Message-ID: <20240123031452.667736338@goodmis.org> User-Agent: quilt/0.67 Date: Mon, 22 Jan 2024 22:08:27 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Petr Pavlu , Tom Zanussi Subject: [for-linus][PATCH 1/2] tracing: Ensure visibility when inserting an element into tracing_map References: <20240123030826.619242906@goodmis.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788849326794197405 X-GMAIL-MSGID: 1788849326794197405 From: Petr Pavlu Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt; The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subsequently insert a new element, resulting in a duplicate. Fix the problem by adding a write barrier between "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;", and for good measure, also use WRITE_ONCE(entry->val, elt) for publishing the element. The sequence pairs with the mentioned "READ_ONCE(entry->val);" and the "val->key" check which has an address dependency. The barrier is placed on a path executed when adding an element for a new key. Subsequent updates targeting the same key remain unaffected. From the user's perspective, the issue was introduced by commit c193707dde77 ("tracing: Remove code which merges duplicates"), which followed commit cbf4100efb8f ("tracing: Add support to detect and avoid duplicates"). The previous code operated differently; it inherently expected potential races which result in duplicates but merged them later when they occurred. Link: https://lore.kernel.org/linux-trace-kernel/20240122150928.27725-1-petr.pavlu@suse.com Fixes: c193707dde77 ("tracing: Remove code which merges duplicates") Signed-off-by: Petr Pavlu Acked-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) --- kernel/trace/tracing_map.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c index c774e560f2f9..a4dcf0f24352 100644 --- a/kernel/trace/tracing_map.c +++ b/kernel/trace/tracing_map.c @@ -574,7 +574,12 @@ __tracing_map_insert(struct tracing_map *map, void *key, bool lookup_only) } memcpy(elt->key, key, map->key_size); - entry->val = elt; + /* + * Ensure the initialization is visible and + * publish the elt. + */ + smp_wmb(); + WRITE_ONCE(entry->val, elt); atomic64_inc(&map->hits); return entry->val; From patchwork Tue Jan 23 03:08:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 190698 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2553:b0:103:945f:af90 with SMTP id p19csp95585dyi; Mon, 22 Jan 2024 19:14:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IEo7znNEha6tulNY90t9XukC17esbZfIaAgbY2PSxvACllmJPijPl1AXsFj47J2MCdWg9cO X-Received: by 2002:a05:620a:88b:b0:783:8269:1f62 with SMTP id b11-20020a05620a088b00b0078382691f62mr5824725qka.155.1705979657500; Mon, 22 Jan 2024 19:14:17 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705979657; cv=pass; d=google.com; s=arc-20160816; b=Ng5Rkc3THB7cr8t15nAFwPzziyJsAlx0gpwctdX2z9JvmZqyTmIUJHBxDM39UjYcnS c/ZAlaJndkipywOqddOLLPdwa8cYbm/N4K1smhzBKGpwPS82VXiGDLwBnujO/IAYpqoC NgLpGatHYB4GCoWzJV+fXvpuABahlctzft6cZRaW2V7V0wuogxuqWbxRVYaF+uaRi8Hu zABWAoDOhD+CJ+qEXw0oV400Si099cLd1uIzYeVEYIYdq+U3sQR4659e9IfHRLqOfTM1 p6ojLbXNS108KKZQgcVFMVJbOItHnkRQBDvB6gyfhveh/YNhF3UhcR4otNjckSnczZ4N gmMA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:subject:cc:to:from:date:user-agent:message-id; bh=Umdkro5x5kuRTrwSRoNTZIjStDCr9LRVL99QFK3uAYE=; fh=3ExuGtZUYaqUYQ6NOg7W3CZ6fshj5PAp4L7OK0kjqpg=; b=HojMbYzMd8i1cSGNu19tAIPeR8UHgdtvVVQ/hOUXcoD82qT0tTmcfkUuHBSSrrgQHj ikyEGNX6yRo8giFT+qaUO+UByIhLuPewgKhYFmY2U93NssSfRCWMzfz0DTTxChgKJVE2 m+xD3WK2gyLgEj9cJdDZEks+XLZQa6udaParolEkyjFEXMj12W+lvXm0+mrfSyAtWTW2 581ekdlgNtcNmgJM8c4wnMxrAAPJwN0ITC8KenQmGKtpVJ2UnXGHqvXVK2sc9bN4Yxgy kTx1dZnsUxoz5pzCmYfZCj3OGQr7bFc/bExznqjhmvEfqeVMAX+m/OBXHTgOcVrME9Is jwiQ== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-34672-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34672-ouuuleilei=gmail.com@vger.kernel.org" Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id d20-20020a05620a241400b0078337d99660si7750098qkn.147.2024.01.22.19.14.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 19:14:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-34672-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-34672-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-34672-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4C6CF1C287F9 for ; Tue, 23 Jan 2024 03:14:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 118DF3229; Tue, 23 Jan 2024 03:13:25 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 60DC11102 for ; Tue, 23 Jan 2024 03:13:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705979603; cv=none; b=E55Vk+c63bvc4NS3qODQiyiARbfOrhRUmMa0jt0NpsJ+NR44sx0oonxcE4rtnY0t12Y7x57KK3x5bv3Wh33IpUH3u8uOZ+5DECYmKZXEN1c0+YhjGM/jh2wmXWRwWz8bEiOlwA6otsngegYo564Wq3v2SgbDQC4VGLjcTRHBFug= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705979603; c=relaxed/simple; bh=g1vOPJnY9t3y2bVhIPnU2h6iLtYDdE5uoCvaW6dG+O4=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=lvsVILXeXkQR7AKknv6/VcPlG/eYSrFWTU5WLfbA1IR9G2dt4w2YbayW5R9g3N0d3PICil5T6bZWFWrLyDMwHVDDRwVxHt4RYCbj+ML1B8D+ESi7Tw7cqQaC6qOQZEHBBiNZjQ/nNivqd0I8BunsvKSBvOW+J5vF2dmZx/r4Ijw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0CF5C43394; Tue, 23 Jan 2024 03:13:22 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.97) (envelope-from ) id 1rS7FU-00000002i9Q-45QQ; Mon, 22 Jan 2024 22:14:52 -0500 Message-ID: <20240123031452.830697973@goodmis.org> User-Agent: quilt/0.67 Date: Mon, 22 Jan 2024 22:08:28 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Linus Torvalds , Geert Uytterhoeven , Kees Cook Subject: [for-linus][PATCH 2/2] eventfs: Save directory inodes in the eventfs_inode structure References: <20240123030826.619242906@goodmis.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788849325183097486 X-GMAIL-MSGID: 1788849325183097486 From: "Steven Rostedt (Google)" The eventfs inodes and directories are allocated when referenced. But this leaves the issue of keeping consistent inode numbers and the number is only saved in the inode structure itself. When the inode is no longer referenced, it can be freed. When the file that the inode was representing is referenced again, the inode is once again created, but the inode number needs to be the same as it was before. Just making the inode numbers the same for all files is fine, but that does not work with directories. The find command will check for loops via the inode number and having the same inode number for directories triggers: # find /sys/kernel/tracing find: File system loop detected; '/sys/kernel/debug/tracing/events/initcall/initcall_finish' is part of the same file system loop as '/sys/kernel/debug/tracing/events/initcall'. [..] Linus pointed out that the eventfs_inode structure ends with a single 32bit int, and on 64 bit machines, there's likely a 4 byte hole due to alignment. We can use this hole to store the inode number for the eventfs_inode. All directories in eventfs are represented by an eventfs_inode and that data structure can hold its inode number. That last int was also purposely placed at the end of the structure to prevent holes from within. Now that there's a 4 byte number to hold the inode, both the inode number and the last integer can be moved up in the structure for better cache locality, where the llist and rcu fields can be moved to the end as they are only used when the eventfs_inode is being deleted. Link: https://lore.kernel.org/all/CAMuHMdXKiorg-jiuKoZpfZyDJ3Ynrfb8=X+c7x0Eewxn-YRdCA@mail.gmail.com/ Link: https://lore.kernel.org/linux-trace-kernel/20240122152748.46897388@gandalf.local.home Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Linus Torvalds Reported-by: Geert Uytterhoeven Fixes: 53c41052ba31 ("eventfs: Have the inodes all for files and directories all be the same") Signed-off-by: Steven Rostedt (Google) Reviewed-by: Kees Cook --- fs/tracefs/event_inode.c | 14 +++++++++++--- fs/tracefs/internal.h | 7 ++++--- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c index 6795fda2af19..6b211522a13e 100644 --- a/fs/tracefs/event_inode.c +++ b/fs/tracefs/event_inode.c @@ -34,7 +34,15 @@ static DEFINE_MUTEX(eventfs_mutex); /* Choose something "unique" ;-) */ #define EVENTFS_FILE_INODE_INO 0x12c4e37 -#define EVENTFS_DIR_INODE_INO 0x134b2f5 + +/* Just try to make something consistent and unique */ +static int eventfs_dir_ino(struct eventfs_inode *ei) +{ + if (!ei->ino) + ei->ino = get_next_ino(); + + return ei->ino; +} /* * The eventfs_inode (ei) itself is protected by SRCU. It is released from @@ -396,7 +404,7 @@ static struct dentry *create_dir(struct eventfs_inode *ei, struct dentry *parent inode->i_fop = &eventfs_file_operations; /* All directories will have the same inode number */ - inode->i_ino = EVENTFS_DIR_INODE_INO; + inode->i_ino = eventfs_dir_ino(ei); ti = get_tracefs(inode); ti->flags |= TRACEFS_EVENT_INODE; @@ -802,7 +810,7 @@ static int eventfs_iterate(struct file *file, struct dir_context *ctx) name = ei_child->name; - ino = EVENTFS_DIR_INODE_INO; + ino = eventfs_dir_ino(ei_child); if (!dir_emit(ctx, name, strlen(name), ino, DT_DIR)) goto out_dec; diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h index 12b7d0150ae9..45397df9bb65 100644 --- a/fs/tracefs/internal.h +++ b/fs/tracefs/internal.h @@ -55,6 +55,10 @@ struct eventfs_inode { struct eventfs_attr *entry_attrs; struct eventfs_attr attr; void *data; + unsigned int is_freed:1; + unsigned int is_events:1; + unsigned int nr_entries:30; + unsigned int ino; /* * Union - used for deletion * @llist: for calling dput() if needed after RCU @@ -64,9 +68,6 @@ struct eventfs_inode { struct llist_node llist; struct rcu_head rcu; }; - unsigned int is_freed:1; - unsigned int is_events:1; - unsigned int nr_entries:30; }; static inline struct tracefs_inode *get_tracefs(const struct inode *inode)