linux-kernel - Re: [RFC][PATCH 4/5] tracing/filters: Provide basic regex support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Aug 2009 03:49:42 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC][PATCH 4/5] tracing/filters: Provide basic regex support

On Thu, Aug 06, 2009 at 09:14:27AM +0800, Li Zefan wrote:
> Frederic Weisbecker wrote:
> > On Mon, Aug 03, 2009 at 01:39:58PM +0800, Li Zefan wrote:
> >> Frederic Weisbecker wrote:
> >>> This patch provides basic support for regular expressions in filters.
> >>> The common filter file doesn't support any regex but a new
> >>> filter_regex file is created for each subsystem/event.
> >>>
> >>> It supports the following types of regexp:
> >>>
> >>> - *match_beginning
> >>> - *match_middle*
> >>> - match_end*
> >>> - !don't match
> >>>
> >> I don't see why adding "filter_regex" is necessary, why not just make
> >> "filter" support regex?
> > 
> > I did that because I feared about people beeing unable to filter using
> > * as a real character inside a filter string.
> > If we are using only one file, we are forced to get the '*' interpreted.
> > That would also break the ABI.
> > 
> 
> I think we don't maintain stable ABI for debugfs and we've been changing
> the "ABI" in debugfs/tracing/, but of course we shouldn't change it
> without good reasons.

Yeah. May be I'm too much careful there but i prefer not to take the risk.

> One alternative is to use '"' to prevent '*' to be translated, but seems
> using "filter_regex" is more convenient, so I agree with this patch.

The problem is that most of the time, the '"' is about mandatory to delimit
a string.
Say you want to filter the lock name &REISERFS_SB(sb)->lock, you can't do that
by just typing:

echo name == &REISERFS_SB(sb)->lock > events/lockdep/filter

because the '&' character is considered as an operator and that will trigger
an error.
Instead you must type:

echo 'name == "&REISERFS_SB(sb)->lock"' > events/lockdep/filter

The '' are there to delimit the string for echo, and the "" are interpreted
by the filter api which take it as a whole string and not strings interleaved
with operators. I even fear - and > may be considered as operators if we omit
the "".

I also thought about using an antislash for those who don't want the * to
be interpreted. But although it seems intuitive, it's not as much as two
distinct and visible files.

Also, we can think about the fact the regexp support could be extended one
day if someone needs to. And we could then encounter even more ambiguous
characters such as $, ^, [, {, etc...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/