From: Oleg Nesterov <oleg@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Geyslan G. Bem" <geyslan@gmail.com>,
kernel-br@googlegroups.com,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Subject: Re: [PATCH] tracing: fix referencing after memory freeing and refactors code
Date: Sat, 19 Oct 2013 14:43:12 +0200 [thread overview]
Message-ID: <20131019124312.GA23872@redhat.com> (raw)
In-Reply-To: <20131017224605.2e1d4bab@gandalf.local.home>
On 10/17, Steven Rostedt wrote:
>
> On Thu, 17 Oct 2013 22:44:56 -0300
> "Geyslan G. Bem" <geyslan@gmail.com> wrote:
>
> > and fix the possible 'dir'
> > assignment after freeing it.
This should be safe afaics, nobody will use it anyway. Even
subsystem_release() won't be called if .open() fails. But I agree
this doesn't look good.
> I'm thinking of just nuking the tracing_open_generic() here. The only
> thing it does here is the tracing_disabled check. The assignment of
> inode->i_private to filp->private_data is pointless
The same for ftrace_enable_fops() and ftrace_event_filter_fops() at
least. The users of event_file_data() do not use ->private_data.
OTOH, say, trace_format_open() doesn't check tracing_disabled, so
> We could add a tracing_is_disabled() function to test instead.
perhaps it can have more callers.
Oleg.
next prev parent reply other threads:[~2013-10-19 12:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 1:44 [PATCH] tracing: fix referencing after memory freeing and refactors code Geyslan G. Bem
2013-10-18 2:46 ` Steven Rostedt
2013-10-18 9:49 ` Geyslan Gregório Bem
2013-10-18 11:02 ` Geyslan Gregório Bem
2013-10-18 12:34 ` Steven Rostedt
2013-10-19 12:43 ` Oleg Nesterov [this message]
2013-10-19 13:34 ` Oleg Nesterov
2013-10-19 13:58 ` Geyslan Gregório Bem
2013-10-19 14:18 ` Oleg Nesterov
2013-10-19 14:41 ` Geyslan Gregório Bem
2013-10-19 19:10 ` Steven Rostedt
2013-10-19 19:35 ` Geyslan Gregório Bem
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=20131019124312.GA23872@redhat.com \
--to=oleg@redhat.com \
--cc=fweisbec@gmail.com \
--cc=geyslan@gmail.com \
--cc=kernel-br@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--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.