///Find conditions where if and else branch are functionally
// identical.
//
// There can be false positives in cases where the positional
// information is used (as with lockdep) or where the identity
// is a placeholder for not yet handled cases.
// Unfortunately there also seems to be a tendency to use
// the last if else/else as a "default behavior" - which some
// might consider a legitimate coding pattern. From discussion
// on kernelnewbies though it seems that this is not really an
// accepted pattern and if at all it would need to be commented
//
// In the Linux kernel it does not seem to actually report
// false positives except for those that were documented as
// being intentional.
// the two known cases are:
// arch/sh/kernel/traps_64.c:read_opcode()
// } else if ((pc & 1) == 0) {
// /* SHcompact */
// /* TODO : provide handling for this. We don't really support
// user-mode SHcompact yet, and for a kernel fault, this would
// have to come from a module built for SHcompact. */
// return -EFAULT;
// } else {
// /* misaligned */
// return -EFAULT;
// }
// fs/kernfs/file.c:kernfs_fop_open()
// * Both paths of the branch look the same. They're supposed to
// * look that way and give @of->mutex different static lockdep keys.
// */
// if (has_mmap)
// mutex_init(&of->mutex);
// else
// mutex_init(&of->mutex);
//
// All other cases look like bugs or at least lack of documentation
//
// Confidence: Moderate
// Copyright: (C) 2016 Nicholas Mc Guire, OSADL. GPLv2.
// Comments:
// Options: --no-includes --include-headers
virtual org
virtual report
@cond@
statement S1;
position p;
@@
* if@p (...) S1 else S1
@script:python depends on org@
p << cond.p;
@@
cocci.print_main("WARNING: possible condition with no effect (if == else)",p)
@script:python depends on report@
p << cond.p;
@@
coccilib.report.print_report(p[0],"WARNING: possible condition with no effect (if == else)")
xt.git/diff/include/dt-bindings/pinctrl/keystone.h?id=79c6f448c8b79c321e4a1f31f98194e4f6b6cae7'>diff
tracing: Fix hwlat kthread migration
The hwlat tracer creates a kernel thread at start of the tracer. It is
pinned to a single CPU and will move to the next CPU after each period of
running. If the user modifies the migration thread's affinity, it will not
change after that happens.
The original code created the thread at the first instance it was called,
but later was changed to destroy the thread after the tracer was finished,
and would not be created until the next instance of the tracer was
established. The code that initialized the affinity was only called on the
initial instantiation of the tracer. After that, it was not initialized, and
the previous affinity did not match the current newly created one, making
it appear that the user modified the thread's affinity when it did not, and
the thread failed to migrate again.
Cc: stable@vger.kernel.org
Fixes: 0330f7aa8ee6 ("tracing: Have hwlat trace migrate across tracing_cpumask CPUs")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>