[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1239769945.7852.21.camel@tropicana>
Date: Tue, 14 Apr 2009 23:32:25 -0500
From: Tom Zanussi <tzanussi@...il.com>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Steven Rostedt <rostedt@...dmis.org>,
paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH] tracing/filters: allow on-the-fly filter switching
On Tue, 2009-04-14 at 22:56 +0200, Frederic Weisbecker wrote:
> On Mon, Apr 13, 2009 at 03:17:50AM -0500, Tom Zanussi wrote:
[...]
>
>
> BTW, this issue might be already present before this patch.
> What happens if:
>
>
> T1 T2
>
> event_filter_read() {
> filter_print_preds() {
> for (i = 0; i < n_preds; i++) {
> pred = preds[i];
> event_filter_write() {
> filter_disable_preds();
> filter_clear_preds() {
> kfree(pred->field_name);
> field_name = pred->field_name;
> // CRASH!!!
>
>
> You need a mutex to protect these two callbacks.
> It would also protect concurrent calls to event_filter_write(),
> which would result in random.
>
Yeah, Li Zefan had already fixed this, but it wasn't included in this
patch. Looks like he'll be resubmitting that part...
>
>
[...]
> Also, is filter_add_pred() supposed to be available for in-kernel
> uses by other tracers or something?
No, the current callers were the only ones I'd planned on (it's not
static because code in trace_events.c needs to call it). But, do you
see a use for it by other tracers?
> If this is planned, the locking could be even deeper than my comments.
>
> Other than these comments:
>
> Acked-by: Frederic Weisbecker <fweisbec@...il.com>
>
> Thanks!
>
Thanks for reviewing it!
Tom
--
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/
Powered by blists - more mailing lists