On Fri, Sep 19, 2014 at 3:19 PM, Filipe Brandenburger <filbranden@xxxxxxxxxx> wrote: > Hi, > > On Fri, Sep 19, 2014 at 3:09 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Fri, Sep 19, 2014 at 3:02 PM, Filipe Brandenburger <filbranden@xxxxxxxxxx> wrote: >>> In case that's useful, I was looking at swapping the vvar page by >>> changing the vm_special_mapping to change the pages array between the >>> actual vvar page and the zero page and using zap_page_range to force >>> the next access to go through a page fault that would remap it. >> >> That will do it globally, since the vm_special_mapping is global. I >> was just thinking of using remap_pfn_range. > > Sorry if I wasn't clear... That's the exact point of my patch, to make > vm_special_mapping local to the task. > > I started with an approach of keeping a struct vm_special_mapping + a > struct page * array per mm_struct. > > I was also looking at keeping two static vm_special_mapping structs, > one with the actual vvar page and the other with the zero page and > then swapping vma->vm_private_data to point to the appropriate one. This sounds like it may be more complicated than necessary. Is there any reason that just doing remap_pfn_range on the vvar page isn't enough? Changing out the text is a whole can of worms involving self-modifying code, although it may be completely safe if done through the page tables. But I don't think you can't use remap_pfn_range for that. > >> Give me another day or two to straighten out the vma stuff, although >> it shouldn't impact your patches too much. The main effect will be >> that you'll be able to rely on mm->context.vdso (renamed to >> vvar_vma_start, most likey) being correct. Currently, you should >> *not* rely on it, especially if CRIU is involved. > > Cool! As I said, let me know if you'd like to see some of my > incomplete patches or if you'd like me to keep working on them to show > you something more complete. Maybe better: what exactly are you trying to do? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
