tracing: Comment why cond_snapshot is checked outside of max_lock protection
authorSteven Rostedt (VMware) <rostedt@goodmis.org>
Thu, 14 Feb 2019 23:45:21 +0000 (18:45 -0500)
committerSteven Rostedt (VMware) <rostedt@goodmis.org>
Wed, 20 Feb 2019 18:51:08 +0000 (13:51 -0500)
commit1c347a94ca79ef89156c7ad5d3a44bb2320a7047
treed66b06113205b4c23da74548f15dc13c2e129d1b
parenta3d86a4ad7e4cef6f04f722028916680b4f635cb
tracing: Comment why cond_snapshot is checked outside of max_lock protection

Before setting tr->cond_snapshot, it must be NULL before it can be updated.
It can go to NULL when a trace event hist trigger is created or removed, and
can only be modified under the max_lock spin lock. But because it can only
be set to something other than NULL under both the max_lock spin lock as
well as the trace_types_lock, we can perform the check if it is not NULL
only under the trace_types_lock and fail out without having to grab the
max_lock spin lock.

This is very subtle, and deserves a comment.

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
kernel/trace/trace.c