When libraries add their own -march flags to CFLAGS, let them.
But if -march=native should be added (it should by default),
add it as the last -march flag to "win".
This ensures, that even if a library brings their own minimal -march,
it will not downgrade the instruction set for the whole Suricata.
This happened with DPDK which, when enabled, downgraded the instruction
set to -march=corei7 or -march=haswell.
When building packages with --disable-gccmarch-native, the instruction set
is auto-upgraded to instruction set requested by libraries.
E.g. from RPM builds: `CFLAGS="-march=x86_64" ./configure --enable-dpdk`
upgrades instruction set to DPDK's corei7 architecture.
Ticket: 8169
When mempool size was configured really low (<32), Suricata exhausted
the mempool with the rx_burst call, which led to undefined behavior.
The current fix ensures the burst size is at most the size of the mempool,
if the mempool is smaller than BURST_SIZE macro.
Based on review it seems p->proto should always be set to the same
value as what `PacketGetIPProto` returns. Add a check to validate
in a decoder that the fuzzer executes.
Move the locking mechanism outside of the getter function and hold the
lock until the reference string is no longer reused.
** CID 1682023: Concurrent data access violations (MISSING_LOCK)
/src/util-mpm-hs-cache.c: 139 in HSGetReferenceDbInfo()
This run-mode does not allow for capture ThreadVars to be created at
the appropriate place in the application life cycle. Instead,
applications should register their own custom run-mode.
Ticket: #8259
To prep for the removal of the lib runmode, simplify this C++ example
to match our simple example. We don't yet have the C++ compatible
headers to allow for a C++ app to register its own custom runmode.
Debug validation revealed that library ThreadVars were being
created *after* the threads were sealed. And the only way to create
your ThreadVars that fits within the current application life-cycle is
to create them in your own custom run mode.
This is likely a better model for users who are bringing their own
packets and threads anyways, as they are essentially providing their
own capture method, and all capture methods provide their own run
mode. They're also using their own threads, which means adapting to
their own threading model.
This is suitable for a backport to 8.0. But for 9.0 we can go further
and remove the built-in library run mode, which will be done in a
follow-up commit.
Ticket: #8259
After the distcheck, this build doesn't need unittests, so add
debug-validation, as this can trigger assertions in our lib examples
that are tested in this job
This triggers a debug-validation error in the custom library example.
Ticket: #8259
If the key `app-layer.protocols.PROTO.enabled` is present, the protocol
is enabled for all carrier protocols. This is not ideal.
Only if the key `app-layer.protocols.PROTO.enabled` is missing, an
attempt is made to look for a setting specific to the ipproto passed
at the time of registration e.g.
`app-layer.protocols.PROTO.udp.enabled`.
By default, check for carrier proto specific setting. If it is not
found, then fall back to the generic setting.
Issue a warning in case an inconsistent combination of global and
ipproto specific setting is found.
Bug 8205
Philippe Antoine
Jason Ish
Lukas Sismis
Lukas Sismis
Victor Julien
Antoine Abou Faysal
Giuseppe Longo
Shivani Bhardwaj
Jeff Lucovsky
dependabot[bot]