Re: [patch 2.6.9] Avoid a rare deadlock during unwind

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Fri, 22 Oct 2004 00:44:35 +1000, Keith Owens <kaos@sgi.com> said:

  Keith> Emprically it works.  The patched code has been hammered
  Keith> several million times, using modifying oprofile code that
  Keith> generates gprof backtraces whenever the profile interrupt
  Keith> pops.  That was the code that found the original deadlock in
  Keith> unwind.

Yes, that's certainly a good way to test.

  Keith> o if both the unw.lock spinlock and a script's read-write lock must be
  Keith> acquired using a method that might sleep, then the read-write lock
  Keith> must be acquired first.

  Keith> adding "using a method that might sleep".  The only read-write lock
  Keith> code under spinlock(unw.lock) is write_trylock(), which never sleeps.
  Keith> If you agree with this analysis, then I am happy to update the comment.

No, the comment was intending to establish the lock hierarchy.  If there
are no other paths where the locks are acquire in the other order, then
it's OK.  I'd just reverse the comment to match the (new) reality.

	--david