Messages in this thread | | | From | Bjorn Helgaas <> | Subject | Re: Who owns those locks ? | Date | Mon, 7 Jun 2004 09:06:54 -0600 |
| |
On Monday 07 June 2004 2:58 am, Zoltan Menyhart wrote: > Bjorn Helgaas wrote: > > On Wednesday 12 May 2004 3:56 am, Zoltan Menyhart wrote: > > > Got a dead lock ? > > > No idea how you got there ? > > > > > > Why don't you put the ID of the owner of the lock in the lock word ? > > > Here is your patch for IA-64. > > > Doesn't cost any additional instruction, you can have it in your > > > "production" kernel, too. > > > > Whatever happened with this patch? I really like the idea, but > > it seems like it died on the vine. Maybe it's time to clean it > > up, pull all the bits together, and repost it. > > Here you are. > (I'm still playing with 2.6.5)
There are a couple issues I was thinking of when I wrote "clean it up, pull the bits together...":
1) Tony Luck's question about what happens when "shr.u r30 = r13, 12" yields zero in the 32-bit lock value. I'm not the 2.6 maintainer, but I'd sure like to see some solution for this. It would be a nightmare to debug a system where one random task didn't release locks correctly. Since other arches use a trick like this, I'm hoping they've figured out something we can copy (I haven't looked).
2) A nit-pick, but for things like this:
- " mov r30 = 1;;\n\t" + /* " mov r30 = 1;;\n\t" */ + " shr.u r30 = r13, 12;;\n\t" /* Current task pointer */
just remove the old line, don't comment it out.
Thanks for collecting the bits. I looked at it last week, got derailed trying to figure out how the pre-gcc-3.3 lock contention code worked (a comment there would have been helpful), and got distracted. - 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/
| |