linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Song Liu <songliubraving@fb.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	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:08:50 +0000	[thread overview]
Message-ID: <6E88C284-7EEB-43EF-8C54-3DCB5F13124B@fb.com> (raw)
In-Reply-To: <CAELBmZCvrL4s+cx2cECMQLQUx0hMxVP-dv9UGBfh64AS6unaBA@mail.gmail.com>


> On Apr 18, 2018, at 7:03 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> 
> On Wed, Apr 18, 2018 at 8:29 AM, Song Liu <songliubraving@fb.com> wrote:
>> As Miklos reported and suggested:
>> 
>>  This pattern repeats two times in trace_uprobe.c and in
>>  kernel/events/core.c as well:
>> 
>>      ret = kern_path(filename, LOOKUP_FOLLOW, &path);
>>      if (ret)
>>          goto fail_address_parse;
>> 
>>      inode = igrab(d_inode(path.dentry));
>>      path_put(&path);
>> 
>>  And it's wrong.  You can only hold a reference to the inode if you
>>  have an active ref to the superblock as well (which is normally
>>  through path.mnt) or holding s_umount.
>> 
>>  This way unmounting the containing filesystem while the tracepoint is
>>  active will give you the "VFS: Busy inodes after unmount..." message
>>  and a crash when the inode is finally put.
>> 
>>  Solution: store path instead of inode.
>> 
>> This patch fixes two instances in trace_uprobe.c.
>> 
>> Fixes: f3f096cfedf8 ("tracing: Provide trace events interface for uprobes")
>> Fixes: 33ea4b24277b ("perf/core: Implement the 'perf_uprobe' PMU")
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Howard McLauchlan <hmclauchlan@fb.com>
>> Cc: Josef Bacik <jbacik@fb.com>
>> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
>> Reported-by: Miklos Szeredi <miklos@szeredi.hu>
>> Signed-off-by: Song Liu <songliubraving@fb.com>
>> ---
>> kernel/trace/trace_uprobe.c | 42 ++++++++++++++----------------------------
>> 1 file changed, 14 insertions(+), 28 deletions(-)
>> 
>> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
>> index 0d450b4..80dfcdf 100644
>> --- a/kernel/trace/trace_uprobe.c
>> +++ b/kernel/trace/trace_uprobe.c
>> @@ -55,7 +55,7 @@ struct trace_uprobe {
>>        struct list_head                list;
>>        struct trace_uprobe_filter      filter;
>>        struct uprobe_consumer          consumer;
>> -       struct inode                    *inode;
>> +       struct path                     path;
>>        char                            *filename;
>>        unsigned long                   offset;
>>        unsigned long                   nhit;
>> @@ -289,7 +289,7 @@ static void free_trace_uprobe(struct trace_uprobe *tu)
>>        for (i = 0; i < tu->tp.nr_args; i++)
>>                traceprobe_free_probe_arg(&tu->tp.args[i]);
>> 
>> -       iput(tu->inode);
>> +       path_put(&tu->path);
>>        kfree(tu->tp.call.class->system);
>>        kfree(tu->tp.call.name);
>>        kfree(tu->filename);
>> @@ -363,7 +363,6 @@ static int register_trace_uprobe(struct trace_uprobe *tu)
>> static int create_trace_uprobe(int argc, char **argv)
>> {
>>        struct trace_uprobe *tu;
>> -       struct inode *inode;
>>        char *arg, *event, *group, *filename;
>>        char buf[MAX_EVENT_NAME_LEN];
>>        struct path path;
>> @@ -371,7 +370,6 @@ static int create_trace_uprobe(int argc, char **argv)
>>        bool is_delete, is_return;
>>        int i, ret;
>> 
>> -       inode = NULL;
>>        ret = 0;
>>        is_delete = false;
>>        is_return = false;
>> @@ -448,14 +446,6 @@ static int create_trace_uprobe(int argc, char **argv)
>>        if (ret)
>>                goto fail_address_parse;
>> 
>> -       inode = igrab(d_inode(path.dentry));
> 
> This is not against -linus tree.

These patches are against tip/perf/core. I can also send version against 
-linus tree. 

> 
>> -       path_put(&path);
>> -
>> -       if (!inode || !S_ISREG(inode->i_mode)) {
>> -               ret = -EINVAL;
>> -               goto fail_address_parse;
>> -       }
>> -
>>        ret = kstrtoul(arg, 0, &offset);
>>        if (ret)
>>                goto fail_address_parse;
>> @@ -490,7 +480,8 @@ static int create_trace_uprobe(int argc, char **argv)
>>                goto fail_address_parse;
>>        }
>>        tu->offset = offset;
>> -       tu->inode = inode;
>> +       tu->path.mnt = path.mnt;
>> +       tu->path.dentry = path.dentry;
> 
> You can just assign the whole structure.  No need to mess with
> individual members.
> 
>        tu->path = path;
Will fix in v2. 
> 
>>        tu->filename = kstrdup(filename, GFP_KERNEL);
>> 
>>        if (!tu->filename) {
>> @@ -558,7 +549,7 @@ static int create_trace_uprobe(int argc, char **argv)
>>        return ret;
>> 
>> fail_address_parse:
>> -       iput(inode);
>> +       path_put(&path);
>> 
>>        pr_info("Failed to parse address or file.\n");
>> 
>> @@ -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?
> 
> 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.

trace_uprobe will not be freed before the uprobe object. trace_uprobe 
holds reference to struct path (with path_get()). 

> 
>>        if (ret)
>>                goto err_buffer;
>> 
>> @@ -981,7 +973,7 @@ probe_event_disable(struct trace_uprobe *tu, struct trace_event_file *file)
>> 
>>        WARN_ON(!uprobe_filter_is_empty(&tu->filter));
>> 
>> -       uprobe_unregister(tu->inode, tu->offset, &tu->consumer);
>> +       uprobe_unregister(d_inode(tu->path.dentry), tu->offset, &tu->consumer);
>>        tu->tp.flags &= file ? ~TP_FLAG_TRACE : ~TP_FLAG_PROFILE;
>> 
>>        uprobe_buffer_disable();
>> @@ -1056,7 +1048,8 @@ static int uprobe_perf_close(struct trace_uprobe *tu, struct perf_event *event)
>>        write_unlock(&tu->filter.rwlock);
>> 
>>        if (!done)
>> -               return uprobe_apply(tu->inode, tu->offset, &tu->consumer, false);
>> +               return uprobe_apply(d_inode(tu->path.dentry), tu->offset,
>> +                                   &tu->consumer, false);
>> 
>>        return 0;
>> }
>> @@ -1088,7 +1081,8 @@ static int uprobe_perf_open(struct trace_uprobe *tu, struct perf_event *event)
>> 
>>        err = 0;
>>        if (!done) {
>> -               err = uprobe_apply(tu->inode, tu->offset, &tu->consumer, true);
>> +               err = uprobe_apply(d_inode(tu->path.dentry),
>> +                                  tu->offset, &tu->consumer, true);
>>                if (err)
>>                        uprobe_perf_close(tu, event);
>>        }
>> @@ -1352,7 +1346,6 @@ struct trace_event_call *
>> create_local_trace_uprobe(char *name, unsigned long offs, bool is_return)
>> {
>>        struct trace_uprobe *tu;
>> -       struct inode *inode;
>>        struct path path;
>>        int ret;
>> 
>> @@ -1360,14 +1353,6 @@ create_local_trace_uprobe(char *name, unsigned long offs, bool is_return)
>>        if (ret)
>>                return ERR_PTR(ret);
>> 
>> -       inode = igrab(d_inode(path.dentry));
>> -       path_put(&path);
>> -
>> -       if (!inode || !S_ISREG(inode->i_mode)) {
>> -               iput(inode);
>> -               return ERR_PTR(-EINVAL);
>> -       }
>> -
>>        /*
>>         * local trace_kprobes are not added to probe_list, so they are never
>>         * searched in find_trace_kprobe(). Therefore, there is no concern of
>> @@ -1383,7 +1368,8 @@ create_local_trace_uprobe(char *name, unsigned long offs, bool is_return)
>>        }
>> 
>>        tu->offset = offs;
>> -       tu->inode = inode;
>> +       tu->path.mnt = path.mnt;
>> +       tu->path.dentry = path.dentry;
> 
> tu->path = path
> 
> 
>>        tu->filename = kstrdup(name, GFP_KERNEL);
>>        init_trace_event_call(tu, &tu->tp.call);
>> 
>> --
>> 2.9.5
>> 

  parent reply	other threads:[~2018-04-18 16:09 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
2018-04-18 16:08   ` Song Liu [this message]
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=6E88C284-7EEB-43EF-8C54-3DCB5F13124B@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).