From: Nathan_Lynch@mentor.com (Nathan Lynch)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/PATCH] ARM: vDSO gettimeofday using generic timer architecture
Date: Tue, 28 Jan 2014 15:48:43 -0600 [thread overview]
Message-ID: <52E825BB.6010901@mentor.com> (raw)
In-Reply-To: <20140128212245.GQ15937@n2100.arm.linux.org.uk>
On 01/28/2014 03:22 PM, Russell King - ARM Linux wrote:
> On Tue, Jan 28, 2014 at 03:06:53PM -0600, Nathan Lynch wrote:
>> +static union {
>> + struct vdso_data data;
>> + u8 page[PAGE_SIZE];
>> +} vdso_data_store __page_aligned_data;
>> +struct vdso_data *vdso_data = &vdso_data_store.data;
>
> So this is in the kernel data segment.
>
>> +void update_vsyscall(struct timekeeper *tk)
>> +{
>> + struct timespec xtime_coarse;
>> + struct timespec wall_time = tk_xtime(tk);
>> + struct timespec *wtm = &tk->wall_to_monotonic;
>> + u32 use_syscall = strcmp(tk->clock->name, "arch_sys_counter");
>> +
>> + ++vdso_data->tb_seq_count;
>> + smp_wmb();
>> +
>> + xtime_coarse = __current_kernel_time();
>> + vdso_data->use_syscall = use_syscall;
>> + vdso_data->xtime_coarse_sec = xtime_coarse.tv_sec;
>> + vdso_data->xtime_coarse_nsec = xtime_coarse.tv_nsec;
>> +
>> + if (!use_syscall) {
>> + vdso_data->cs_cycle_last = tk->clock->cycle_last;
>> + vdso_data->xtime_clock_sec = wall_time.tv_sec;
>> + vdso_data->xtime_clock_nsec = wall_time.tv_nsec;
>> + vdso_data->cs_mult = tk->mult;
>> + vdso_data->cs_shift = tk->shift;
>> + vdso_data->wtm_clock_sec = wtm->tv_sec;
>> + vdso_data->wtm_clock_nsec = wtm->tv_nsec;
>> + }
>> +
>> + smp_wmb();
>> + ++vdso_data->tb_seq_count;
>> +}
>> +
>> +void update_vsyscall_tz(void)
>> +{
>> + vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
>> + vdso_data->tz_dsttime = sys_tz.tz_dsttime;
>> +}
>
> which gets written to directly, and read from userspace. This won't work
> with aliasing caches, of which we have VIVT caches on all ARMv4 and ARMv5
> CPUs, and VIPT caches on some ARMv6.
>
> Either this needs to be limited to just VIPT nonaliasing caches, or it
> needs cache handling.
Thanks, I will address this.
>
> The above also looks rather unsafe from the SMP perspective - how does
> vdso_data->tb_seq_count protect this data between CPUs?
It doesn't -- it merely provides a mechanism for signaling the
consistency of the data userspace reads from the page. It's basically a
seqlock.
Looks like timekeeper_lock in kernel/time/timekeeping.c prevents
concurrent calls to update_vsyscall. I could document that dependency...
prev parent reply other threads:[~2014-01-28 21:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 16:25 [RFC] arm: vdso: Convert sigpage to vdso implementation Steve Capper
2014-01-28 17:10 ` Russell King - ARM Linux
2014-01-29 14:22 ` Steve Capper
2014-01-30 18:51 ` Will Deacon
2014-01-28 21:05 ` Nathan Lynch
2014-01-29 14:39 ` Steve Capper
2014-01-28 21:06 ` [RFC/PATCH] ARM: vDSO gettimeofday using generic timer architecture Nathan Lynch
2014-01-28 21:22 ` Russell King - ARM Linux
2014-01-28 21:48 ` Nathan Lynch [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52E825BB.6010901@mentor.com \
--to=nathan_lynch@mentor.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.