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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Fri, Apr 26, 2019 at 8:47 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> >>> 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.

Perhaps, but that's also way beyond what I have bandwidth at this time
to investigate.

Tamas

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