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 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.

>
> As to your question above - that would be another option, of
> course with the config option getting its HAS_ part dropped.
> Possibly it could then even default to enabled when BIGMEM=y.
> But you realize that by going this route you further increase
> the risk of changes elsewhere breaking mem-sharing without
> anyone noticing right away?

I do realize that but considering how much breakage happened to
memsharing with it enabled, I don't think it makes much difference.
Without having any tests in the CI system the compile-testing itself
is not sufficient.

Tamas

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