On 09/03/2017 21:32, Andy Lutomirski wrote: > On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier <thgarnie@xxxxxxxxxx> wrote: > >> --- a/arch/x86/xen/enlighten.c >> +++ b/arch/x86/xen/enlighten.c >> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t, >> >> *shadow = t->tls_array[i]; >> >> - gdt = get_cpu_gdt_table(cpu); >> + gdt = get_cpu_gdt_rw(cpu); >> maddr = arbitrary_virt_to_machine(&gdt[GDT_ENTRY_TLS_MIN+i]); >> mc = __xen_mc_entry(0); > Boris, is this right? I don't see why it wouldn't be, but Xen is special. Under Xen PV, the GDT is already read-only at this point. (It is not safe to let the guest have writeable access to system tables, so the guest must relinquish write access to the frames wishing to be used as LDTs or GDTs.) The hypercall acts on the frame, not a virtual address, so either alias should be fine here. Under this new scheme, there will be two read-only aliases. I guess this is easier to maintain the split consistently across Linux, than to special case Xen PV because it doesn't need the second alias. ~Andrew -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>