[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] logdev debugging memory device for tough to debug areas

* Steven Rostedt <> wrote:

> 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.

> [...] 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.

> 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.

> 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 :-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.027 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site