[lkml]   [2013]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/4] tracing: fix open/delete fixes
(2013/07/17 23:43), Oleg Nesterov wrote:
> On 07/17, Masami Hiramatsu wrote:
>> At a glance, you're trying to change which operation will be
>> failed. Currently, user can not remove an event while someone
>> opens files which related to the event. And this approach
>> changes that the someone can remove the event even if the
>> files are opened (and read/write operation will be failed).
>> Am I understand correctly?
> Yes.
> Once again, I am still not sure and I am asking for your review.


> But to me this looks much better. To simplify the discussion, lets
> consider ftrace_enable_fops in particular.
> - Why should .open() block rmdir or unregister_uprobe_event?

Because it is opened and under preparing for use. :)
But, yeah, if we expect there is only one user using
ftrace, accessing the removing event file is meaningless.
It should be failed.

> - Why do we need .open() at all? Whatever it can do to
> validate file/call/etc, .read/write can do the same.

Currently, just for preparing and reserving.

> - If we kill .open/release, we do not need the nontrivial
> refcounting. Everything becomes simple, no need to keep
> the state "in between".

That also means to refrain checking existence under locking mutex
in all operations. And we have to check it, which I actually concern.
refcounting is not so small and itself is complex, but it just
needs to inc/dec on open/close.

> We need event_mutex anyway (and note that other f_op's can
> also rely on other locks taken by trace_remove_event_call),
> the validation degrades to the trivial != NULL check.
> - This also simplifies trace_remove_event_call() paths, we
> know that once it takes event_mutex nobody can play with
> ftrace_event_file/ftrace_event_call we are going to free.

Hmm, it seems that we can remove only refcount check, or more?

Thank you,

IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory

 \ /
  Last update: 2013-07-18 10:41    [W:0.070 / U:22.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site