[RFC] logdev debugging memory device for tough to debug areas

[Ingo Molnar]

I've created a tracing tool several years ago for my master's thesis
against the 2.2 kernel and onto the 2.4 kernel. I'm currently using
this in the 2.6 kernel to debug some customizations against Ingo's RT
kernel.

neat. It seems there's some overlap with relayfs, which is in -mm
currently:

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/broken-out/relayfs.patch

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Steven Rostedt]

Post by Ingo Molnar

I've created a tracing tool several years ago for my master's thesis
against the 2.2 kernel and onto the 2.4 kernel. I'm currently using
this in the 2.6 kernel to debug some customizations against Ingo's RT
kernel.

neat. It seems there's some overlap with relayfs, which is in -mm
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/broken-out/relayfs.patch

Thanks Ingo, I didn't know about this. I'll look into it further when I
have more time, and maybe my tools already implement things that need to
be done in here, and I can port them (if they're interested). I first
wrote this back in 1998 or 1999 and have added on since then. So it is
pretty mature. Unfortunately I still had to clean it up for the post. It
was only for my personal use till someone mentioned to me that I should
share it.

Also, I'm almost done adding the pending owner work against .41-11. I
see you now have 41-13, and if you already implemented it, let me know.
I've been fighting your deadlock detection to make sure it works with
the changes. Then finally I found a race condition that I'm solving.

To have a task take back the ownership, I had the stealer call
task_blocks_on_lock on the task that it stole it from. To get this to
work, when a task is given the pending ownership, it doesn't NULL the
blocked_on at that point (although the waiter->task is set to NULL). But
this gives the race condition in pi_setprio where it checks for
p->blocked_on still exists. Reason is that I don't want the waking up of
a process to call any more locks. To solve this, I had to (and this is
what I don't like right now) add another flag for the process called
PF_BLOCKED. So that this can tell the pi_setprio when to stop. This flag
is set in task_blocks_on_lock and cleared in pick_new_owner where the
setting of blocked_on to NULL use to be.

Unless you already implemented this, I'll have a patch for you to look
at later today, and you can then (if you want) critique it :-)

-- Steve

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Steven Rostedt]

Post by Steven Rostedt
To have a task take back the ownership, I had the stealer call
task_blocks_on_lock on the task that it stole it from. To get this to
work, when a task is given the pending ownership, it doesn't NULL the
blocked_on at that point (although the waiter->task is set to NULL).
But this gives the race condition in pi_setprio where it checks for
p->blocked_on still exists. Reason is that I don't want the waking up
of a process to call any more locks. To solve this, I had to (and this
is what I don't like right now) add another flag for the process
called PF_BLOCKED. So that this can tell the pi_setprio when to stop.
This flag is set in task_blocks_on_lock and cleared in pick_new_owner
where the setting of blocked_on to NULL use to be.

which locks are affected? I'd prefer the simplest solution. If there's
more overhead with deadlock detection (which is a debugging feature),
that doesnt matter much.

I've already covered the deadlock detection problems, and that didn't
add anymore overhead. That was just what kept breaking every time I
changed something ;-)

The overhead is caused by the pi_setprio knowing when to stop following
the chain of blocked processes. Since it can't check for p->blocked_on
== NULL anymore. I first had it check that or p->flags & PF_PENDOWNER,
but since the process waking up can happen at anytime without grabbing
any lock, this flag can be cleared as well as the blocked_on at the time
of this test. So I added another flag to p->flags to tell when the
process is locked and not pending ownership. I don't know yet if this
works, I have to run to an appointment now and I'll find out when I get
back.

Oh, and I disabled the deadlock check on the stolen case. So when a
pending owner goes back to blocked, right now it doesn't check the
deadlock, since the code uses current as the test, and that no longer
applies. So for now I have a test in task_blocks_on_lock to see if task
== current otherwise, don't check for deadlocks.

-- Steve

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Ingo Molnar]

Post by Steven Rostedt
Also, I'm almost done adding the pending owner work against .41-11. I
see you now have 41-13, and if you already implemented it, let me
know. [...]

nope, i havent touched that area of code, knowing that you are working
on it.

Post by Steven Rostedt
[...] I've been fighting your deadlock detection to make sure it works
with the changes. Then finally I found a race condition that I'm
solving.

great - just send it along when you have it.

Post by Steven Rostedt
To have a task take back the ownership, I had the stealer call
task_blocks_on_lock on the task that it stole it from. To get this to
work, when a task is given the pending ownership, it doesn't NULL the
blocked_on at that point (although the waiter->task is set to NULL).
But this gives the race condition in pi_setprio where it checks for
p->blocked_on still exists. Reason is that I don't want the waking up
of a process to call any more locks. To solve this, I had to (and this
is what I don't like right now) add another flag for the process
called PF_BLOCKED. So that this can tell the pi_setprio when to stop.
This flag is set in task_blocks_on_lock and cleared in pick_new_owner
where the setting of blocked_on to NULL use to be.

which locks are affected? I'd prefer the simplest solution. If there's
more overhead with deadlock detection (which is a debugging feature),
that doesnt matter much.

Post by Steven Rostedt
Unless you already implemented this, I'll have a patch for you to look
at later today, and you can then (if you want) critique it :-)

sure.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------