This commit adds zero-initializations by changing `SFL_ALLOC` from
`malloc` to `xzalloc`, adding a `memset` call to `sflAlloc`,
initializing a `pollfd` struct variable with zeroes, and changing some
calls to `xmalloc` to `xzalloc`. This is to prevent potential data leaks
or undefined behavior from potentially uninitialized variables.
Some variables would always be initialized by either the code flow or
the compiler. Thus, some of the associated Coverity reports might be
false positives. That said, it is still considered best practice to
zero-initialize variables upfront just in case to ensure the overall
resilience and security of OVS, as long as they do not impact
performance-critical code. As a bonus, it would also make static
analyzer tools, such as Coverity, happy.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: James Raphael Tiovalen <jamestiotio@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Several 'sflow' functions (sfl_poller_tick, sfl_sampler_tick, and
sfl_receiver_tick) have unused parameter 'now' in their signatures. This patch
removes that parameter from their signatures to fix compilation warnings.
Also, according to the 'utilities/checkpatch.py', there should be an indent
between 'for' keyword an opening left paren. Additionally, the line containing
'for' keyword had to end with an opening curly brace. Therefore, I did a bit of
formatting besides removing the unused parameter in the modified code.
Signed-off-by: Sergey Madaminov <sergey.madaminov@gmail.com>
Reviewed-by: Michael Santana <msantana@redhat.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch changes the order of the steps that are followed
every second in the sFlow agent. By moving the receiver_tick()
step to the end, we ensure that any counters that were polled
during the poller_tick() step are flushed immediately to the
sFlow collector. This eliminates what was a variable time-delay
between counters being polled and being flushed.
The variable time-delay that this eliminates could be up to
a second because counters lingering in the output buffer could be
flushed at any time by the arrival of random packet-samples.
Since the sFlow standard does not require that a poll-timestamp be sent
along with the counters the collector must use his receive-time as the
timestamp, so that extra second of variable delay was "stretching or
shrinking" the time between successive counter readings. This
affected any counter-rate calculation that was based only on the delta
between sucessive samples. The effect was small with a polling
interval of 60 seconds: just +/- 2%. But the effect grew larger
when faster polling was configured. For example, if the counters
were pushed every 5 seconds then the instantaneous rate
calculations could wander by +/- 20%. For a thorough analysis
of this problem, see Rick Jones' paper:
"High Frequency sFlow v5 Counter Sampling"
ftp://ftp.netperf.org/papers/high_freq_sflow/hf_sflow_counters.pdf
So this patch makes it possible to obtain usable results even
when high-frequency polling is configured.
Signed-off-by: Neil McKee <neil.mckee@inmon.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Export standard sFlow LAG, PORTNAME and OPENFLOWPORT structures with each
counter-sample. Add unit-test for sFlow-LAG. Adjust other unit-tests to
accommodate these new annotations.
The sFlow-LAG structures are important for topology discovery, for
troubleshooting LAG instability, and for correctly combining
sFlow feeds from multiple sources.
The OPENFLOWPORT and PORTNAME structures are important for systems that
aim to combine sFlow monitoring with OpenFlow controls, as they
provide straightforward mapping (1) between sFlow agent IP and OpenFlow
datapath-id, and (2) between interface name,ifIndex and OpenFlow
port number.
Signed-off-by: Neil McKee <neil.mckee@inmon.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
These functions use sprintf() into a 1000-byte buffer. It appears to me
that the strings they format are either short, fixed-length strings or the
output of strerror(), neither of which should ordinarily overflow.
However, using snprintf() cannot hurt.
Launchpad bug #914160.
Reported-by: Matthias Klose <doko@ubuntu.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The sFlow License was not on the list for the Fedora Project, but the
Sun Industry Standards Source License 1.1 was (and it has the right
properties). So this patch includes it as a licensing option in the
relevant places (COPYING and the lib/sflow* sources). Let me know
if this looks OK or not.
Signed-off-by: Neil McKee <neil.mckee@inmon.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
The C source and header files added in this commit is covered under the
InMon sFlow license at http://www.inmon.com/technology/sflowlicense.txt
The library requires -Wno-unused to compile without warnings, so this
commit adds that for building the sFlow code only. Automake can only
change compiler flags on a per-library or per-program basis, so sFlow
is built as a separate library.
The library will be used in upcoming commits.
