[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241028101850.548f0fcd@rorschach.local.home>
Date: Mon, 28 Oct 2024 10:18:50 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, Masami
Hiramatsu <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton
<akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 5/5] ftrace: Use guard to take ftrace_lock in
ftrace_graph_set_hash()
On Mon, 28 Oct 2024 10:16:56 +0100
Peter Zijlstra <peterz@...radead.org> wrote:
> > @@ -6846,13 +6844,8 @@ ftrace_graph_set_hash(struct ftrace_hash *hash, char *buffer)
> > }
> > }
> > } while_for_each_ftrace_rec();
> > -out:
> > - mutex_unlock(&ftrace_lock);
> >
> > - if (fail)
> > - return -EINVAL;
> > -
> > - return 0;
> > + return fail ? -EINVAL : 0;
> > }
>
> Isn't the fail case more a case of -ESRCH / -ENOENT rather than -EINVAL?
Could be. Although this is mostly for internal use. I should check to
see if this gets back to user space. And yeah, it probably should be
changed.
>
> Anyway, that's orthogonal, the patch preserves existing semantics and
> looks okay (as do the others fwiw).
Thanks for the review!
-- Steve
Powered by blists - more mailing lists