From: "Steven Rostedt (VMware)" <[email protected]>
If a process has the trace_pipe open on a trace_array, the current tracer
for that trace array should not be changed. This was original enforced by a
global lock, but when instances were introduced, it was moved to the
current_trace. But this structure is shared by all instances, and a
trace_pipe is for a single instance. There's no reason that a process that
has trace_pipe open on one instance should prevent another instance from
changing its current tracer. Move the reference counter to the trace_array
instead.
This is marked as "Fixes" but is more of a clean up than a true fix.
Backport if you want, but its not critical.
Fixes: cf6ab6d9143b1 ("tracing: Add ref count to tracer for when they are being read by pipe")
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
---
kernel/trace/trace.c | 12 ++++++------
kernel/trace/trace.h | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8241d1448d70..64c5b8146cca 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5891,7 +5891,7 @@ int tracing_set_tracer(struct trace_array *tr, const char *buf)
}
/* If trace pipe files are being read, we can't change the tracer */
- if (tr->current_trace->ref) {
+ if (tr->trace_ref) {
ret = -EBUSY;
goto out;
}
@@ -6107,7 +6107,7 @@ static int tracing_open_pipe(struct inode *inode, struct file *filp)
nonseekable_open(inode, filp);
- tr->current_trace->ref++;
+ tr->trace_ref++;
out:
mutex_unlock(&trace_types_lock);
return ret;
@@ -6126,7 +6126,7 @@ static int tracing_release_pipe(struct inode *inode, struct file *file)
mutex_lock(&trace_types_lock);
- tr->current_trace->ref--;
+ tr->trace_ref--;
if (iter->trace->pipe_close)
iter->trace->pipe_close(iter);
@@ -7428,7 +7428,7 @@ static int tracing_buffers_open(struct inode *inode, struct file *filp)
filp->private_data = info;
- tr->current_trace->ref++;
+ tr->trace_ref++;
mutex_unlock(&trace_types_lock);
@@ -7529,7 +7529,7 @@ static int tracing_buffers_release(struct inode *inode, struct file *file)
mutex_lock(&trace_types_lock);
- iter->tr->current_trace->ref--;
+ iter->tr->trace_ref--;
__trace_array_put(iter->tr);
@@ -8737,7 +8737,7 @@ static int __remove_instance(struct trace_array *tr)
int i;
/* Reference counter for a newly created trace array = 1. */
- if (tr->ref > 1 || (tr->current_trace && tr->current_trace->ref))
+ if (tr->ref > 1 || (tr->current_trace && tr->trace_ref))
return -EBUSY;
list_del(&tr->list);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 13db4000af3f..f21607f87189 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -356,6 +356,7 @@ struct trace_array {
struct trace_event_file *trace_marker_file;
cpumask_var_t tracing_cpumask; /* only trace on set CPUs */
int ref;
+ int trace_ref;
#ifdef CONFIG_FUNCTION_TRACER
struct ftrace_ops *ops;
struct trace_pid_list __rcu *function_pids;
@@ -547,7 +548,6 @@ struct tracer {
struct tracer *next;
struct tracer_flags *flags;
int enabled;
- int ref;
bool print_max;
bool allow_instances;
#ifdef CONFIG_TRACER_MAX_TRACE
--
2.26.2
On Thu, Jul 02, 2020 at 05:58:21PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <[email protected]>
>
> If a process has the trace_pipe open on a trace_array, the current tracer
> for that trace array should not be changed. This was original enforced by a
> global lock, but when instances were introduced, it was moved to the
> current_trace. But this structure is shared by all instances, and a
> trace_pipe is for a single instance. There's no reason that a process that
> has trace_pipe open on one instance should prevent another instance from
> changing its current tracer. Move the reference counter to the trace_array
> instead.
>
> This is marked as "Fixes" but is more of a clean up than a true fix.
> Backport if you want, but its not critical.
Thanks Steven! In case it helps backport consideration, I wanted to
note that this addresses an issue we've seen with users trying to
change current_tracer when they happen to have rasdaemon
installed. rasdaemon uses the trace_pipe interface at runtime, which
therefore blocks changing the current tracer. But of course, unless
you know about rasdaemon internals, it isn't exactly an obvious
failure mode.
-dann
> Fixes: cf6ab6d9143b1 ("tracing: Add ref count to tracer for when they are being read by pipe")
> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
> ---
> kernel/trace/trace.c | 12 ++++++------
> kernel/trace/trace.h | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8241d1448d70..64c5b8146cca 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -5891,7 +5891,7 @@ int tracing_set_tracer(struct trace_array *tr, const char *buf)
> }
>
> /* If trace pipe files are being read, we can't change the tracer */
> - if (tr->current_trace->ref) {
> + if (tr->trace_ref) {
> ret = -EBUSY;
> goto out;
> }
> @@ -6107,7 +6107,7 @@ static int tracing_open_pipe(struct inode *inode, struct file *filp)
>
> nonseekable_open(inode, filp);
>
> - tr->current_trace->ref++;
> + tr->trace_ref++;
> out:
> mutex_unlock(&trace_types_lock);
> return ret;
> @@ -6126,7 +6126,7 @@ static int tracing_release_pipe(struct inode *inode, struct file *file)
>
> mutex_lock(&trace_types_lock);
>
> - tr->current_trace->ref--;
> + tr->trace_ref--;
>
> if (iter->trace->pipe_close)
> iter->trace->pipe_close(iter);
> @@ -7428,7 +7428,7 @@ static int tracing_buffers_open(struct inode *inode, struct file *filp)
>
> filp->private_data = info;
>
> - tr->current_trace->ref++;
> + tr->trace_ref++;
>
> mutex_unlock(&trace_types_lock);
>
> @@ -7529,7 +7529,7 @@ static int tracing_buffers_release(struct inode *inode, struct file *file)
>
> mutex_lock(&trace_types_lock);
>
> - iter->tr->current_trace->ref--;
> + iter->tr->trace_ref--;
>
> __trace_array_put(iter->tr);
>
> @@ -8737,7 +8737,7 @@ static int __remove_instance(struct trace_array *tr)
> int i;
>
> /* Reference counter for a newly created trace array = 1. */
> - if (tr->ref > 1 || (tr->current_trace && tr->current_trace->ref))
> + if (tr->ref > 1 || (tr->current_trace && tr->trace_ref))
> return -EBUSY;
>
> list_del(&tr->list);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 13db4000af3f..f21607f87189 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -356,6 +356,7 @@ struct trace_array {
> struct trace_event_file *trace_marker_file;
> cpumask_var_t tracing_cpumask; /* only trace on set CPUs */
> int ref;
> + int trace_ref;
> #ifdef CONFIG_FUNCTION_TRACER
> struct ftrace_ops *ops;
> struct trace_pid_list __rcu *function_pids;
> @@ -547,7 +548,6 @@ struct tracer {
> struct tracer *next;
> struct tracer_flags *flags;
> int enabled;
> - int ref;
> bool print_max;
> bool allow_instances;
> #ifdef CONFIG_TRACER_MAX_TRACE
On Fri, 31 Jul 2020 13:33:45 -0600
dann frazier <[email protected]> wrote:
> > This is marked as "Fixes" but is more of a clean up than a true fix.
> > Backport if you want, but its not critical.
>
> Thanks Steven! In case it helps backport consideration, I wanted to
> note that this addresses an issue we've seen with users trying to
> change current_tracer when they happen to have rasdaemon
> installed. rasdaemon uses the trace_pipe interface at runtime, which
> therefore blocks changing the current tracer. But of course, unless
> you know about rasdaemon internals, it isn't exactly an obvious
> failure mode.
Ah, then this should probably be backported.
When I push to Linus (during the next merge window) and it gets into
Linus's tree. Feel free to send [email protected] the sha1 of this
commit, and ask for it to be backported for the above stated reason.
-- Steve
On Fri, Jul 31, 2020 at 3:16 PM Steven Rostedt <[email protected]> wrote:
>
> On Fri, 31 Jul 2020 13:33:45 -0600
> dann frazier <[email protected]> wrote:
>
> > > This is marked as "Fixes" but is more of a clean up than a true fix.
> > > Backport if you want, but its not critical.
> >
> > Thanks Steven! In case it helps backport consideration, I wanted to
> > note that this addresses an issue we've seen with users trying to
> > change current_tracer when they happen to have rasdaemon
> > installed. rasdaemon uses the trace_pipe interface at runtime, which
> > therefore blocks changing the current tracer. But of course, unless
> > you know about rasdaemon internals, it isn't exactly an obvious
> > failure mode.
>
> Ah, then this should probably be backported.
>
> When I push to Linus (during the next merge window) and it gets into
> Linus's tree. Feel free to send [email protected] the sha1 of this
> commit, and ask for it to be backported for the above stated reason.
Will do.
-dann