Re: [Xen-devel] [PATCH] [FOR 4.2] tmem: add matching unlock for an about-to-be-destroyed object

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.08.12 at 21:58, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> A 4.2 changeset forces a preempt_disable/enable with
> 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 soon after any object is
> destroyed.
> 
> So force lock to be released before destroying objects.

We had noticed this oddity during XSA-15 processing too.
What's the purpose of holding a lock on a to be destroyed
object anyway? One would expect a lock of a containing
entity to be held for that purpose (or really just while
taking the object off whatever data structure it can be
looked up through), which would eliminate the need for
locking the object itself. That lock generally appears to be
pool_rwlock, but in several places that one gets acquired
_after_ checking pgp_count to be zero - how is it being
guaranteed that this count doesn't increase between the
check and the lock being acquired?

Jan


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