[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200124184502.6e4683f3@gandalf.local.home>
Date: Fri, 24 Jan 2020 18:45:02 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHES] constifying ftrace globs
Seems that this series fell through the cracks. Is it worth
resurrecting?
-- Steve
On Thu, 5 Feb 2015 19:49:14 +0000
Al Viro <viro@...IV.linux.org.uk> wrote:
> We don't really need to NUL-terminate the substring we are
> matching against; all it takes is introducing memmem(3) and using it
> instead of str[n]str().
>
> It's not that much work - see vfs.git#ftrace_glob. The reason
> I went there is rather amusing; it all started with making do_execve()
> take arrays of const strings for argv and envp. After all, we never
> change them *and* we often enough pass arrays of string literals that
> way. It exploded into a series of 75 commits, with the final ripple
> being argv_split() and argv_free(). OK, turns out that ftrace is
> using those as well, fortunately it's done to get arrays of regexes,
> so it should be trivial to constify as well, right? Imagine the amount of
> swearing when I noticed that it *does* modify the resulting strings...
>
> This series deals with that problem, providing the missing prereq for
> the patchbomb from hell...
>
> Could you review #ftrace_glob? It's not large - seven commits,
> boiling down to
> include/linux/ftrace.h | 8 ++---
> include/linux/string.h | 1 +
> kernel/trace/ftrace.c | 68 ++++++++++++++++++--------------------
> kernel/trace/trace.h | 2 +-
> kernel/trace/trace_events_filter.c | 26 +++++++++------
> lib/string.c | 34 ++++++++++++-------
> 6 files changed, 75 insertions(+), 64 deletions(-)
>
> Patches in followups.
Powered by blists - more mailing lists