mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vincent Donnefort <vdonnefort@google.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	suleiman@google.com, Thomas Gleixner <tglx@linutronix.de>,
	Vineeth Pillai <vineeth@bitbyteword.org>,
	Youssef Esmat <youssefesmat@google.com>,
	Beau Belgrave <beaub@linux.microsoft.com>,
	Alexander Graf <graf@amazon.com>, Baoquan He <bhe@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	David Howells <dhowells@redhat.com>,
	Mike Rapoport <rppt@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Ross Zwisler <zwisler@google.com>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v4 01/13] ring-buffer: Allow mapped field to be set without mapping
Date: Tue, 11 Jun 2024 15:43:59 -0700	[thread overview]
Message-ID: <5178e22b-0c00-48d2-8a6e-85510706f145@roeck-us.net> (raw)
In-Reply-To: <20240611192907.402447387@goodmis.org>

On 6/11/24 12:28, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> 
> In preparation for having the ring buffer mapped to a dedicated location,
> which will have the same restrictions as user space memory mapped buffers,
> allow it to use the "mapped" field of the ring_buffer_per_cpu structure
> without having the user space meta page mapping.
> 
> When this starts using the mapped field, it will need to handle adding a
> user space mapping (and removing it) from a ring buffer that is using a
> dedicated memory range.
> 
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> ---
>   kernel/trace/ring_buffer.c | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 28853966aa9a..78beaccf9c8c 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -5224,6 +5224,9 @@ static void rb_update_meta_page(struct ring_buffer_per_cpu *cpu_buffer)
>   {
>   	struct trace_buffer_meta *meta = cpu_buffer->meta_page;
>   
> +	if (!meta)
> +		return;
> +
>   	meta->reader.read = cpu_buffer->reader_page->read;
>   	meta->reader.id = cpu_buffer->reader_page->id;
>   	meta->reader.lost_events = cpu_buffer->lost_events;
> @@ -6167,7 +6170,7 @@ rb_get_mapped_buffer(struct trace_buffer *buffer, int cpu)
>   
>   	mutex_lock(&cpu_buffer->mapping_lock);
>   
> -	if (!cpu_buffer->mapped) {
> +	if (!cpu_buffer->mapped || !cpu_buffer->meta_page) {
>   		mutex_unlock(&cpu_buffer->mapping_lock);
>   		return ERR_PTR(-ENODEV);
>   	}
> @@ -6359,12 +6362,13 @@ int ring_buffer_map(struct trace_buffer *buffer, int cpu,
>   	 */
>   	raw_spin_lock_irqsave(&cpu_buffer->reader_lock, flags);
>   	rb_setup_ids_meta_page(cpu_buffer, subbuf_ids);
> +

Picky again. Is that a leftover from something ? I don't see an immediate reason
for the added newline.

>   	raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
>   
>   	err = __rb_map_vma(cpu_buffer, vma);
>   	if (!err) {
>   		raw_spin_lock_irqsave(&cpu_buffer->reader_lock, flags);
> -		cpu_buffer->mapped = 1;
> +		cpu_buffer->mapped++;
>   		raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
>   	} else {
>   		kfree(cpu_buffer->subbuf_ids);
> @@ -6403,7 +6407,8 @@ int ring_buffer_unmap(struct trace_buffer *buffer, int cpu)
>   	mutex_lock(&buffer->mutex);
>   	raw_spin_lock_irqsave(&cpu_buffer->reader_lock, flags);
>   
> -	cpu_buffer->mapped = 0;
> +	WARN_ON_ONCE(!cpu_buffer->mapped);
> +	cpu_buffer->mapped--;

This will wrap to UINT_MAX if it was 0. Is that intentional ?

>   
>   	raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
>   


  reply	other threads:[~2024-06-11 22:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 19:28 [PATCH v4 00/13] tracing: Persistent traces across a reboot or crash Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 01/13] ring-buffer: Allow mapped field to be set without mapping Steven Rostedt
2024-06-11 22:43   ` Guenter Roeck [this message]
2024-06-11 22:53     ` Steven Rostedt
2024-06-11 23:53       ` Guenter Roeck
2024-06-12  1:39         ` Steven Rostedt
2024-06-12  1:57           ` Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 02/13] ring-buffer: Add ring_buffer_alloc_range() Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 03/13] ring-buffer: Add ring_buffer_meta data Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 04/13] tracing: Implement creating an instance based on a given memory region Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 05/13] ring-buffer: Add output of ring buffer meta page Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 06/13] ring-buffer: Add test if range of boot buffer is valid Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 07/13] ring-buffer: Validate boot range memory events Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 08/13] tracing: Add option to use memmapped memory for trace boot instance Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 09/13] ring-buffer: Save text and data locations in mapped meta data Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 10/13] tracing/ring-buffer: Add last_boot_info file to boot instance Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 11/13] tracing: Handle old buffer mappings for event strings and functions Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 12/13] tracing: Update function tracing output for previous boot buffer Steven Rostedt
2024-06-11 19:28 ` [PATCH v4 13/13] tracing: Add last boot delta offset for stack traces Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5178e22b-0c00-48d2-8a6e-85510706f145@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=akpm@linux-foundation.org \
    --cc=beaub@linux.microsoft.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=bristot@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dhowells@redhat.com \
    --cc=graf@amazon.com \
    --cc=joel@joelfernandes.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=suleiman@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vdonnefort@google.com \
    --cc=vineeth@bitbyteword.org \
    --cc=youssefesmat@google.com \
    --cc=zwisler@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®