[Xen-devel] preemption and locking: why joined at the hip?

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Tracking down a tmem problem in 4.2.0-rcN that crashes the
hypervisor, I've discovered a 4.2 changeset that forces
a preemption_enable/disable for every lock/unlock.

Tmem has dynamically allocated "objects" that contain a
lock.  The lock is held when the object is destroyed.
No reason to unlock something that's about to be destroyed.
But with the preempt_enable/disable in the generic locking code,
and the fact that do_softirq ASSERTs that preempt_count
must be zero, a crash occurs.

While I'm suitably embarrassed that tmem has not yet
been tested with any recent -unstable, and I note that the
workaround is simple (forcing an unlock before destroying the
object containing the held lock), I have to ask if
this change is really a good idea or is it unnecessary
babysitting?

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel