linux-kernel - Re: [PATCH v19 RESEND 3/5] tracing: Allow user-space mapping of the ring-buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zg1qMI7JYhdeY_z7@google.com>
Date: Wed, 3 Apr 2024 15:39:44 +0100
From: Vincent Donnefort <vdonnefort@...gle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: mhiramat@...nel.org, linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org, mathieu.desnoyers@...icios.com,
	kernel-team@...roid.com, linux-mm@...ck.org
Subject: Re: [PATCH v19 RESEND 3/5] tracing: Allow user-space mapping of the
 ring-buffer

On Wed, Apr 03, 2024 at 10:13:52AM -0400, Steven Rostedt wrote:
> On Fri, 29 Mar 2024 14:40:55 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > > +static vm_fault_t tracing_buffers_mmap_fault(struct vm_fault *vmf)
> > > +{
> > > +	return VM_FAULT_SIGBUS;
> > > +}  
> > 
> > If this is all it does, I don't believe it's needed.
> > 
> > > +
> > > +#ifdef CONFIG_TRACER_MAX_TRACE
> > > +static int get_snapshot_map(struct trace_array *tr)
> > > +{
> > > +	int err = 0;
> > > +
> > > +	/*
> > > +	 * Called with mmap_lock held. lockdep would be unhappy if we would now
> > > +	 * take trace_types_lock. Instead use the specific
> > > +	 * snapshot_trigger_lock.
> > > +	 */
> > > +	spin_lock(&tr->snapshot_trigger_lock);
> > > +
> > > +	if (tr->snapshot || tr->mapped == UINT_MAX)
> > > +		err = -EBUSY;
> > > +	else
> > > +		tr->mapped++;
> > > +
> > > +	spin_unlock(&tr->snapshot_trigger_lock);
> > > +
> > > +	/* Wait for update_max_tr() to observe iter->tr->mapped */
> > > +	if (tr->mapped == 1)
> > > +		synchronize_rcu();
> > > +
> > > +	return err;
> > > +
> > > +}
> > > +static void put_snapshot_map(struct trace_array *tr)
> > > +{
> > > +	spin_lock(&tr->snapshot_trigger_lock);
> > > +	if (!WARN_ON(!tr->mapped))
> > > +		tr->mapped--;
> > > +	spin_unlock(&tr->snapshot_trigger_lock);
> > > +}
> > > +#else
> > > +static inline int get_snapshot_map(struct trace_array *tr) { return 0; }
> > > +static inline void put_snapshot_map(struct trace_array *tr) { }
> > > +#endif
> > > +
> > > +static void tracing_buffers_mmap_close(struct vm_area_struct *vma)
> > > +{
> > > +	struct ftrace_buffer_info *info = vma->vm_file->private_data;
> > > +	struct trace_iterator *iter = &info->iter;
> > > +
> > > +	WARN_ON(ring_buffer_unmap(iter->array_buffer->buffer, iter->cpu_file));
> > > +	put_snapshot_map(iter->tr);
> > > +}
> > > +
> > > +static void tracing_buffers_mmap_open(struct vm_area_struct *vma) { }  
> > 
> > Same for the open.
> > 
> > 
> > > +
> > > +static const struct vm_operations_struct tracing_buffers_vmops = {
> > > +	.open		= tracing_buffers_mmap_open,
> > > +	.close		= tracing_buffers_mmap_close,
> > > +	.fault		= tracing_buffers_mmap_fault,
> > > +};  
> > 
> > I replaced this with:
> > 
> > static const struct vm_operations_struct tracing_buffers_vmops = {
> > 	.close		= tracing_buffers_mmap_close,
> > };
> > 
> > And it appears to work just fine. The mm code handles the NULL cases for
> > .open and .fault.
> > 
> > Is there any reason to do something different than the mm defaults?

No other reason here than my own ignorance. I will remove.

> 
> Hi Vincent,
> 
> Do you plan on sending out a v20 series?

Of course, let me spin that this week! Got also few typos to fix in the doc and
I believe an include missing for riscv.

> 
> -- Steve