LTTng » LTTng-UST

I just noticed something quite unpleasant: if we link a probe provider built against lttng-ust 2.1 with a liblttng-ust 2.0, the application may access beyond structure allocation size when traced.

Here is a bit of background explaining this:

1) we want to ensure drop-in compatibility for old applications with newer liblttng-ust versions. Therefore, for 2.0 and 2.1, we chose to leave the soname version at 0.0.0, which means an application (and probe provider) compiled against lttng-ust 2.0 can link to lttng-ust 2.1 without being recompiled.
2) we made sure, in the ABI, to only extend the data structures used within the probe providers. We never shrink them, never remove nor change any of their fields. This means that a 2.0 probe provider can run with a 2.1 liblttng-ust flawlessly: it will just use the fields it knows about.
3) what we failed to consider though was this use-case: if a probe provider is built against lttng-ust 2.1, and linked against an old liblttng-ust 2.0, the probe provider may access 2.1 fields that were not present in 2.0. Since liblttng-ust allocates the memory that contains those structures, this is an out-of-bound access.

So I guess for 2.0 and 2.1, there is not much we can do other than document the limitation (anyone has a better idea ?).

Now the real question is: what should we do to handle this kind of change in the future ?

One possibility would be to ensure the probe provider advertize the lttng-ust version it has been built against, adding a new lttng_probe_register_version() for this. However, this would require to break compatibility between 2.1 and 2.2, which I very much want to avoid.

Another possibility would be to use padding fields in struct lttng_probe_desc to advertize the version. 2.0 and 2.1 would advertize as 0.0 (major.minor probe provider ABI version). The compatibility mapping would be based on the minor version: a new lttng-ust is compatible with older probes, but older lttng-ust are incompatible with newer probes (and therefore their registration is refused). If we ever need to completely break compatibility, the major would be bumped.

Thoughts ?

Thanks,

Mathieu