lkml.org 
[lkml]   [2008]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 16/22 -v2] add get_monotonic_cycles

    >
    > Crazy ideas :
    >
    > Could we do something along the lines of the thread local storage ?
    >
    > Or could we map a per-thread page that would contradict this
    > "definition" ?

    When working on lguest64, I implemented a "per CPU" shadow page. That the
    process of a guest running on one real CPU, could never see this page for
    a process of the same guest running on another real CPU.

    This is a nightmare to manage. The thing is that threads share the same
    pgd. With shadow pages, it's doable, but hard to manage. It required
    making a "copy" of the pgd for each real CPU.

    Here we are not talking about guests, but bare-metal. So this complicates
    things even more. The problem is that each thread shares the same pgd. If
    two threads run on the same time on two different CPUS, then the two
    threads would see the same counter. But we need to make this per cpu.

    Now if the thread was given a clue to what CPU it was running on, then we
    might be able to accomplish something. But then we have the same issue.
    How do you tell a thread what CPU it's on, without running into the same
    issues as where to store this data?

    -- Steve

    >
    > Or can we move down the beginning of the user-space thread stack of 4
    > bytes (it's already put at a random address anyway) and use these 32
    > bits to put our variable ? We don't care if userspace also modifies it;
    > the kernel would blindly increment it, so there would be no security
    > concerns involved.



    \
     
     \ /
      Last update: 2008-01-17 16:25    [W:2.913 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site