Messages in this thread | | | Date | Tue, 29 Mar 2005 13:56:56 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC] logdev debugging memory device for tough to debug areas |
| |
* Steven Rostedt <rostedt@goodmis.org> 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 :-)
sure.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |