All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()
Date: Sat, 27 Jan 2018 17:07:48 +0000	[thread overview]
Message-ID: <20180127170748.GF13338@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAJwJo6YD4ds-AHZRm-zEyGCnu+PS-6g_FFeAmHDfaKQxQAUr=A@mail.gmail.com>

On Sat, Jan 27, 2018 at 01:59:56PM +0000, Dmitry Safonov wrote:
> 
> > Incidentally, shouldn't filter_parse_regex("*[ab]", 5, &s, &not)
> > end up with s = "*[ab]"?  We are returning MATCH_GLOB, after all,
> > so we want the entire pattern there...  I would've assumed that
> > this is what the code in unregister_ftrace_function_probe_func()
> > is trying to compensate for, the first oddity predates MATCH_GLOB...
> 
> No, I don't think filter_parse_regex() should return the full regex..
> ftrace_match() expects search would be processed string, not a glob.
> So, this unnecessary assignment broke unregistering multiple kprobs
> with a middle/end pattern..

For substring - sure, but what about something like "*a*b" and "a*b"?
AFAICS, filter_parse_regex() ends up with identical results in both
cases - MATCH_GLOB and *search = "a*b".  And no way for the caller
to tell one from another.

IOW, it's a different bug sometimes obscured by the one in
unregister_ftrace_function_probe_func().  filter_parse_regex()
ought to revert to *search = buff; when it decides to return
MATCH_GLOB.  Or something like
        for (i = 0; i < len; i++) {
                if (buff[i] == '*') {
                        if (!i) {
                                type = MATCH_END_ONLY;
                        } else if (i == len - 1) {
                                if (type == MATCH_END_ONLY)
                                        type = MATCH_MIDDLE_ONLY;
                                else
                                        type = MATCH_FRONT_ONLY;
                                buff[i] = 0;
                                break;
                        } else {        /* pattern continues, use full glob */
                                return MATCH_GLOB;
                        }
                } else if (strchr("[?\\", buff[i])) {
                        return MATCH_GLOB;
                }
        }
        if (buff[0] == '*')
                *search = buff + 1;
for that matter - i.e. delay that "we want everything past the first character"
until we are certain it's not a MATCH_GLOB.

That one was introduced by "ftrace: Support full glob matching" in 2016, AFAICS...

  reply	other threads:[~2018-01-27 17:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-27  3:17 [RFC] apparent bogosity in unregister_ftrace_function_probe_func() Al Viro
2018-01-27 13:59 ` Dmitry Safonov
2018-01-27 17:07   ` Al Viro [this message]
2018-01-28 10:31     ` Steven Rostedt
2018-01-29 13:59     ` Masami Hiramatsu
2018-02-05 22:54       ` Steven Rostedt
2018-02-06  1:25         ` Dmitry Safonov
2018-02-06  2:26         ` Masami Hiramatsu
2018-02-06  2:40           ` Steven Rostedt
2018-02-06  2:44             ` Dmitry Safonov
2018-02-06  2:48               ` Steven Rostedt
2018-02-06  2:53                 ` Dmitry Safonov
2018-01-29 13:49 ` Masami Hiramatsu

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=20180127170748.GF13338@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=0x7f454c46@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.