When reading a pcap, packet time can move much faster than wall
clock time. This would trigger many more profile syncs than before.
As the sync is using a lock to synchronize with other threads, this
is an expensive operation.
Bug: #6619.
Fixes: b591813b86 ("profiling/rules: reduce sync logic scope")
If a commit introduces code that changes Suricata behavior, the related
documentation changes should go in a separate commit, but refer to the
same ticket number.
This reduces the chances of said changes being lost if there are backports
while still keeping the backporting process a bit less bulky, for each
commit.
Related to
Task #6568
This section seemed to aim both at PR reviewers and PR authors at the
same time, even though some info is probably of low value for
contributors.
Created new section for PR reviewers and maintainers, and kept the info
for PR authors separated. Also highlighted information on requested
changes and stale PRs.
This could be justified from a semantic point of view, and also can help
in bringing more attention to where this information is, as it is less
hidden, now.
Also add Dev Guide as one of our resources in our Readme.
During the pre-scan for "requires", also parse the SID if possible. If
the rule fails high level parsing (syntax), the SID will not be
parsed.
But every keyword other than "sid" and "requires" should expect to be
provided with a parsed sid.
Add a "pre-scan" rule parse that will check for requires statement. It
will return a special error code (-4) if the requires fails due to
missing requirements.
Syntactic errors will also abort parsing here.
Feature: #5972
Add a new rule keyword "requires" that allows a rule to require specific
Suricata versions and/or Suricata features to be enabled.
Example:
requires: feature geoip, version >= 7.0.0, version < 8;
requires: version >= 7.0.3 < 8
requires: version >= 7.0.3 < 8 | >= 8.0.3
Feature: #5972
Co-authored-by: Philippe Antoine <pantoine@oisf.net>
Add a more visible explanation of that requests, responses, frontend and
and backend are, in Pgsql context, to avoid having to repeat that over
different portions of the docs.
A CanceldRequest can occur after any query request, and is sent over a
new connection, leading to a new flow. It won't take any reply, but, if
processed by the backend, will lead to an ErrorResponse.
Task #6577