From: Steven Rostedt <srostedt@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>,
George Spelvin <linux@horizon.com>,
linux-kernel@vger.kernel.org, tj@kernel.org
Subject: Re: [RFC] globmatch() helper function
Date: Wed, 17 Dec 2008 10:47:36 -0500 [thread overview]
Message-ID: <1229528856.30177.4.camel@localhost.localdomain> (raw)
In-Reply-To: <1229526942.9487.75.camel@twins>
On Wed, 2008-12-17 at 16:15 +0100, Peter Zijlstra wrote:
> On Wed, 2008-12-17 at 14:28 +0100, Andi Kleen wrote:
> > "George Spelvin" <linux@horizon.com> writes:
> >
> > Wow, finally a name.
> >
> > > break;
> > > case '*':
> > > if (pat[1] == '\0') /* Optimize trailing * case */
> > > return true;
> > > /* Recurse on each possible tail of str */
> > > while (!globmatch(pat+1, str))
> > > if (!*str++)
> > > return false;
> >
> > I'm uneasy with the unbounded recursion. Sure currently all the users
> > are controlled in kernel source code and expect to put in sane patterns.
> > But if someone ever adds a user controlled glob in some way it will be
> > trivial to crash/overwrite memory with the limited kernel stack.
> > And with such a generalized function it's likely to be used more
> > in the future.
>
> ftrace has a globbing thing in there somewhere as well and that does
> indeed take user input.
>
> Using recursion in kernel code is indeed not recommended, what Andi said
> we have tiny stacks.
ftrace has a very limited glob feature, and requires no recursion.
Basically, we allow:
*match
match*
*match*
We do not allow match*two, that would be the same as match*
I need to look at your code (I would like a generalized glob feature for
user input). Can you accomplish the same with using a loop instead of
recursion?
-- Steve
next prev parent reply other threads:[~2008-12-17 15:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 10:42 [RFC] globmatch() helper function George Spelvin
2008-12-17 13:28 ` Andi Kleen
2008-12-17 15:15 ` Peter Zijlstra
2008-12-17 15:47 ` Steven Rostedt [this message]
2008-12-17 16:15 ` Andi Kleen
2008-12-18 8:00 ` George Spelvin
2008-12-18 8:55 ` George Spelvin
2008-12-18 19:53 ` Casey Dahlin
2008-12-18 21:53 ` George Spelvin
2008-12-17 16:04 ` George Spelvin
2008-12-17 16:13 ` Steven Rostedt
2008-12-17 16:22 ` Tejun Heo
2008-12-17 16:31 ` Steven Rostedt
2008-12-17 16:33 ` Tejun Heo
2008-12-17 16:36 ` Peter Zijlstra
2008-12-17 16:45 ` Tejun Heo
2008-12-17 16:37 ` Steven Rostedt
2008-12-17 16:51 ` Andi Kleen
2008-12-17 16:54 ` Steven Rostedt
2008-12-17 15:37 ` George Spelvin
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=1229528856.30177.4.camel@localhost.localdomain \
--to=srostedt@redhat.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox