Re: [Xen-devel] [PATCH 2/3] x86/mem_sharing: replace use of page_lock/unlock with our own lock

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.04.19 at 14:24, <tamas@xxxxxxxxxxxxx> wrote:
> On Fri, Apr 26, 2019 at 3:24 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>
>> >>> On 26.04.19 at 02:12, <tamas@xxxxxxxxxxxxx> wrote:
>> > I would be OK with putting the whole thing behind
>> > CONFIG_HAS_MEM_SHARING and having that be off by default. Is that a
>> > feasible route from your POV?
>>
>> So is there anything wrong with my earlier suggestion of
>> re-purposing the sharing field to attach a structure to the page
>> which contains the necessary lock? I.e. in the simplest case by
>> adding the lock to struct page_sharing_info itself?
> 
> Yes, that won't work unfortunately. The lock is supposed to protect
> updates made to the structure but also freeing it. If the lock lives
> within the structure it obviously would have to be unlocked before its
> freed, but if its unlocked before freed then another thread waiting on
> it could continue without realizing it is being freed.

Can't you RCU-free the structure instead, after detaching it from
the main struct page_info instance? Of course all involved parties
then need to be aware that once they've acquired the lock, the
pointer in struct page_info may have become NULL, which
presumably would direct them to drop the lock again right away.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel