On Fri, Sep 19, 2014 at 8:10 PM, Filipe Brandenburger <filbranden@xxxxxxxxxx> wrote: > Hi Andy, > > On Fri, Sep 19, 2014 at 3:31 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> 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? > > I thought of doing that from the prctl but AFAICT remap_pfn_range > requires that it's unmapped before the call (remap_pte_range has > BUG_ON(!pte_none(*pte));) and doing a zap_page_range followed by > remap_pfn_range might incur a race condition if another thread of the > same process is accessing the vvar page at that time... Am I wrong > about that race? No, you're right. Ugh. It might pay to add an explicit .fault callback to vm_special_mapping, but your approach will work, too. The main downside is more memory overhead per mm. > >> 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. > > No, I'm not planning to change the text, just replacing the vvar page > swapping the one where the vsyscall_gtod_data lives with a zero page > (and back depending on the parameter of the prctl.) Hmm. This will break the _COARSE timing functions as well as __vdso_time. That'll need fixing, either by swapping out the code (yuck!) or by adding a branch to all of those code paths. Maybe there's a non-branchy way, though. Let me think. > >> Maybe better: what exactly are you trying to do? > > Just replace the page mapped to the vvar address. > > But nevermind my ramblings here, looks like you're almost there so go > ahead and when you have a working patch I'll take a look at it. See: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/vma_tracking > > My offer to help still stands, so let me know if you'd like to see > some of my code (unfinished as it is now or if you'd like me to show > you something that works in a few days.) > > Cheers, > Filipe -- Andy Lutomirski AMA Capital Management, LLC -- 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
