Messages in this thread | | | Date | Sat, 19 Oct 2013 16:18:59 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH] tracing: fix referencing after memory freeing and refactors code |
| |
On 10/19, Geyslan Gregório Bem wrote: > > 2013/10/19 Oleg Nesterov <oleg@redhat.com>: > > On 10/17, Steven Rostedt wrote: > >> > >> 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. > > > > Aren't "ftrace_enable_fops" and "ftrace_event_filter_fops" structures?
I meant, their ->open() methods.
> About event_file_data() I think that the callers uses the > private_data. So, we have to analyze better.
No, event_file_data() uses ->i_private, filp->private_data is not used. And it can't be used, it can point to the already destroyed/freed data.
but, as for seq_open() users,
> static int trace_format_open(struct inode *inode, struct file *file) > { > struct seq_file *m; > int ret; > > ret = seq_open(file, &trace_format_seq_ops); > if (ret < 0) > return ret; > > m = file->private_data; > m->private = file; > > return 0; > } > > I really got confused here. The 'm' assignments are, to me, pointless.
I confused too... Why do you think it is pointless?
Just in case, not that after seq_open() ->private_data points to seq_file but it is still "void *". And in this case ->private_data has nothing to do with ->private_data set by tracing_open_generic().
Oleg.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |