Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/roundingissue in timekeeping core

[Andy Lutomirski]

On Wed, Sep 19, 2012 at 10:54 AM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> On 09/19/2012 10:03 AM, Richard Cochran wrote:
>>
>> On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
>>>
>>> With powerpc, there is no arch specific kernel code involved, its
>>> just a data structure the kernel exports that is accessible to
>>> userland. The execution logic lives in userland libraries, or
>>> sometimes application code itself.
>>
>> I took a brief look at arch/powerpc/kernel/vdso32/gettimeofday.S and
>> arch/powerpc/kernel/vdso64/gettimeofday.S, and I see what looks a lot
>> like functions
>
> Sorry, yes. My statement wasn't subtle enough (and I may be confusing my
> history).
>
> You are right, there is arch specific code involved, but the data structure
> that is exported is considered part of the abi since some applications
> access it directly.
>
> See the comments and structure in:
> arch/powerpc/include/asm/vdso_datapage.h
>
>
>
>> $ find arch/powerpc/kernel/vdso* -name gettimeofday.S|xargs grep
>> FUNCTION_BEGIN
>>
>>
>> arch/powerpc/kernel/vdso32/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_gettimeofday)
>>
>> arch/powerpc/kernel/vdso32/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_gettime)
>>
>> arch/powerpc/kernel/vdso32/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_getres)
>>
>> arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_gettimeofday)
>>
>> arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_gettime)
>>
>> arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_getres)
>> arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__do_get_tspec)
>>
>> and I wonder whether these could be done in C instead.
>
>
> Possibly, but I suspect they're in asm for performance reasons.
>
> Paul/Ben: Do you have any thoughts here?
>

Does anything except the vDSO actually use the vDSO data page?  It's
mapped as part of the vDSO image (i.e. at a non-constant address), and
it's not immediate obvious how userspace would locate that page.

FWIW, this is kind of cute and is not obviously worse than the way
that x86-64 does it, other than the possible ABI issue.
Pros:
 - vDSO code could use RIP-relative addressing instead of absolute
addressing, although I'm not sure whether there's actually a RIP +
16-bit offset encoding, so this might not be a win
 - Avoids a read-only page at a constant address
 - The mapping is per-process, so evil tricks could be used to shove,
say, pid in there.  This is almost certainly not worth it, especially
given the odd things that clone can do and that glibc already ought to
cache the pid.
Cons:
 - If ptrace or mprotect pokes that page, the clock stops for that process.
 - Lots of complexity for minimal gain.

In any case, it looks like #define VVAR(x) vdso_data->x would work on
ppc, although the vvar specification mechanism would not work.

--Andy
--
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/