Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load

[Andy Lutomirski]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/