]> git.karo-electronics.de Git - linux-beck.git/commit
i386: Remove unneeded test of 'task' in dump_trace() (again)
authorSteven Rostedt <rostedt@goodmis.org>
Fri, 7 Mar 2014 15:52:42 +0000 (10:52 -0500)
committerIngo Molnar <mingo@kernel.org>
Tue, 11 Mar 2014 11:02:31 +0000 (12:02 +0100)
commit7743a536beda6225eef4a0758c5370f761fb0616
tree6b430b8c29c6a1e1e6dac333ef26ac219f2029f4
parent8712a00514e50aafa7c9bf5cd3955fa60758e53b
i386: Remove unneeded test of 'task' in dump_trace() (again)

Commit 028a690a1ebc8b "i386: Remove unneeded test of 'task' in
dump_trace()" correctly removed the unneeded 'task != NULL'
check because it would be set to current if it was NULL.

Commit 2bc5f927d489 "i386: split out dumpstack code from
traps_32.c" moved the code from traps_32.c to its own file
dump_stack.c for preparation of the i386 / x86_64 merge.

Commit 8a541665b906 "dumpstack: x86: various small unification
steps" worked to make i386 and x86_64 dump_stack logic similar.
But this actually reverted the correct change from
028a690a1ebc8b.

Commit d0caf292505d "x86/dumpstack: Remove unneeded check in
dump_trace()" removed the unneeded "task != NULL" check for
x86_64 but left that same unneeded check for i386, that was
added because x86_64 had it!

This chain of events ironically had i386 add back the unneeded
task != NULL check because x86_64 did it, and then the fix for
x86_64 was fixed by Dan. And even more ironically, it was Dan's
smatch bot that told me that a change to dump_stack_32 I made
may be wrong if current can be NULL (it can't), as there was a
check for it by assigning task to current, and then checking if
task is NULL.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Alexander van Heukelum <heukelum@fastmail.fm>
Cc: Jesper Juhl <jesper.juhl@gmail.com>
Link: http://lkml.kernel.org/r/20140307105242.79a0befd@gandalf.local.home
Signed-off-by: Ingo Molnar <mingo@kernel.org>
arch/x86/kernel/dumpstack_32.c