Re: Should Linux VDSO be using symbol version based on the released kernel?

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 04/05/2016 19:04, Mike Frysinger wrote:
> On 04 May 2016 15:22, Adhemerval Zanella wrote:
>> On 04/05/2016 13:37, Carlos O'Donell wrote:
>>> The Linux VDSO uses a singular version string, different by
>>> architecture, for all VDSO symbols e.g. LINUX_2.6.29 for s390x.
>>>
>>> Should the Linux kernel be using LINUX_4.5 as the version string
>>> for new VDSO symbols added in LINUX_4.5?
>>>
>>> That way we can talk sensibly about what VDSO symbols were added
>>> upstream, and talk sensible about the ABI/API being exported by
>>> any given kernel via the VDSO?
>>>
>>> Right now the version is really only meaningless version for
>>> future compat support.
>>
>> Ideally I would say yes, however the way we use the vDSO is not
>> by exporting it directly in GLIBC own supported versions, but 
>> rather through wrappers and these already take care of check if
>> the symbol exist based on exported kernel version.
> 
> logically it seems like the version symbol should match the version of
> the kernel where it first showed up, but practically speaking i don't
> think it matters.
> 
>> And I do not think we should think the vDSO as an stable ABI
>> that we must enforce symbol version compatibility, but rather
>> helper functions that GLIBC would use internally.
> 
> err, it should be a stable ABI in the sense that the func cannot break
> behavior.  e.g. __vdso_getcpu@@LINUX_2.6 must behave the same way it
> always has.  if you want to change the func API, then add a new symbol
> version e.g. __vdso_getcpu@@LINUX_4.5.
> 
>> It is the same rationale based on other Linux exported facilities
>> that we do support directly.
> 
> yes, the vDSO should be held to the same Linux stable ABI guarantees
> as syscalls or /proc or /sys interfaces.  if code is using it (like
> glibc), then it cannot be broken.  that includes dropping symbols if
> userspace is making assumptions about its existence.  this might not
> be a common issue with any one symbol since the ELF symbol versioning
> has set up an expectation that userspace should check before using,
> but since glibc has been dropping support for older kernels, it isn't
> unreasonable for us to start blindly assuming for some arches/kernel
> versions that (1) the vDSO always exists and (2) it always provides
> certain functions.
> -mike

I was considering the GLIBC position on the enforcing the version compatibility
and I also assume Linus' mantra 'we do not break userspace!'.  Off course
if a vDSO symbol change its semantic it also should change either its name or
versioning. And I see this will be flag intermediately as kernel issue and 
fixed as such.  Same thing for adding or symbol removing.

My view is for matter of fact, the symbol version itself for a given vDSO
matter little to GLIBC.  I think we can stir some discussion and ask the 
kernel developer to enforce the version tied more strictly for future
version.