From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755663Ab0JDMlk (ORCPT ); Mon, 4 Oct 2010 08:41:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21228 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755226Ab0JDMlj (ORCPT ); Mon, 4 Oct 2010 08:41:39 -0400 Date: Mon, 4 Oct 2010 09:40:59 -0300 From: Glauber Costa To: john stultz Cc: linux-kernel@vger.kernel.org, avi@redhat.com, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra Subject: Re: [PATCH] use a stable clock reference in vdso vgetns Message-ID: <20101004124059.GD1230@mothafucka.localdomain> References: <1285938596-2186-1-git-send-email-glommer@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ChuckNorris: True User-Agent: Jack Bauer Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 01, 2010 at 10:49:53AM -0700, john stultz wrote: > On Fri, Oct 1, 2010 at 6:09 AM, Glauber Costa wrote: > > When using vdso services for clock_gettime, we test for the ability > > of a fine-grained measurement through the existance of a vread() function. > > > > However, from the time we test it, to the time we use it, vread() reference > > may not be valid anymore. It happens, for example, when we change the current > > clocksource from one that provides vread (say tsc) to one that lacks it > > (say acpi_pm), in the middle of clock_gettime routine. > > > > seqlock does not really protect us, since readers here won't stop the writers > > to change references. The proposed solution is to grab a copy of the clock > > structure early, and use it as a stable reference onwards. > > Ah. Good find! The fix looks reasonable to me. However, its likely the > similar code in arch/x86/kernel/vsyscall_64.c will need a similar fix. > > Awhile back there was some motivation to merge the two vdso/vsyscall > implementations to avoid the duplication, but my memory is failing on > why that didn't happen. I feel like it had to do with complication > with the way the two implementations are mapped out to userland. Even > so, it seems a shared forced inline method would resolve the issue, so > maybe it just fell off the todo list? Actually vsyscall updates seem to be covered by update_vsyscall() already. I tried hard and can't reproduce this behaviour. Now that I am thinking, maybe we could come up something similar to vsyscall? If we start by making vsyscall data point to the same object, we may get it for free. Or am I missing something ?