Re: [PATCH 00/16 v3] tracing: Add new file system tracefs

From: Steven Rostedt
Date: Mon Jan 26 2015 - 20:01:57 EST


On Tue, 27 Jan 2015 00:37:42 +0000
Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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 tracefs.
> >
> > 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.
>
> Yecchhh...
>
> Looks like something that fell out of BKL removal - AFAICS, you are
> using it to protect all kinds of things ;-/

It's only used to protect slow paths. Yes, it grew more than what it
should protect. I had patches to add a few more mutexes, to narrow
things down. But that still did not solve this issue. The broken out
mutex still needed to be held when events are created.

The main issue is that mkdir() and rmdir() will create events that
require holding a mutex to make sure access to the events are
serialized.

But creating events requires grabbing the i_mutex. We can create events
either with mkdir() or when a module is loaded that has its own events.

Same goes with the mutex that protects adding and removing of
trace_arrays. When a module is loaded, we need to add events to each
trace array that exists (requiring that we grab the mutex that protects
that list). And hold it while we add our events.

Now you see why I found just dropping the parent mutex easier.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/