linux-kernel - Re: sparc64: Optimized immediate value implementation build error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20081014.120215.101891203.davem@davemloft.net>
Date:	Tue, 14 Oct 2008 12:02:15 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mathieu.desnoyers@...ymtl.ca
Cc:	linux-kernel@...r.kernel.org
Subject: Re: sparc64: Optimized immediate value implementation build error

From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Date: Tue, 14 Oct 2008 12:08:48 -0400

> * David Miller (davem@...emloft.net) wrote:
> > On the other hand, CONFIG_PSRWLOCK_LATENCY_TEST fails to build:
> > 
> >   CC      lib/psrwlock-latency-trace.o
> > lib/psrwlock-latency-trace.c: In function ‘calibrate_get_cycles’:
> > lib/psrwlock-latency-trace.c:60: error: implicit declaration of function ‘rdtsc_barrier’
> > 
> > You could use sched_clock() or similar, we do have portable
> > interfaces by which to do these things.  And if we don't
> > have something fitting exactly what is needed here, add it :-)
> > 
> 
> I think the %tick register we get with get_cycles() on sparc64 is what
> is needed. Hopefully it's synchronized across CPUs on SMP systems ?

Yes, it is synchronized.

> On x86_64, rdtsc_barrier() issues a synchronizing instruction (cpuid)
> which serializes the instructions executed on the CPU so we do not
> execute rdtsc speculatively. Is reading %tick synchronized on sparc64 or
> not ?

It is synchronized on sparc64.

> Is there a similar %tick register on sparc32 ? I've read somewhere it's
> new to sparc v8. (http://cr.yp.to/hardware/sparc.html) So I guess we
> should simply disable this psrwlock latency tracer on SPARC32 ?

Not really.  There is only the time keeping device out in I/O space
which is very expensive to access.

This is why we don't have a sched_clock() implementation on sparc32.

> Probably that the best way to deal with this is to create a 
> 
> (generic code)
> HAVE_GET_CYCLES
>   def_bool n
> 
> (sparc, x86, powerpc... Kconfig)
> config SPARC64/X86/POWERPC
>   select HAVE_GET_CYCLES
> 
> And we can make CONFIG_PSRWLOCK_LATENCY_TEST depend on HAVE_GET_CYCLES.

Yes, something like that.

> > Also:
> > 
> > <stdin>:1421:2: warning: #warning syscall marker not implemented
> > <stdin>:1425:2: warning: #warning syscall trace not implemented
> > 
> > which should be fixed by the following patch:
> > 
> > sparc: Add sys_trace() and sys_marker() syscall table entries.
> > 
> 
> Thanks, I'll merge it :) I don't expect the userspace tracing to be in
> its final form, but it's good to add such support.

I think so too :)