[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091209141619.GA21862@elte.hu>
Date: Wed, 9 Dec 2009 15:16:19 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
srostedt@...hat.com, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:tracing/urgent] tracing: Add pipe_close interface
* Steven Rostedt <rostedt@...dmis.org> wrote:
> On Wed, 2009-12-09 at 15:35 +0900, KOSAKI Motohiro wrote:
>
> > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > > index 874f289..f804b40 100644
> > > --- a/kernel/trace/trace.c
> > > +++ b/kernel/trace/trace.c
> > > @@ -2898,6 +2898,10 @@ static int tracing_release_pipe(struct inode *inode, struct file *file)
> > > else
> > > cpumask_clear_cpu(iter->cpu_file, tracing_reader_cpumask);
> > >
> > > +
> > > + if (iter->trace->pipe_open)
> > > + iter->trace->pipe_close(iter);
> > > +
> >
> > What's happen if pipe_close is NULL? Wny following straightforward check
> > is wrong?
> > I mean the above description explain pipe_close is only useful if plugin
> > allocate something at pipe_open. then allowing NULL seems natural.
> >
> > if (iter->trace->pipe_close)
> > iter->trace->pipe_close(iter);
>
> Ug, good point (stupid cut & paste should be illegal).
>
> Ingo, I'll fix this up too in the next patch set. Want me to rebase it
> or just start with this fix?
I'd suggest to start with a fix. Thanks,
Ingo
--
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