lkml.org 
[lkml]   [2014]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
On Fri, Sep 19, 2014 at 8:10 PM, Filipe Brandenburger
<filbranden@google.com> wrote:
> Hi Andy,
>
> On Fri, Sep 19, 2014 at 3:31 PM, Andy Lutomirski <luto@amacapital.net> 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


\
 
 \ /
  Last update: 2014-09-20 05:41    [W:0.074 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site