From: Song Liu <songliubraving@fb.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
LKML <linux-kernel@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>, Ingo Molnar <mingo@redhat.com>,
"Howard McLauchlan" <hmclauchlan@fb.com>,
Josef Bacik <jbacik@fb.com>,
"Srikar Dronamraju" <srikar@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/2] tracing: fix bad use of igrab in trace_uprobe.c
Date: Wed, 18 Apr 2018 16:15:50 +0000 [thread overview]
Message-ID: <939B1EB1-07D3-473F-B7D1-21E7B0F6CF13@fb.com> (raw)
In-Reply-To: <20180418102504.7673a7f3@gandalf.local.home>
> On Apr 18, 2018, at 7:25 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 18 Apr 2018 16:03:42 +0200
> Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>>> @@ -937,7 +928,8 @@ probe_event_enable(struct trace_uprobe *tu, struct trace_event_file *file,
>>> goto err_flags;
>>>
>>> tu->consumer.filter = filter;
>>> - ret = uprobe_register(tu->inode, tu->offset, &tu->consumer);
>>> + ret = uprobe_register(d_inode(tu->path.dentry), tu->offset,
>>> + &tu->consumer);
>>
>> It is not entirely clear how the lifetime of uprobe relates to the
>> lifetime of trace_uprobe. Is the uprobe object never going to survive
>> its creator trace_uprobe object?
>
> Not exactly sure what you mean here.
>
> The trace_uprobe (the probe event) is created, it doesn't do anything
> until it is enabled. This function is called when it is enabled. The
> trace_uprobe (probe event) can not be deleted while it is enabled
> (EBUSY).
>
> Are you asking what happens if the file is deleted while it has probe?
> That I don't know about (haven't tried it out). But I would hope that
> it keeps a reference to the inode, isn't that what the igrab is for?
> And is now being replaced by a reference on the path, or is that the
> problem?
>
> -- Steve
>
Just as Miklos pointed out, I run tests with the uprobe and confirmed
that igrab() is not sufficient to prevent umount. When we change it to
path_get()/path_put(), umount will abort because of the trace_uprobe.
Song
>>
>> If that's the case, it warrants a comment. If that's not the case,
>> then the path would need to be passed to uprobe_resister() which would
>> need to obtain its own reference.
>>
>>> if (ret)
>>> goto err_buffer;
>>>
next prev parent reply other threads:[~2018-04-18 16:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 6:29 [PATCH 1/2] tracing: fix bad use of igrab in trace_uprobe.c Song Liu
2018-04-18 6:29 ` [PATCH 2/2] perf/core: fix bad use of igrab in kernel/event/core.c Song Liu
2018-04-19 6:17 ` Alexander Shishkin
2018-05-22 21:56 ` Song Liu
2018-05-23 13:11 ` Peter Zijlstra
2018-05-25 9:49 ` [tip:perf/core] perf/core: Fix bad use of igrab() tip-bot for Song Liu
2018-04-18 14:03 ` [PATCH 1/2] tracing: fix bad use of igrab in trace_uprobe.c Miklos Szeredi
2018-04-18 14:25 ` Steven Rostedt
2018-04-18 14:40 ` Miklos Szeredi
2018-04-18 15:19 ` Steven Rostedt
2018-04-18 16:15 ` Song Liu [this message]
2018-04-18 16:08 ` Song Liu
2018-04-18 16:25 ` Steven Rostedt
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=939B1EB1-07D3-473F-B7D1-21E7B0F6CF13@fb.com \
--to=songliubraving@fb.com \
--cc=Kernel-team@fb.com \
--cc=hmclauchlan@fb.com \
--cc=jbacik@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).