-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build-info: workaround special _FORTIFY_SOURCE defines #1871
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On systems like Gentoo where _FORTIFY_SOURCE is already defined like FORTIFY_SOURCE=((defined __OPTIMIZE && OPTIMIZE > 0) ? 2 : 0) the use within the printf function (%d) won't result in the correct value and we end up with 'defined' undeclared compile error. This workaround makes sure that just the resolved value is checked and then printed.
Closed
victorjulien
added a commit
to victorjulien/suricata
that referenced
this pull request
Nov 20, 2019
A BUG_ON statement would seemingly randomly trigger during the threading shutdown logic. After a packet thread reached the THV_RUNNING_DONE state, it would sometimes still receive flow timeout packets which would then remain unprocessed. 1 main: TmThreadDisableReceiveThreads(); <- stop capturing packets 2 worker: -> TmThreadTimeoutLoop (THV_FLOW_LOOP) phase starts 3 main: FlowForceReassembly(); <- inject packets from flow engine 4 main: TmThreadDisablePacketThreads(); <- then disable packet threads 5 main: -> checks if 'worker' is ready processing packets 6 main: -> sends THV_KILL to worker 7 worker: breaks out of TmThreadTimeoutLoop and changes to THV_RUNNING_DONE. Part of the problem was with (5) above. When checking if the worker was already done with its work, TmThreadDisablePacketThreads would not consider the injected flow timeout packets. The second part of the problem was with (7), where the worker checked if it was ready with the TmThreadTimeoutLoop in a thread unsafe way. As a result TmThreadDisablePacketThreads would not wait long enough for the worker(s) to finish its work and move the threads to the THV_RUNNING_DONE phase by issuing the THV_KILL command. When waiting for packet processing threads to process all in-flight packets, also consider the 'stream_pq'. This will have received the flow timeout packets. Bug OISF#1871.
victorjulien
added a commit
to victorjulien/suricata
that referenced
this pull request
Nov 25, 2019
A BUG_ON statement would seemingly randomly trigger during the threading shutdown logic. After a packet thread reached the THV_RUNNING_DONE state, it would sometimes still receive flow timeout packets which would then remain unprocessed. 1 main: TmThreadDisableReceiveThreads(); <- stop capturing packets 2 worker: -> TmThreadTimeoutLoop (THV_FLOW_LOOP) phase starts 3 main: FlowForceReassembly(); <- inject packets from flow engine 4 main: TmThreadDisablePacketThreads(); <- then disable packet threads 5 main: -> checks if 'worker' is ready processing packets 6 main: -> sends THV_KILL to worker 7 worker: breaks out of TmThreadTimeoutLoop and changes to THV_RUNNING_DONE. Part of the problem was with (5) above. When checking if the worker was already done with its work, TmThreadDisablePacketThreads would not consider the injected flow timeout packets. The second part of the problem was with (7), where the worker checked if it was ready with the TmThreadTimeoutLoop in a thread unsafe way. As a result TmThreadDisablePacketThreads would not wait long enough for the worker(s) to finish its work and move the threads to the THV_RUNNING_DONE phase by issuing the THV_KILL command. When waiting for packet processing threads to process all in-flight packets, also consider the 'stream_pq'. This will have received the flow timeout packets. Bug OISF#1871.
victorjulien
added a commit
to victorjulien/suricata
that referenced
this pull request
Dec 11, 2019
A BUG_ON statement would seemingly randomly trigger during the threading shutdown logic. After a packet thread reached the THV_RUNNING_DONE state, it would sometimes still receive flow timeout packets which would then remain unprocessed. 1 main: TmThreadDisableReceiveThreads(); <- stop capturing packets 2 worker: -> TmThreadTimeoutLoop (THV_FLOW_LOOP) phase starts 3 main: FlowForceReassembly(); <- inject packets from flow engine 4 main: TmThreadDisablePacketThreads(); <- then disable packet threads 5 main: -> checks if 'worker' is ready processing packets 6 main: -> sends THV_KILL to worker 7 worker: breaks out of TmThreadTimeoutLoop and changes to THV_RUNNING_DONE. Part of the problem was with (5) above. When checking if the worker was already done with its work, TmThreadDisablePacketThreads would not consider the injected flow timeout packets. The second part of the problem was with (7), where the worker checked if it was ready with the TmThreadTimeoutLoop in a thread unsafe way. As a result TmThreadDisablePacketThreads would not wait long enough for the worker(s) to finish its work and move the threads to the THV_RUNNING_DONE phase by issuing the THV_KILL command. When waiting for packet processing threads to process all in-flight packets, also consider the 'stream_pq'. This will have received the flow timeout packets. Bug OISF#1871. (cherry picked from commit fe9aeed)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On systems like Gentoo where _FORTIFY_SOURCE is already defined like
FORTIFY_SOURCE=((defined __OPTIMIZE && OPTIMIZE > 0) ? 2 : 0) the use
within the printf function (%d) won't result in the correct value and
we end up with 'defined' undeclared compile error. This workaround makes
sure that just the resolved value is checked and then printed.
This resolves the issue https://redmine.openinfosecfoundation.org/issues/1676 and also added more description/comment as proposed in the former PR: #1863