[PATCH] arm64: vdso: minor ABI fix for clock_getres

[will.deacon@arm.com (Will Deacon)]

On Wed, Feb 25, 2015 at 04:14:19PM +0000, Nathan Lynch wrote:
> On 02/25/2015 10:02 AM, Will Deacon wrote:
> > On Tue, Feb 24, 2015 at 11:21:07PM +0000, Nathan Lynch wrote:
> >> The vdso implementation of clock_getres currently returns 0 (success)
> >> whenever a null timespec is provided by the caller, regardless of the
> >> clock id supplied.
> >>
> >> This behavior is incorrect.  It should fall back to syscall when an
> >> unrecognized clock id is passed, even when the timespec argument is
> >> null.  This ensures that clock_getres always returns an error for
> >> invalid clock ids.
> >>
> >> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
> >> ---
> >>  arch/arm64/kernel/vdso/gettimeofday.S | 3 +--
> >>  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > 
> > Thanks, Nathan.
> 
> Thank you.  I'm curious -- do you know of a use case for the VDSO
> implementation of clock_getres?  I.e. what kind of real-world workload
> sees a benefit from it?

No, I just implemented it for completeness (and it's also way simpler than
the other functions!). Calling it with a NULL timespec is probably even
less common, so an alternative to your patch would be changing the label
of the existing cbz to hand-off to the kernel when the thing is NULL.

> I'm not suggesting removing it from the arm64 vdso, but I'm considering
> dropping clock_getres from the 32-bit ARM vdso patch set since I haven't
> been able to answer this.

Well, if there aren't any fastpath users then I'm not bothered about
removing it from arm64 either. I'm not sure how we establish that, though.

Will