Re: Who owns those locks ?

[Bjorn Helgaas]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/