Comment # 2
on bug 1062
from Nathan Scott
(In reply to comment #1)
> (A weaker variant of this problem involves the inherent risks of
> lack of concurrency control between an application that asynchronously
> modifies the mmv shmem data, at the same time as the pmda mmv can
Yes, at the time the code was written this class of potential issue was
discussed at length. However (setting asides strings for now), at the
time no realistic issue was able to be found - this isn't my code FWIW,
I was (as you are) in the mindset of trying to find issues... :)
> read it. Even four-byte metric values can get corrupted if an app
> happens to write them byte-by-byte in an unexpected way,
OK - so, in what realistic scenario would that ever happen? (given the
nature of the values we're talking about here & the were they will be
modified in the real world)
I've been unable to come up with any over the years, and have managed to
come to terms with the fact that this scheme works :) ... and in practice
its extremely efficient for the kind of performance data (counters, etc)
we're manipulating.
IOW, its not a general purpose, stick-bytes-anywhere-in-whatever-order
and expect-sensible-results kind of interface ... practical tradeoffs are
made, as always, to gain efficiency for use with actual performance data.
> never mind strings.)
Yes, strings are a different & highly problematic case. However, we must
once again consider reality and how strings are used for performance data
in system-level tools like PCP. The overwhelming (if not exclusive) use
of string metrics is for static data that rarely, if ever, changes. i.e.
things like hardware inventory, versions of application software, etc.
In MMV, this has equated to things like JVM version, the instrumented app
version, and so on. Such things are set once, then never change for the
life of the instrumented application.
There was much discussion about these theoretical aspects many years ago,
in particular around strings with their obvious issues. Guards were put
in place, like fixed-short-length-only string values and I remember lots of
discussion about schemes where strings could be written backwards and all
sorts of funky things like that ... to further minimise the chance of midair
collisions. From a quick look in the userspace library, it looks like just
the simplest approach (strncpy) was taken though.
Ken, if your plate is full atm, I can take a look into adding new offseting
guards into pmdammv early next week (from the original report, which I tend
to agree with Frank, is lacking). I think it'll be easy to provide greater
protection around string updates too (such that only the original value, an
empty string, or a new value is ever visible), from a quick code perusal,
so I might look into that at some point as well.
cheers.