[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Tamas

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.