From nobody Sat Apr 4 00:05:40 2026 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 E16F235A3A0 for ; Sun, 22 Mar 2026 03:09:33 +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=1774148974; cv=none; b=GThjmDoezwNen1KrcyzEsqeOJltBOHf3GuSLlHnmQ+PQJLcY2yh3631CBzkjBdOiYgnnX1hdVlvalYFaDowjnn114goP/5O0TXkYGkmQbRATh5Ddl7Jy+jC1tjxD4AqBE7AVXDYlQL41xN+AppCWUSHADbhH0FMe8ErIXUDWCdk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774148974; c=relaxed/simple; bh=Y0vJ04qnrIj0JjEPZkiv+HOg9hCIM3QRi+mv9JwVktA=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=Ldqac3KHQaEkYWc97yUIYBf/U2N8CqucBmp7VqY9+5li5xizA30EpR2KUz9obnfTKcThxZfQA6gUsO7SCIjVdpdhCdY306f0Ym3M90TWR12oDixZAhLeS9a9+0FXF3bSM1Y31DrbL6myv1fenagE91ObCciLskto4JSzAN53lNI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SN/sFpCs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SN/sFpCs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C423C2BC87; Sun, 22 Mar 2026 03:09:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774148973; bh=Y0vJ04qnrIj0JjEPZkiv+HOg9hCIM3QRi+mv9JwVktA=; h=Date:From:To:Cc:Subject:References:From; b=SN/sFpCs4AAJMyvdxtM+J2e4LaVIr9u4CutnVKk+6sDGw2W6qZJUorkkgtEGWuAfI zmKhbwaETvisuubqukiGXk2affC+hP2F2pCl5WR3yVzo8F1/5D51ane0ByYuXKqP6i godxws6HF9/s/nKbJMp8nLdG+1j6VWdY79Aq81tyM7qoO8ouSHPoeF8SYUPNlYl1sB 6cY0vkrBLjH9mML7POHZaa34Xa+Wxk6X7wozkPTFAD4M+Vx+Qi4mBMCkPQwWt5pqYj AaVgCNXKgCJG23kyL+CcURpLGguusEr1vB8yvyQxs3F9eXsLxB6CE+owBAFNc83CJV LiuJe34SCcobg== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1w49Cc-0000000B7jI-0iSU; Sat, 21 Mar 2026 23:10:10 -0400 Message-ID: <20260322031010.014220602@kernel.org> User-Agent: quilt/0.69 Date: Sat, 21 Mar 2026 23:09:55 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , , , Guohua Yan , Xuewen Yan Subject: [for-linus][PATCH 1/5] tracing: Revert "tracing: Remove pid in task_rename tracing output" References: <20260322030954.198361547@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xuewen Yan This reverts commit e3f6a42272e028c46695acc83fc7d7c42f2750ad. The commit says that the tracepoint only deals with the current task, however the following case is not current task: comm_write() { p =3D get_proc_task(inode); if (!p) return -ESRCH; if (same_thread_group(current, p)) set_task_comm(p, buffer); } where set_task_comm() calls __set_task_comm() which records the update of p and not current. So revert the patch to show pid. Cc: Cc: Cc: Cc: Link: https://patch.msgid.link/20260306075954.4533-1-xuewen.yan@unisoc.com Fixes: e3f6a42272e0 ("tracing: Remove pid in task_rename tracing output") Reported-by: Guohua Yan Signed-off-by: Xuewen Yan Reviewed-by: Steven Rostedt (Google) Signed-off-by: Steven Rostedt (Google) --- include/trace/events/task.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/trace/events/task.h b/include/trace/events/task.h index 4f0759634306..b9a129eb54d9 100644 --- a/include/trace/events/task.h +++ b/include/trace/events/task.h @@ -38,19 +38,22 @@ TRACE_EVENT(task_rename, TP_ARGS(task, comm), =20 TP_STRUCT__entry( + __field( pid_t, pid) __array( char, oldcomm, TASK_COMM_LEN) __array( char, newcomm, TASK_COMM_LEN) __field( short, oom_score_adj) ), =20 TP_fast_assign( + __entry->pid =3D task->pid; memcpy(entry->oldcomm, task->comm, TASK_COMM_LEN); strscpy(entry->newcomm, comm, TASK_COMM_LEN); __entry->oom_score_adj =3D task->signal->oom_score_adj; ), =20 - TP_printk("oldcomm=3D%s newcomm=3D%s oom_score_adj=3D%hd", - __entry->oldcomm, __entry->newcomm, __entry->oom_score_adj) + TP_printk("pid=3D%d oldcomm=3D%s newcomm=3D%s oom_score_adj=3D%hd", + __entry->pid, __entry->oldcomm, + __entry->newcomm, __entry->oom_score_adj) ); =20 /** --=20 2.51.0 From nobody Sat Apr 4 00:05:40 2026 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 1698A37106D; Sun, 22 Mar 2026 03:09:34 +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=1774148974; cv=none; b=r5TZZJu5UQ9k1AhFYqfwiQVb37BGDXei3aQ5KxFGwBbFhs91r8DwRANpV+hKm/AVJGI8lKXLPyl3C6Yri0FZXfvvjFNqwSch37N/Z3oDMVw0J/T3/UVp/m+PBNMBBRV9vLqS9dl73KYA6x5cMixSfMgJ1JlkKcKlB81qkfCnv6Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774148974; c=relaxed/simple; bh=8Uh/2C2chpwUjdNna2gkJd6YPMWhIiCHZHB2dwFsr64=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=DawPGAPqyKdy3kF4sWR6+zV1JtgjnGYLIh/+VeeHeslvWdha8A+4OMWAYOYLxYA09Q9jrBk5NXX+Zh6uDtb9MZTm1+FmMkAfOrjuLDUl9ncIPMSDLW0IVxNr+Xlm5Ufntdcd/ppeOJyj3HH8hcRCq0QgEGmfTT5RyjpBl8VdRiI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t1JFfRde; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="t1JFfRde" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7B2BC2BCB4; Sun, 22 Mar 2026 03:09:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774148973; bh=8Uh/2C2chpwUjdNna2gkJd6YPMWhIiCHZHB2dwFsr64=; h=Date:From:To:Cc:Subject:References:From; b=t1JFfRde5MmXavnxWQsfvd0KCUteupz0nTfbJOYGVCHgqZdNk8MxdYU/q8M7vVLsG ibtH6KCeLFlCenMAvCy7tDqjEEIL6xrX334mXemNIf7yhr7/kchdIYkU2D61cWcjz7 yDt8t8mDS9FzfOBA0Cz9LIfg8CA7/Mdf/egAZsIuIhaVjWgJoC7VNt70gXdJio4Aj8 o5TAT7GRrmmtzo8O4Kaw4KTpsSxPOWXHS7PgKF06RJHWmIAt/wDGEWeFz8sAlylPGs dOUjZJE1Sk0mAdVLfWxAF9m0LTRSPK1KV/81IayE+SjUXK1ezrH4x0+jbKowu+u20o c9Jly58edVJPg== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1w49Cc-0000000B7jn-1T1A; Sat, 21 Mar 2026 23:10:10 -0400 Message-ID: <20260322031010.191529722@kernel.org> User-Agent: quilt/0.69 Date: Sat, 21 Mar 2026 23:09:56 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org Subject: [for-linus][PATCH 2/5] tracing: Fix failure to read user space from system call trace events References: <20260322030954.198361547@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Steven Rostedt The system call trace events call trace_user_fault_read() to read the user space part of some system calls. This is done by grabbing a per-cpu buffer, disabling migration, enabling preemption, calling copy_from_user(), disabling preemption, enabling migration and checking if the task was preempted while preemption was enabled. If it was, the buffer is considered corrupted and it tries again. There's a safety mechanism that will fail out of this loop if it fails 100 times (with a warning). That warning message was triggered in some pi_futex stress tests. Enabling the sched_switch trace event and traceoff_on_warning, showed the problem: pi_mutex_hammer-1375 [006] d..21 138.981648: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981651: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981656: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981659: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981664: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981667: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981671: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981675: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981679: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981682: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981687: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981690: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981695: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981698: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981703: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981706: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981711: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981714: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981719: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981722: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981727: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981730: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 pi_mutex_hammer-1375 [006] d..21 138.981735: sched_switch: prev_comm= =3Dpi_mutex_hammer prev_pid=3D1375 prev_prio=3D95 prev_state=3DR+ =3D=3D> n= ext_comm=3Dmigration/6 next_pid=3D47 next_prio=3D0 migration/6-47 [006] d..2. 138.981738: sched_switch: prev_comm= =3Dmigration/6 prev_pid=3D47 prev_prio=3D0 prev_state=3DS =3D=3D> next_comm= =3Dpi_mutex_hammer next_pid=3D1375 next_prio=3D95 What happened was the task 1375 was flagged to be migrated. When preemption was enabled, the migration thread woke up to migrate that task, but failed because migration for that task was disabled. This caused the loop to fail to exit because the task scheduled out while trying to read user space. Every time the task enabled preemption the migration thread would schedule in, try to migrate the task, fail and let the task continue. But because the loop would only enable preemption with migration disabled, it would always fail because each time it enabled preemption to read user space, the migration thread would try to migrate it. To solve this, when the loop fails to read user space without being scheduled out, enabled and disable preemption with migration enabled. This will allow the migration task to successfully migrate the task and the next loop should succeed to read user space without being scheduled out. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260316130734.1858a998@gandalf.local.home Fixes: 64cf7d058a005 ("tracing: Have trace_marker use per-cpu data to read = user space") Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index ebd996f8710e..bb4a62f4b953 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6783,6 +6783,23 @@ char *trace_user_fault_read(struct trace_user_buf_in= fo *tinfo, */ =20 do { + /* + * It is possible that something is trying to migrate this + * task. What happens then, is when preemption is enabled, + * the migration thread will preempt this task, try to + * migrate it, fail, then let it run again. That will + * cause this to loop again and never succeed. + * On failures, enabled and disable preemption with + * migration enabled, to allow the migration thread to + * migrate this task. + */ + if (trys) { + preempt_enable_notrace(); + preempt_disable_notrace(); + cpu =3D smp_processor_id(); + buffer =3D per_cpu_ptr(tinfo->tbuf, cpu)->buf; + } + /* * If for some reason, copy_from_user() always causes a context * switch, this would then cause an infinite loop. --=20 2.51.0 From nobody Sat Apr 4 00:05:40 2026 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 1EAD737C92D; Sun, 22 Mar 2026 03:09:34 +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=1774148974; cv=none; b=hHUaowAFXKr/rE/FMz9/bFMUFWfPzlYcUQbrOipmCYHRx0W6UbxpAjPXOdVcKIr0JCQ2r57fjNZ2+1h/3Z1bHRz6QhJzmDo45Wjlayt/TwABpdmRHcdhqckV9T4mE6qH8BEAl2nPzTVacyj1MGSglSdx9d5E/zhhVb5mDSD/l9s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774148974; c=relaxed/simple; bh=qtH6bG4u2QFvuoi0sHppW45t1BcXTOUZnSN9m4ZE0F8=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=Q7My+2b4A3vNv/d7Wlk94A8w2bOLXjLLCDHeam/QB8ZPP6pPLnAS05OpUTBjyNdFn1kIku3pz8iKcc8oUq9E152Z1zTiRCPARK4G1NbmrKtF2NeoHq+KJNRJmdmKlFJBSWPakNEJfzXOLIBPdBK1u+4x/66Y6D4+dHbXYPa5foY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=St4VISp/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="St4VISp/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFBEEC2BCB7; Sun, 22 Mar 2026 03:09:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774148974; bh=qtH6bG4u2QFvuoi0sHppW45t1BcXTOUZnSN9m4ZE0F8=; h=Date:From:To:Cc:Subject:References:From; b=St4VISp/eESYD9sFLI8+jZcJ+y51aMmXU8RaUbgrIBErHzVXw2bMy04DDTSf8C5qh CiN6Xt8KdWyi3gFjBw5vs6Zmc3oFAcfiZITcDNbSvhwRvrhmFOsFDFQ27yrmKWCOeF lTxveF0SexiCdf5FLt7wXqtF7snosM9BGbOvHyyHznG8FezG78siG3GFBjcACxlZ4X hewim5eoKKFuAzqmkDd5+NZuGlMmWArnWG0J0wnoAT4CSiKOaKtwTJmw/kGyCvHPvo HpXoVov9K/WQDC/ZQTOI6VREFHxUkLoU82eNZDqZq35/dytlqrayR8Su+y5GZS52ly ohWuN9+grUDdg== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1w49Cc-0000000B7kH-2AUe; Sat, 21 Mar 2026 23:10:10 -0400 Message-ID: <20260322031010.367354466@kernel.org> User-Agent: quilt/0.69 Date: Sat, 21 Mar 2026 23:09:57 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Sasha Levin Subject: [for-linus][PATCH 3/5] tracing: Fix trace_marker copy link list updates References: <20260322030954.198361547@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Steven Rostedt When the "copy_trace_marker" option is enabled for an instance, anything written into /sys/kernel/tracing/trace_marker is also copied into that instances buffer. When the option is set, that instance's trace_array descriptor is added to the marker_copies link list. This list is protected by RCU, as all iterations uses an RCU protected list traversal. When the instance is deleted, all the flags that were enabled are cleared. This also clears the copy_trace_marker flag and removes the trace_array descriptor from the list. The issue is after the flags are called, a direct call to update_marker_trace() is performed to clear the flag. This function returns true if the state of the flag changed and false otherwise. If it returns true here, synchronize_rcu() is called to make sure all readers see that its removed from the list. But since the flag was already cleared, the state does not change and the synchronization is never called, leaving a possible UAF bug. Move the clearing of all flags below the updating of the copy_trace_marker option which then makes sure the synchronization is performed. Also use the flag for checking the state in update_marker_trace() instead of looking at if the list is empty. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260318185512.1b6c7db4@gandalf.local.home Fixes: 7b382efd5e8a ("tracing: Allow the top level trace_marker to write in= to another instances") Reported-by: Sasha Levin Closes: https://lore.kernel.org/all/20260225133122.237275-1-sashal@kernel.o= rg/ Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index bb4a62f4b953..a626211ceb9a 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -555,7 +555,7 @@ static bool update_marker_trace(struct trace_array *tr,= int enabled) lockdep_assert_held(&event_mutex); =20 if (enabled) { - if (!list_empty(&tr->marker_list)) + if (tr->trace_flags & TRACE_ITER(COPY_MARKER)) return false; =20 list_add_rcu(&tr->marker_list, &marker_copies); @@ -563,10 +563,10 @@ static bool update_marker_trace(struct trace_array *t= r, int enabled) return true; } =20 - if (list_empty(&tr->marker_list)) + if (!(tr->trace_flags & TRACE_ITER(COPY_MARKER))) return false; =20 - list_del_init(&tr->marker_list); + list_del_rcu(&tr->marker_list); tr->trace_flags &=3D ~TRACE_ITER(COPY_MARKER); return true; } @@ -9761,18 +9761,19 @@ static int __remove_instance(struct trace_array *tr) =20 list_del(&tr->list); =20 - /* Disable all the flags that were enabled coming in */ - for (i =3D 0; i < TRACE_FLAGS_MAX_SIZE; i++) { - if ((1ULL << i) & ZEROED_TRACE_FLAGS) - set_tracer_flag(tr, 1ULL << i, 0); - } - if (printk_trace =3D=3D tr) update_printk_trace(&global_trace); =20 + /* Must be done before disabling all the flags */ if (update_marker_trace(tr, 0)) synchronize_rcu(); =20 + /* Disable all the flags that were enabled coming in */ + for (i =3D 0; i < TRACE_FLAGS_MAX_SIZE; i++) { + if ((1ULL << i) & ZEROED_TRACE_FLAGS) + set_tracer_flag(tr, 1ULL << i, 0); + } + tracing_set_nop(tr); clear_ftrace_function_probes(tr); event_trace_del_tracer(tr); --=20 2.51.0 From nobody Sat Apr 4 00:05:40 2026 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 4EBAB37DEA3; Sun, 22 Mar 2026 03:09:34 +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=1774148974; cv=none; b=C7eYSEMSvr+xM2G8IIQWOOz1ctp91PBnO8dkYRD9aos0rTtsALd5XDzrDFMY9uNGmtiKCzl3025tK2RCILhHikIi7RQpUVnOu3ovQFRDo8lmKNhM16PAeZDnKnAMhGM8qkvYjVipY9LLhm4ekAu3Jke/X8UmfSvzAyTt/y6vL1Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774148974; c=relaxed/simple; bh=iejwqkXaOG/T7GdgDguaa9GJnn2r+//3Ug9XdJlwwOM=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=i534M2IJTlBxJNoA7m3J8AstwE6l1mK6YAqkuO6Sxj7c23P85brJ7NciTxIcjpKHIXhLUjGwMt38nnlIS8RaS4ypjgq0t8j6m39jC1vftp7egUyamBBkbHK0hXBUKTQfnKjVT+xKkgy1G4ARN9jLMRoRoPsx2eh/yV1ZOhxI0ns= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Oce8VZSf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Oce8VZSf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2165FC2BCB2; Sun, 22 Mar 2026 03:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774148974; bh=iejwqkXaOG/T7GdgDguaa9GJnn2r+//3Ug9XdJlwwOM=; h=Date:From:To:Cc:Subject:References:From; b=Oce8VZSfV+8BGJbgWQWdnWfxFUMI4xc97Rump7CVb3+tbHF7S9x6LwJsJ1xIJbRf+ YAPJxddmfJI3hjH/dCvdMH247UTkbX+Vi0wFzCcqfhpqlwGEby44PnSdlunRE+9p3C p3x0EgHb8VbWvPZMVOzGEHTbxjqQErrwR5lMkvo93jSRAAl0azXrjAS32vDK6R0/UW /mo86fm879q2YJVDNTJOqknwhF8S+F+eXTEl5EvOrfsy1gLQf439lpFsnJAvKXt4cw tra1bd4hnmCUfIB8cv7AjVFMk1XpHUOeGZb2BF3jSGMyKeKpECGyMB38CGsFI1Tq48 5Ce+WTJqjydAg== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1w49Cc-0000000B7km-2rYj; Sat, 21 Mar 2026 23:10:10 -0400 Message-ID: <20260322031010.535986464@kernel.org> User-Agent: quilt/0.69 Date: Sat, 21 Mar 2026 23:09:58 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Ian Rogers Subject: [for-linus][PATCH 4/5] ring-buffer: Fix to update per-subbuf entries of persistent ring buffer References: <20260322030954.198361547@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Masami Hiramatsu (Google)" Since the validation loop in rb_meta_validate_events() updates the same cpu_buffer->head_page->entries, the other subbuf entries are not updated. Fix to use head_page to update the entries field, since it is the cursor in this loop. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Ian Rogers Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Link: https://patch.msgid.link/177391153882.193994.17158784065013676533.stg= it@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) --- kernel/trace/ring_buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 17d0ea0cc3e6..170170bd83bd 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -2053,7 +2053,7 @@ static void rb_meta_validate_events(struct ring_buffe= r_per_cpu *cpu_buffer) =20 entries +=3D ret; entry_bytes +=3D local_read(&head_page->page->commit); - local_set(&cpu_buffer->head_page->entries, ret); + local_set(&head_page->entries, ret); =20 if (head_page =3D=3D cpu_buffer->commit_page) break; --=20 2.51.0 From nobody Sat Apr 4 00:05:40 2026 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 5032B37DEA9 for ; Sun, 22 Mar 2026 03:09:34 +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=1774148974; cv=none; b=DwfoUizzB9GoSImzKYKXbZ/lpYPmLg5socWCC/DXL0WipC0l6qBnDm4JiyHnKCACNS0pdP5i35ifDXZAdas2y6kC1wsnNoWfHJWH0LBXSXlpv4eBj9SyDO2pA6K3scnRG2lnFKOhn9amd3Ramr+xB4veSy162jcD5/ESVqoLAa0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774148974; c=relaxed/simple; bh=u3aqDEGH3wpQ9SDVAiCfC5NIrhSusCratN/XQgDz1yM=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=YGomkePh313ZFTZM1gtVsTeBNGdfvhLHJ/R3tychTkjc4dJJnKMcOVjIWpE4OQG452ivy9dgm6ilAXmAcGlo2vnNWwjTXYsq5AH8dXAHvI7FuG9q+uj3hlqv1GAQ6QUzci+X9f+ZuNIribXheEaGSHwiecOjlXeJdvfDcZAEx3Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IcPInyZT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IcPInyZT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EC42C2BCB3; Sun, 22 Mar 2026 03:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774148974; bh=u3aqDEGH3wpQ9SDVAiCfC5NIrhSusCratN/XQgDz1yM=; h=Date:From:To:Cc:Subject:References:From; b=IcPInyZTn/hEMxykl6MazSYSG6hfjdmUaZ+Tw5uyHPbFGRAO+EdoHXsLlBM3eJCjA WwARthQ8trZFVzGUO3LDW2P8VLzNMPozNA1j/XWvrs+My6bu3irI+MXA8bPikbfS5n tWh+kxo5pcWnH0Gu9kVqnXUGQ/M05qpGvnJx7T0mLx8YSAbsoWHLHo31cy4AInVKX3 jtj8Zp5neRfDJ72OdEQSYYdSVy/n9b6EtNEzJE3cEGJyVkfF83Kv1LfctJtFmtbPp8 eUaUKzXOdA3gh11oozORkrv7ATPsJ/jg0YofTblqP12Tt03J/KXOYQ+iP3jRd8217k jD9IW48cqUgPQ== Received: from rostedt by gandalf with local (Exim 4.99.1) (envelope-from ) id 1w49Cc-0000000B7lG-3YLS; Sat, 21 Mar 2026 23:10:10 -0400 Message-ID: <20260322031010.701213833@kernel.org> User-Agent: quilt/0.69 Date: Sat, 21 Mar 2026 23:09:59 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Menglong Dong , Song Liu , Jiri Olsa Subject: [for-linus][PATCH 5/5] ftrace: Use hash argument for tmp_ops in update_ftrace_direct_mod References: <20260322030954.198361547@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiri Olsa The modify logic registers temporary ftrace_ops object (tmp_ops) to trigger the slow path for all direct callers to be able to safely modify attached addresses. At the moment we use ops->func_hash for tmp_ops filter, which represents all the systems attachments. It's faster to use just the passed hash filter, wh= ich contains only the modified sites and is always a subset of the ops->func_ha= sh. Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Menglong Dong Cc: Song Liu Link: https://patch.msgid.link/20260312123738.129926-1-jolsa@kernel.org Fixes: e93672f770d7 ("ftrace: Add update_ftrace_direct_mod function") Signed-off-by: Jiri Olsa Signed-off-by: Steven Rostedt (Google) --- kernel/trace/ftrace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 8df69e702706..413310912609 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6606,9 +6606,9 @@ int update_ftrace_direct_mod(struct ftrace_ops *ops, = struct ftrace_hash *hash, b if (!orig_hash) goto unlock; =20 - /* Enable the tmp_ops to have the same functions as the direct ops */ + /* Enable the tmp_ops to have the same functions as the hash object. */ ftrace_ops_init(&tmp_ops); - tmp_ops.func_hash =3D ops->func_hash; + tmp_ops.func_hash->filter_hash =3D hash; =20 err =3D register_ftrace_function_nolock(&tmp_ops); if (err) --=20 2.51.0