On Tue, 27 Jan 2015 10:19:53 -0500
Steven Rostedt wrote:
>
> You mean, instead of grabbing trace_types_lock for modifying of events
> and trace arrays, we should grab the dentry->d_inode->i_mutex?
>
OK, trace_arrays_lock protects against the tr->current_trace and the
list of arrays, and accessi
On Tue, 27 Jan 2015 04:38:39 +
Al Viro wrote:
> On Mon, Jan 26, 2015 at 08:03:50PM -0500, Steven Rostedt wrote:
> > On Mon, 26 Jan 2015 20:02:18 -0500
> > Steven Rostedt wrote:
> >
> >
> > > Now you see why I found just dropping the parent mutex easier.
> >
> > And this is probably why ke
On Tue, 27 Jan 2015 04:34:21 +
Al Viro wrote:
> Frankly, the first impression is that you have trace_types_lock way too
> high in the hierarchy - you are taking it well outside of the level where
> you start walking through ftrace_trace_arrays...
Actually, it is originally used for modifyin
On Mon, Jan 26, 2015 at 09:34:19PM -0500, Steven Rostedt wrote:
> On Mon, 26 Jan 2015 18:37:39 -0500
> Steven Rostedt wrote:
>
>
> > > the first call of tracing_init_dentry(). Prior to that it's NULL.
> > > BTW, may I politely inquire what the fuck are those contortions in
> > > tracing_init_de
On Mon, Jan 26, 2015 at 08:03:50PM -0500, Steven Rostedt wrote:
> On Mon, 26 Jan 2015 20:02:18 -0500
> Steven Rostedt wrote:
>
>
> > Now you see why I found just dropping the parent mutex easier.
>
> And this is probably why kernfs does things the way it does. I can
> imagine it having the same
On Mon, Jan 26, 2015 at 07:39:09PM -0500, Steven Rostedt wrote:
> On Mon, 26 Jan 2015 18:49:16 -0500
> Steven Rostedt wrote:
>
> > On Mon, 26 Jan 2015 18:43:14 -0500
> > Steven Rostedt wrote:
> >
> > > That is, we can not hold i_mutex and take trace_types_lock.
> > >
> > > trace_types_lock ne
On Mon, 26 Jan 2015 18:37:39 -0500
Steven Rostedt wrote:
> > the first call of tracing_init_dentry(). Prior to that it's NULL.
> > BTW, may I politely inquire what the fuck are those contortions in
> > tracing_init_dentry_tr() about? Looks like a stunningly convoluted
> > way to trigger that a
On Mon, 26 Jan 2015 20:02:18 -0500
Steven Rostedt wrote:
> Now you see why I found just dropping the parent mutex easier.
And this is probably why kernfs does things the way it does. I can
imagine it having the same locking issues.
-- Steve
--
To unsubscribe from this list: send the line "unsu
On Tue, 27 Jan 2015 00:37:42 +
Al Viro wrote:
> On Mon, Jan 26, 2015 at 06:43:14PM -0500, Steven Rostedt wrote:
>
> > I originally had this, but the issue isn't with i_mutex only. The
> > instance_mkdir and instance_rmdir need to grab trace_types_lock.
> > This is also held when calling into
On Mon, 26 Jan 2015 18:49:16 -0500
Steven Rostedt wrote:
> On Mon, 26 Jan 2015 18:43:14 -0500
> Steven Rostedt wrote:
>
> > That is, we can not hold i_mutex and take trace_types_lock.
> >
> > trace_types_lock needs to be held with the creation or destruction
> > of events, which is what mkdir
On Mon, Jan 26, 2015 at 06:43:14PM -0500, Steven Rostedt wrote:
> I originally had this, but the issue isn't with i_mutex only. The
> instance_mkdir and instance_rmdir need to grab trace_types_lock. This
> is also held when calling into tracefs.
>
> That is, we can not hold i_mutex and take trace
On Mon, 26 Jan 2015 21:40:20 +
Al Viro wrote:
> Is the following correct?
> * only one directory in the entire tree (/instances) allows mkdir/rmdir.
yes
> * ftrace_trace_arrays always starts with global_trace and the rest
> is in 1-to-1 correspondence with subdirectories of /in
On Mon, 26 Jan 2015 21:46:58 +
Al Viro wrote:
> On Mon, Jan 26, 2015 at 03:42:59PM -0500, Steven Rostedt wrote:
> > On Mon, 26 Jan 2015 19:30:49 +
> > Al Viro wrote:
> >
> > > You are still fighting an inconvenient API, but now it's not debugfs one -
> > > it's your copy thereof. Why n
On Mon, 26 Jan 2015 23:02:03 +
Al Viro wrote:
> BTW, could you merge vfs.git#debugfs_automount, rather than copy the commits
> into your branch? Bloody inconvenient as it is...
Ah, you're pushing it. Sorry, I thought this was more of a temp branch
for me to play with.
OK, I can merge it.
On Mon, 26 Jan 2015 18:43:14 -0500
Steven Rostedt wrote:
> That is, we can not hold i_mutex and take trace_types_lock.
>
> trace_types_lock needs to be held with the creation or destruction of
> events, which is what mkdir an rmdir do.
Although, I can not remember how this happened, but lockde
On Mon, Jan 26, 2015 at 09:46:58PM +, Al Viro wrote:
> On Mon, Jan 26, 2015 at 03:42:59PM -0500, Steven Rostedt wrote:
> > On Mon, 26 Jan 2015 19:30:49 +
> > Al Viro wrote:
> >
> > > You are still fighting an inconvenient API, but now it's not debugfs one -
> > > it's your copy thereof.
On Mon, Jan 26, 2015 at 03:42:59PM -0500, Steven Rostedt wrote:
> On Mon, 26 Jan 2015 19:30:49 +
> Al Viro wrote:
>
> > You are still fighting an inconvenient API, but now it's not debugfs one -
> > it's your copy thereof. Why not give your instances/ an inode_operations
> > of its own? One
On Mon, Jan 26, 2015 at 03:58:22PM -0500, Steven Rostedt wrote:
> On Mon, 26 Jan 2015 15:44:19 -0500
> Steven Rostedt wrote:
>
> > Now what I could also do is to only allow this to be called once. And
> > in that case, we can hard code what mkdir and rmdir are. This could
> > work as currently th
On Mon, Jan 26, 2015 at 07:30:49PM +, Al Viro wrote:
> On Mon, Jan 26, 2015 at 10:09:13AM -0500, Steven Rostedt wrote:
> > There has been complaints that tracing is tied too much to debugfs,
> > as there are systems that would like to perform tracing, but do
> > not mount debugfs for security r
On Mon, 26 Jan 2015 15:44:19 -0500
Steven Rostedt wrote:
> Now what I could also do is to only allow this to be called once. And
> in that case, we can hard code what mkdir and rmdir are. This could
> work as currently there only exists a single instance of the instances
> directory.
>
> I might
On Mon, 26 Jan 2015 15:42:59 -0500
Steven Rostedt wrote:
> - if (IS_ERR(dentry))
> +struct dentry *tracefs_create_instance_dir(const char *name, struct dentry
> *parent,
> + int (*mkdir)(const char *name),
> + int
On Mon, 26 Jan 2015 19:30:49 +
Al Viro wrote:
> You are still fighting an inconvenient API, but now it's not debugfs one -
> it's your copy thereof. Why not give your instances/ an inode_operations
> of its own? One with ->mkdir() and ->rmdir(), leaving all other directories
> as-is. That
On Mon, Jan 26, 2015 at 10:09:13AM -0500, Steven Rostedt wrote:
> There has been complaints that tracing is tied too much to debugfs,
> as there are systems that would like to perform tracing, but do
> not mount debugfs for security reasons. That is because any subsystem
> may use debugfs for debug
23 matches
Mail list logo
