[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegv807ktfv+tjYE65Yr_TbGnjds6ZCtoYX_yQTg_1wodzQ@mail.gmail.com>
Date: Thu, 26 Apr 2018 15:24:55 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Song Liu <songliubraving@...com>
Cc: linux-kernel@...r.kernel.org, kernel-team <kernel-team@...com>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Howard McLauchlan <hmclauchlan@...com>,
Josef Bacik <jbacik@...com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Subject: Re: [PATCH v5 1/2] tracing: fix bad use of igrab in trace_uprobe.c
On Mon, Apr 23, 2018 at 7:21 PM, Song Liu <songliubraving@...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. struct path is added to
> struct trace_uprobe to keep the inode and containing mount point
> referenced.
>
> Fixes: f3f096cfedf8 ("tracing: Provide trace events interface for uprobes")
> Fixes: 33ea4b24277b ("perf/core: Implement the 'perf_uprobe' PMU")
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Howard McLauchlan <hmclauchlan@...com>
> Cc: Josef Bacik <jbacik@...com>
> Cc: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> Cc: Miklos Szeredi <miklos@...redi.hu>
> Reported-by: Miklos Szeredi <miklos@...redi.hu>
> Signed-off-by: Song Liu <songliubraving@...com>
Acked-by: Miklos Szeredi <mszeredi@...hat.com>
Powered by blists - more mailing lists