Re: FOR REVIEW: New x86-64 vsyscall vgetcpu()

[Andi Kleen <ak at suse dot de>]

On Wednesday 14 June 2006 17:23, Ulrich Drepper wrote:

> 1.  x86-64 should be converted to the regular vDSO format we use for the
> other archs.  These magic addresses are simply unacceptable.  Adding yet
> another one makes things only worse.  Outside glibc nobody should use
> them so it's just one dependency.  We can control via setarch whether 
> the old code is available for an interim period.

I'm not going to break the ABI on this. There are non glibc libcs
and programs that don't use glibc and statically linked program

Eventually we'll need a dynamic format but I'll only add it 
for new calls that actually require it for security.
vgetcpu doesn't need it.

> 
> > long vgetcpu(int *cpu, int *node, unsigned long *tcache)
> 
> Do you expect the value returned in *cpu and*node to require an error
> value?  If not, then why this fascination with signed types?

Shouldn't make a difference.

> And as for the cache: you definitely should use a length parameter.
> We've seen in the past over and over again that implicit length
> requirements sooner or later fail.

No, the cache should be completely opaque to user space. It's just
temporary space for the vsyscall which it cannot store for itself.
I'll probably change it to a struct to make that clearer.

length doesn't make sense for that use.

 
> Maybe this is a more commonly needed requirement for the vdso in
> feature.  In which case it might be adequate to have a new vdso
> functions which returns to total number of bytes needed for caches etc.
>  This could be called while setting up the thread stack.  Then we pass a
> pointer to an approriately sized local memory region to this call and
> others.  The vdso functions will organize among themselves which part of
> the buffer each of them can use.  Internally it would be a struct,
> initially with only the two longs you currently have in mind.

If some other function needs a cache too it can define its own.
I don't see any advantage of using a shared buffer.

> 
> Not doing it this way would mean that for each new vdso function needing
>  TLS memory we would have to modify the very lowlevel TLS structures.
> That's a horrible proposition.

I think you're misunderstanding the concept. The vsyscall doesn't
know anything about about TLS. It just gets a pointer pointing to a fixed
size buffer. How that buffer is provided is left to the caller.
glibc would likely use TLS, but the vsyscall code doesn't care.


-Andi