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 15:18, <tamas@xxxxxxxxxxxxx> wrote:
> On Fri, Apr 26, 2019 at 7:12 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>
>> >>> 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.
> 
> It's a chicken-and-the-egg problem. It wouldn't be safe without a lock
> to do anything with that structure. Having a caller be able to grab
> the lock but have an understanding that the structure - including the
> lock itself - may be freed is not a feasible route.

But by using RCU the structure can't be freed behind the back of
anyone holding a lock. Parties observing the pointer to become
NULL could still (using a local copy of the pointer) access the
structure (and hence the lock).

> If it was possible
> to do that kind-of coordination then we wouldn't need a lock in the
> first place.

I'm not convinced of this, but I'm also not an RCU specialist, so
there may well be ways of getting things to work that way without
any lock.

Jan



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