On Fri, Apr 26, 2019 at 7:12 AM Jan Beulich <jbeul...@suse.com> wrote: > > >>> On 26.04.19 at 14:24, <ta...@tklengyel.com> wrote: > > On Fri, Apr 26, 2019 at 3:24 AM Jan Beulich <jbeul...@suse.com> wrote: > >> > >> >>> On 26.04.19 at 02:12, <ta...@tklengyel.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
