From nobody Fri Dec 19 16:43:49 2025 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 E76C81624E0; Sat, 15 Feb 2025 03:52:48 +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=1739591569; cv=none; b=leTxK1Gn+UlnmxdgakXUAAELi9L7c+OiXwcijA+DvFGLRLq4HrQLKPI8WT0zcfZbpqIIDd3eXr/mg0xt55MvxYrG1huRVifjHgeB7mDO8q7dHgvnyfJAwJiNRVUiQiijwaytxIhNbLOcd35iG8XxpN2hGf4rhvZoKBPuSjkcrH0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739591569; c=relaxed/simple; bh=gW2hZsCFQxTjSaHx/556S3IDT5o80OmaVZfwNcoiZbw=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=unsxxOPcXH8Jtgwfz1CEQd2OhLc+hesRU4L3bcyLIlJgSX2Xp8lbnaHELBkEzGqRK67x52Qkj5afoM7iVB4+yU7VW5C2rGL4LJAVW68sBvctmJaoP9/+5m4KtqJ3/BmxCE6txsCaU7XKb/gnwp6aLMB+BHc0f3iJxTYjFFYYojU= 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 606FEC4CEE5; Sat, 15 Feb 2025 03:52:48 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98) (envelope-from ) id 1tj9Ek-00000002hE2-1QFs; Fri, 14 Feb 2025 22:53:02 -0500 Message-ID: <20250215035302.198095677@goodmis.org> User-Agent: quilt/0.68 Date: Fri, 14 Feb 2025 22:52:32 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Vincent Donnefort Subject: [for-linus][PATCH 1/5] ring-buffer: Unlock resize on mmap error References: <20250215035231.786853904@goodmis.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 Memory mapping the tracing ring buffer will disable resizing the buffer. But if there's an error in the memory mapping like an invalid parameter, the function exits out without re-enabling the resizing of the ring buffer, preventing the ring buffer from being resized after that. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Vincent Donnefort Link: https://lore.kernel.org/20250213131957.530ec3c5@gandalf.local.home Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functio= ns") Signed-off-by: Steven Rostedt (Google) --- kernel/trace/ring_buffer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index b8e0ae15ca5b..07b421115692 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -7126,6 +7126,7 @@ int ring_buffer_map(struct trace_buffer *buffer, int = cpu, kfree(cpu_buffer->subbuf_ids); cpu_buffer->subbuf_ids =3D NULL; rb_free_meta_page(cpu_buffer); + atomic_dec(&cpu_buffer->resize_disabled); } =20 unlock: --=20 2.47.2 From nobody Fri Dec 19 16:43:49 2025 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 E77141624F0; Sat, 15 Feb 2025 03:52:48 +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=1739591569; cv=none; b=JJyP2ix1qwBZbu75XWHyoJa9ouAEgU4GpYAyiSZd5Ey5Su7rDJiDqhXCcacbdkP5jiRCByrp38JIt0Fd6MBMqAZ6HJQK0jIWWWtWQWP6DeSmJht1PRto4j6cj5GvfVyImcdr8emGOILzxKlxwPvK38e4RAf+yTGkadV6FNDsOwM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739591569; c=relaxed/simple; bh=LYVwNsgFca20o8iJ9fMn0a36Xx0jM6SIdNj3AIwERK4=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=ReRIAUIqIE/vnT7neSz1h0jHvsl4EPeA6Dx5A03BwfPSNqG1REKxbTuyBGMFVbQ2eNhwHN0v8YRSsYkSRfmgsNhEjwBONBG/vf8C8m1jmi5B0uuYrbf9+E3yfDZbea4+Ge4M7E24w0HKPEVJJwr15mG3vS3hItot7iy0DIOqA0Q= 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 8464CC4CEE9; Sat, 15 Feb 2025 03:52:48 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98) (envelope-from ) id 1tj9Ek-00000002hEX-28oQ; Fri, 14 Feb 2025 22:53:02 -0500 Message-ID: <20250215035302.360105504@goodmis.org> User-Agent: quilt/0.68 Date: Fri, 14 Feb 2025 22:52:33 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Vincent Donnefort Subject: [for-linus][PATCH 2/5] tracing: Have the error of __tracing_resize_ring_buffer() passed to user References: <20250215035231.786853904@goodmis.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 Currently if __tracing_resize_ring_buffer() returns an error, the tracing_resize_ringbuffer() returns -ENOMEM. But it may not be a memory issue that caused the function to fail. If the ring buffer is memory mapped, then the resizing of the ring buffer will be disabled. But if the user tries to resize the buffer, it will get an -ENOMEM returned, which is confusing because there is plenty of memory. The actual error returned was -EBUSY, which would make much more sense to the user. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Vincent Donnefort Link: https://lore.kernel.org/20250213134132.7e4505d7@gandalf.local.home Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functio= ns") Signed-off-by: Steven Rostedt (Google) Reviewed-by: Masami Hiramatsu (Google) --- kernel/trace/trace.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 1496a5ac33ae..25ff37aab00f 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -5977,8 +5977,6 @@ static int __tracing_resize_ring_buffer(struct trace_= array *tr, ssize_t tracing_resize_ring_buffer(struct trace_array *tr, unsigned long size, int cpu_id) { - int ret; - guard(mutex)(&trace_types_lock); =20 if (cpu_id !=3D RING_BUFFER_ALL_CPUS) { @@ -5987,11 +5985,7 @@ ssize_t tracing_resize_ring_buffer(struct trace_arra= y *tr, return -EINVAL; } =20 - ret =3D __tracing_resize_ring_buffer(tr, size, cpu_id); - if (ret < 0) - ret =3D -ENOMEM; - - return ret; + return __tracing_resize_ring_buffer(tr, size, cpu_id); } =20 static void update_last_data(struct trace_array *tr) --=20 2.47.2 From nobody Fri Dec 19 16:43:49 2025 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 376E418950A; Sat, 15 Feb 2025 03:52:48 +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=1739591569; cv=none; b=qAeYMznWCwbKtxbgAH+1wkQVfEB+g7YuaoDTpU8CnR7YAmK8CmKxS/Y3MixlhZ++rR7a/v+1M5O8y2U3w7hgzLS2lAihATBc8xE3znhxJb5YzJlhdvRp2ms1g2BBXe7V6rZJ1UtBYoUy/a3b+a/JGHkHaOyouNKzIDCC3p2Hgrw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739591569; c=relaxed/simple; bh=EBOuzCn9cDnla0fhU5eNtn8IHcG5Hasda2XM8CLZYj8=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=iLma6XZ0WIMDL4lMXnsh06tCYxZV7t/xGYAXqw/o+vb70TADyZ0aBvXO3EaDUK9PsXwmuLl3M8RCOWtRdYEIOZ3JcNrNohVwHCwePsb/JQMTC1Yxzd0eeaDfoFdS+yYiSmeOMfXISjJm332K8cocY7NLHcQlnmboIjcBAwYH8uY= 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 B160AC4CEE7; Sat, 15 Feb 2025 03:52:48 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98) (envelope-from ) id 1tj9Ek-00000002hF1-2rDX; Fri, 14 Feb 2025 22:53:02 -0500 Message-ID: <20250215035302.532467545@goodmis.org> User-Agent: quilt/0.68 Date: Fri, 14 Feb 2025 22:52:34 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Vincent Donnefort Subject: [for-linus][PATCH 3/5] ring-buffer: Validate the persistent meta data subbuf array References: <20250215035231.786853904@goodmis.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 meta data for a mapped ring buffer contains an array of indexes of all the subbuffers. The first entry is the reader page, and the rest of the entries lay out the order of the subbuffers in how the ring buffer link list is to be created. The validator currently makes sure that all the entries are within the range of 0 and nr_subbufs. But it does not check if there are any duplicates. While working on the ring buffer, I corrupted this array, where I added duplicates. The validator did not catch it and created the ring buffer link list on top of it. Luckily, the corruption was only that the reader page was also in the writer path and only presented corrupted data but did not crash the kernel. But if there were duplicates in the writer side, then it could corrupt the ring buffer link list and cause a crash. Create a bitmask array with the size of the number of subbuffers. Then clear it. When walking through the subbuf array checking to see if the entries are within the range, test if its bit is already set in the subbuf_mask. If it is, then there is duplicates and fail the validation. If not, set the corresponding bit and continue. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Vincent Donnefort Link: https://lore.kernel.org/20250214102820.7509ddea@gandalf.local.home Fixes: c76883f18e59b ("ring-buffer: Add test if range of boot buffer is val= id") Signed-off-by: Steven Rostedt (Google) --- kernel/trace/ring_buffer.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 07b421115692..0419d41a2060 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -1672,7 +1672,8 @@ static void *rb_range_buffer(struct ring_buffer_per_c= pu *cpu_buffer, int idx) * must be the same. */ static bool rb_meta_valid(struct ring_buffer_meta *meta, int cpu, - struct trace_buffer *buffer, int nr_pages) + struct trace_buffer *buffer, int nr_pages, + unsigned long *subbuf_mask) { int subbuf_size =3D PAGE_SIZE; struct buffer_data_page *subbuf; @@ -1680,6 +1681,9 @@ static bool rb_meta_valid(struct ring_buffer_meta *me= ta, int cpu, unsigned long buffers_end; int i; =20 + if (!subbuf_mask) + return false; + /* Check the meta magic and meta struct size */ if (meta->magic !=3D RING_BUFFER_META_MAGIC || meta->struct_size !=3D sizeof(*meta)) { @@ -1712,6 +1716,8 @@ static bool rb_meta_valid(struct ring_buffer_meta *me= ta, int cpu, =20 subbuf =3D rb_subbufs_from_meta(meta); =20 + bitmap_clear(subbuf_mask, 0, meta->nr_subbufs); + /* Is the meta buffers and the subbufs themselves have correct data? */ for (i =3D 0; i < meta->nr_subbufs; i++) { if (meta->buffers[i] < 0 || @@ -1725,6 +1731,12 @@ static bool rb_meta_valid(struct ring_buffer_meta *m= eta, int cpu, return false; } =20 + if (test_bit(meta->buffers[i], subbuf_mask)) { + pr_info("Ring buffer boot meta [%d] array has duplicates\n", cpu); + return false; + } + + set_bit(meta->buffers[i], subbuf_mask); subbuf =3D (void *)subbuf + subbuf_size; } =20 @@ -1889,17 +1901,22 @@ static void rb_meta_init_text_addr(struct ring_buff= er_meta *meta) static void rb_range_meta_init(struct trace_buffer *buffer, int nr_pages) { struct ring_buffer_meta *meta; + unsigned long *subbuf_mask; unsigned long delta; void *subbuf; int cpu; int i; =20 + /* Create a mask to test the subbuf array */ + subbuf_mask =3D bitmap_alloc(nr_pages + 1, GFP_KERNEL); + /* If subbuf_mask fails to allocate, then rb_meta_valid() will return fal= se */ + for (cpu =3D 0; cpu < nr_cpu_ids; cpu++) { void *next_meta; =20 meta =3D rb_range_meta(buffer, nr_pages, cpu); =20 - if (rb_meta_valid(meta, cpu, buffer, nr_pages)) { + if (rb_meta_valid(meta, cpu, buffer, nr_pages, subbuf_mask)) { /* Make the mappings match the current address */ subbuf =3D rb_subbufs_from_meta(meta); delta =3D (unsigned long)subbuf - meta->first_buffer; @@ -1943,6 +1960,7 @@ static void rb_range_meta_init(struct trace_buffer *b= uffer, int nr_pages) subbuf +=3D meta->subbuf_size; } } + bitmap_free(subbuf_mask); } =20 static void *rbm_start(struct seq_file *m, loff_t *pos) --=20 2.47.2 From nobody Fri Dec 19 16:43:49 2025 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 4C2A0189BBB; Sat, 15 Feb 2025 03:52:48 +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=1739591569; cv=none; b=ucMWMRDroGDsMnr+NGCrFUmOKiGoeEr+FaAwWvJvxaK8Vn6h7F5lmsMLPXBRQlKvXTP8d+4W1CBkMgpaUkJPsTWF1S0sKgHbJxhTlE3nkkQBVYfl4NqfKlPkselooqZgxFhboemFOtkua0o32UlKsY+sF1bTCduv5Qp73ZXJC/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739591569; c=relaxed/simple; bh=t09DrRZAWA2OQ3CdNfQbI0y+HmU/ot9RpAYjsATCDMs=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=jTEPy08r+VIBYNuxiRqU6QCA4Wj2OWjCUH7V8Ndb6yFq7rB85n4vDAF19ZCrva8dhgbWthEby2y9EPgy8MIMGYWZk4Txc/sYTImEf1xbBsAivEgGtcKtfhi9h9X0UnfRDANIm9DvlNdnrMwtYx6MDcJMoJCyG+sCPxyWPBiXj8g= 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 DC3B0C4CEEB; Sat, 15 Feb 2025 03:52:48 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98) (envelope-from ) id 1tj9Ek-00000002hFX-3Zsv; Fri, 14 Feb 2025 22:53:02 -0500 Message-ID: <20250215035302.702637791@goodmis.org> User-Agent: quilt/0.68 Date: Fri, 14 Feb 2025 22:52:35 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Vincent Donnefort Subject: [for-linus][PATCH 4/5] tracing: Do not allow mmap() of persistent ring buffer References: <20250215035231.786853904@goodmis.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 trying to mmap a trace instance buffer that is attached to reserve_mem, it would crash: BUG: unable to handle page fault for address: ffffe97bd00025c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 2862f3067 P4D 2862f3067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f= 1a5e3fbf9e-dirty #233 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.1= 6.3-2 04/01/2014 RIP: 0010:validate_page_before_insert+0x5/0xb0 Code: e2 01 89 d0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90= 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 <48> 8b 46 08 a8 = 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89 RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246 RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29 RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08 RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000 R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000 FS: 00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:00000000000000= 00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0 Call Trace: ? __die_body.cold+0x19/0x1f ? __die+0x2e/0x40 ? page_fault_oops+0x157/0x2b0 ? search_module_extables+0x53/0x80 ? validate_page_before_insert+0x5/0xb0 ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70 ? __bad_area_nosemaphore+0x16e/0x1b0 ? bad_area_nosemaphore+0x16/0x20 ? do_kern_addr_fault+0x77/0x90 ? exc_page_fault+0x22b/0x230 ? asm_exc_page_fault+0x2b/0x30 ? validate_page_before_insert+0x5/0xb0 ? vm_insert_pages+0x151/0x400 __rb_map_vma+0x21f/0x3f0 ring_buffer_map+0x21b/0x2f0 tracing_buffers_mmap+0x70/0xd0 __mmap_region+0x6f0/0xbd0 mmap_region+0x7f/0x130 do_mmap+0x475/0x610 vm_mmap_pgoff+0xf2/0x1d0 ksys_mmap_pgoff+0x166/0x200 __x64_sys_mmap+0x37/0x50 x64_sys_call+0x1670/0x1d70 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The reason was that the code that maps the ring buffer pages to user space has: page =3D virt_to_page((void *)cpu_buffer->subbuf_ids[s]); And uses that in: vm_insert_pages(vma, vma->vm_start, pages, &nr_pages); But virt_to_page() does not work with vmap()'d memory which is what the persistent ring buffer has. It is rather trivial to allow this, but for now just disable mmap() of instances that have their ring buffer from the reserve_mem option. If an mmap() is performed on a persistent buffer it will return -ENODEV just like it would if the .mmap field wasn't defined in the file_operations structure. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Vincent Donnefort Link: https://lore.kernel.org/20250214115547.0d7287d3@gandalf.local.home Fixes: e645535a954ad ("tracing: Add option to use memmapped memory for trac= e boot instance") Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 25ff37aab00f..0e6d517e74e0 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -8279,6 +8279,10 @@ static int tracing_buffers_mmap(struct file *filp, s= truct vm_area_struct *vma) struct trace_iterator *iter =3D &info->iter; int ret =3D 0; =20 + /* Currently the boot mapped buffer is not supported for mmap */ + if (iter->tr->flags & TRACE_ARRAY_FL_BOOT) + return -ENODEV; + ret =3D get_snapshot_map(iter->tr); if (ret) return ret; --=20 2.47.2 From nobody Fri Dec 19 16:43:49 2025 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 282B017799F; Sat, 15 Feb 2025 03:52:49 +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=1739591569; cv=none; b=dJhie5GHlcCGiPGO0KEHXR+KO1YrX8xim2L/jdG15zg2sONHmOZAZfVJH+aZVLhwwgxs5r+KPScvVm5cyCvPafVJG2F8WUyV18qdHbQ/8VLXArFPQ9zvQv6KRJ4C4SJ+EEiwjLZCKpWK+Vq/fN7PZJW8D1zdZBb5AIAwoeeXpkM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739591569; c=relaxed/simple; bh=s4WmS2kRHPuaEIzsd7gYZwiPeVAc/SGM3MwLSlgJonA=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=Eb/BXnoOou6YhFFhz1Blr67BovL1TFaFh2xM164OWOqLrigbBjEWdglsiNRNwIzfv0UzlwKavMfXWiP7QaekoEjhf+mer7KIfYNQgyrSCOKea/8JOdfA2FSQBCFFHX+WLcOtUjuPuObQ5ylJN8Q9QXJb++Vdvxnri5IU/h2ySKI= 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 138A0C4CEE6; Sat, 15 Feb 2025 03:52:49 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98) (envelope-from ) id 1tj9El-00000002hG1-06uK; Fri, 14 Feb 2025 22:53:03 -0500 Message-ID: <20250215035302.872962698@goodmis.org> User-Agent: quilt/0.68 Date: Fri, 14 Feb 2025 22:52:36 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Vincent Donnefort Subject: [for-linus][PATCH 5/5] ring-buffer: Update pages_touched to reflect persistent buffer content References: <20250215035231.786853904@goodmis.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 pages_touched field represents the number of subbuffers in the ring buffer that have content that can be read. This is used in accounting of "dirty_pages" and "buffer_percent" to allow the user to wait for the buffer to be filled to a certain amount before it reads the buffer in blocking mode. The persistent buffer never updated this value so it was set to zero, and this accounting would take it as it had no content. This would cause user space to wait for content even though there's enough content in the ring buffer that satisfies the buffer_percent. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Vincent Donnefort Link: https://lore.kernel.org/20250214123512.0631436e@gandalf.local.home Fixes: 5f3b6e839f3ce ("ring-buffer: Validate boot range memory events") Signed-off-by: Steven Rostedt (Google) --- kernel/trace/ring_buffer.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 0419d41a2060..bb6089c2951e 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -1850,6 +1850,11 @@ static void rb_meta_validate_events(struct ring_buff= er_per_cpu *cpu_buffer) cpu_buffer->cpu); goto invalid; } + + /* If the buffer has content, update pages_touched */ + if (ret) + local_inc(&cpu_buffer->pages_touched); + entries +=3D ret; entry_bytes +=3D local_read(&head_page->page->commit); local_set(&cpu_buffer->head_page->entries, ret); --=20 2.47.2