Remove unnecessary null pointer checks?
Subsystems (270)
Hello,
I have tried the following short semantic patch out on a source file directory for Linux 3.13.1.
@Remove_unnecessary_pointer_checks@
expression x;
@@
-if (x)
kfree(x);
Some update candidates were found. I imagine that this search pattern can be extended a bit more.
How do think about the applicability of corresponding changes for current kernel source code?
What will be a good way to discuss such fixes on other mailing lists eventually?
Regards,
Markus
Quoted 9 lines · SF Markus Elfring
Hello,
I have tried the following short semantic patch out on a source file directory for Linux 3.13.1.
@Remove_unnecessary_pointer_checks@
expression x;
@@
-if (x)
Quoted 5 lines
kfree(x);Some update candidates were found. I imagine that this search pattern can be extended a bit more.
Not sure what you mean by extended. There are indeed some other functions in Linux that perform NULL tests before doing anything, and thus they don't really need a null test around them. Actually, it could be possible to find such functions using Coccinelle.
On the other hand, I think that one should study the code carefully before making such a change. There are several ways to make error handling code. One is to have one label at the end of the function, to have all error cases jump to there, and then to have if tests to decide what should be done. Another way is to have lots of labels, and jump directly to the right place, without any tests.
I think that the second way is nicer. So in removing such an if, one can consider whether the code could be further improved by adding more labels, and jumping to the right place directly, rather tha executing unnecessary code.
Quoted 3 lines
How do think about the applicability of corresponding changes for current kernel source code?
What will be a good way to discuss such fixes on other mailing lists eventually?
If you want to propose Linux related fixes, you may want to look at the kernel janitors mailing list.
http://vger.kernel.org/vger-lists.html#kernel-janitors
julia
Quoted 1 line
Not sure what you mean by extended.
I have tried the following search pattern.
@Show_functions_with_input_pointer_validation@
identifier fun, x;
type t;
@@
*fun(..., t* x, ...)
{
...
if (!x) return;
...
}
Will your current tool version "1.0.0-rc20" find also the kfree() functions?
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/mm/slab.c#n3641
Should I add any variant of "unlikely(ZERO_OR_NULL_PTR(...))" to my filter pattern eventually?
Quoted 2 lines
If you want to propose Linux related fixes, you may want to look at the kernel janitors mailing list.
Would it make sense to add the shown semantic patches to a specific script directory?
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/scripts/coccinelle
Regards,
Markus
Quoted 16 lines · SF Markus Elfring
Quoted 1 line
Not sure what you mean by extended.
I have tried the following search pattern.
@Show_functions_with_input_pointer_validation@
identifier fun, x;
type t;
@@
*fun(..., t* x, ...)
{
...
if (!x) return;
...
}
Quoted 5 lines
Will your current tool version "1.0.0-rc20" find also the
kfree()functions?
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/mm/slab.c#n3641Should I add any variant of "unlikely(ZERO_OR_NULL_PTR(...))" to my filter pattern eventually?
If you want to match a call to ZERO_OR_NULL_PTR, then you need to include that in the semantic patch. Coccinelle does not expand macros, so if doesn't see the relation to a NULL test.
Quoted 6 lines
Quoted 2 lines
If you want to propose Linux related fixes, you may want to look at the kernel janitors mailing list.
Would it make sense to add the shown semantic patches to a specific script directory?
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/scripts/coccinelle
Not sure to understand what the "shown semantic patches" refers to. What you have proposed is a semntic patch that finds functions that test their argument for NULL and return if the test is satisfied. That gives the user some information, but the rules in the Linux kernel are for finding bugs or making transformations.
Personally, I rather like null tests, if they are really needed, ie not implied to be always false by the context, because they give some information, eg that the value can be null at this point, and it is important to take that into account when considerin the following operation. So I'm not very eager to go around removing them.
julia
Quoted 3 lines
If you want to match a call to
ZERO_OR_NULL_PTR, then you need to include that in the semantic patch. Coccinelle does not expand macros, so if doesn't see the relation to a NULL test.
I have tried a command like the following a moment ago.
elfring at Sonne:~/Projekte/Coccinelle/janitor> MY_PATTERN=find_input_pointer_validation2.cocci && cat $MY_PATTERN && echo '-----' && spatch --version && spatch --sp-file $MY_PATTERN /usr/src/linux-stable/mm/slab.c --recursive-includes -I /usr/src/linux-stable/include/linux -I /usr/src/linux-stable/include/uapi -I /usr/src/linux-stable/arch/ia64/include -I /usr/src/linux-stable/include/asm-generic -I /usr/src/linux-stable/include/asm-generic/bitops -I /usr/local/include/c++/4.8.2 -I /usr/local/include/c++/4.8.2/x86_64-unknown-linux-gnu -I /usr/local/include -I /usr/include
@Show_functions_with_input_pointer_validation@
identifier fun, x;
type t;
@@
*void fun(..., t* x, ...)
{
...
if (unlikely(ZERO_OR_NULL_PTR(x)))
return;
...
}
-----
spatch version 1.0.0-rc20 with Python support and with PCRE supportinit_defs_builtins: ...
(ONCE) TYPE: header trace/events/kmem.h not found
previous modification:
MINUS
According to environment 2:
Show_functions_with_input_pointer_validation.t -> const
void
Show_functions_with_input_pointer_validation.fun -> id kfree
current modification:
MINUS
According to environment 2:
Show_functions_with_input_pointer_validation.t -> const void Show_functions_with_input_pointer_validation.fun -> id kfree
Fatal error: exception Failure("Show_functions_with_input_pointer_validation:
already tagged token:
C code context
File "/usr/src/linux-stable/mm/slab.c", line 3650, column 11, charpos = 94972
around = 'const', whole content = void kfree(const void *objp)")
How can I achieve a better result here?
Quoted 4 lines
What you have proposed is a semntic patch that finds functions that test their argument for NULL and return if the test is satisfied. That gives the user some information, but the rules in the Linux kernel are for finding bugs or making transformations.
I try to collect all names for functions which handle passed null pointers in a known way. I hope that such a function list can be converted into a constraint for a metavariable in another semantic patch variant.
Regards,
Markus
Quoted 1 line
spatch version 1.0.0-rc20 with Python support and with PCRE support
[...]
Quoted 3 lines
Fatal error: exception Failure("Show_functions_with_input_pointer_validation:
already tagged token:
C code context
I tried this small source code search out again.
elfring at Sonne:~/Projekte/Coccinelle/janitor> date \
Quoted 15 lines
&& MY_PATTERN=find_input_pointer_validation2.cocci \
&& cat $MY_PATTERN \
&& echo '-----' \
&& spatch.opt --version \
&& spatch.opt --profile --include-headers-for-types --recursive-includes \(quoted diff) +0
-10-I /usr/src/linux-stable/include/linux \ -I /usr/src/linux-stable/include/uapi \ -I /usr/src/linux-stable/arch/ia64/include \ -I /usr/src/linux-stable/include/asm-generic \ -I /usr/src/linux-stable/include/asm-generic/bitops \ -I /usr/local/include/c++/4.8.2 \ -I /usr/local/include/c++/4.8.2/x86_64-unknown-linux-gnu \ -I /usr/local/include \ -I /usr/include \ --sp-file $MY_PATTERN /usr/src/linux-stable/mm/slab.c; \
Quoted 1 line
date
So 26. Okt 07:02:18 CET 2014
@Show_functions_with_input_pointer_validation@
identifier fun, x;
type t;
@@
*void fun(..., t* x, ...)
{
...
if (unlikely(ZERO_OR_NULL_PTR(x)))
return;
...
}
-----
spatch version 1.0.0-rc22 with Python support and with PCRE supportinit_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/mm/slab.c
(ONCE) TYPE: header process.h not found
[...]
(ONCE) TYPE: header trace/events/kmem.h not found
(ONCE) already tagged but only removed, so safe
diff =
--- /usr/src/linux-stable/mm/slab.c
@@ -3598,7 +3598,6 @@ EXPORT_SYMBOL(kmem_cache_free);
* Don't free memory not originally allocated by kmalloc()
* or you will run into trouble.
*/
-void kfree(const void *objp)
{
struct kmem_cache *c;
unsigned long flags;Note: processing took 43.5s: /usr/src/linux-stable/mm/slab.c
starting: Common.group_assoc_bykey_eff
ending: Common.group_assoc_bykey_eff, 0.000005s
---------------------
profiling result
---------------------
Main total : 43.552 sec 1 count Main.outfiles computation : 43.490 sec 1 count full_engine : 43.481 sec 1 count C parsing : 17.765 sec 866 count TOTAL : 17.763 sec 866 count HACK : 6.017 sec 2001 count C parsing.fix_cpp : 5.559 sec 1134 count C parsing.tokens : 3.528 sec 867 count LEXING : 3.506 sec 866 count Parsing: multi pass : 2.818 sec 2369 count Parsing: 1st pass : 2.258 sec 42256 count MACRO managment : 1.725 sec 2671 count YACC : 1.634 sec 40007 count TAC.annotate_program : 0.983 sec 433 count show_xxx : 0.855 sec 310 count C parsing.fix_define : 0.761 sec 1733 count MACRO mgmt prep 2 : 0.494 sec 866 count C consistencycheck : 0.461 sec 866 count C parsing.lookahead : 0.407 sec 455401 count Common.full_charpos_to_pos_large : 0.389 sec 867 count flow : 0.371 sec 20946 count C parsing.mk_info_item : 0.361 sec 42256 count C parsing.lex_ident : 0.314 sec 313227 count Type_c.type_of_s : 0.234 sec 10649 count fix_flow : 0.154 sec 15138 count TAC.add_binding : 0.075 sec 18856 count MACRO mgmt prep 1 : 0.064 sec 866 count pre_engine : 0.036 sec 1 count parse cocci : 0.032 sec 1 count bigloop : 0.026 sec 1 count Show_functions_with_input_pointer_validation : 0.023 sec 1 count process_a_ctl_a_env_a_toplevel : 0.023 sec 300 count mysat : 0.022 sec 300 count Common.info_from_charpos : 0.018 sec 82 count Common.=~ : 0.013 sec 9107 count worth_trying : 0.009 sec 1 count Common.full_charpos_to_pos : 0.005 sec 2 count TAC.typedef_fix : 0.005 sec 14621 count C unparsing : 0.005 sec 2 count asttoctl2 : 0.003 sec 1 count ctl : 0.000 sec 3 count Transformation3.transform : 0.000 sec 1 count get_glimpse_constants : 0.000 sec 1 count Main.result analysis : 0.000 sec 1 count check_duplicate : 0.000 sec 1 count Common.group_assoc_bykey_eff : 0.000 sec 1 count C_vs_c : 0.000 sec 1 count merge_env : 0.000 sec 1 count post_engine : 0.000 sec 1 count Main.infiles computation : 0.000 sec 1 count
So 26. Okt 07:03:01 CET 2014
Do you find this analysis result interesting?
Regards,
Markus
A message that is not in the archive (sent off-list or not yet received): alpine.DEB.2.10.1410260614460.2563@hadrien
I would like to show again that the version 1.0.0-rc22 works better than 1.0.0-rc20 for another use case.
Quoted 1 line
There is an isomorphism for unlikely, but it does not work well.
Interesting ...
Quoted 2 lines
You can disable it (look in standard.iso to find the name and then put disable name between the initial @@).
Does your feedback refer also to the message "(ONCE) already tagged but only removed, so safe" eventually?
I am curious how the shown profiling results will change over time because of software improvements.
Regards,
Markus
Quoted 1 line
Not sure what you mean by extended.
I would also like to try another source code search approach like the following.
elfring at Sonne:~/Projekte/Coccinelle/janitor> LINE='-----' && echo $LINE && PAT=list_input_parameter_validation1.cocci && cat $PAT && echo $LINE && SP=/usr/local/bin/spatch && $SP --version && $SP --sp-file $PAT /usr/src/linux-stable/fs/btrfs/extent_map.c
-----
@initialize:python@
@@
import sys
result = []
mark = ['"', '', '"']
delimiter = '|'
def store_positions(fun, typ, point, places):
"""Add source code positions to an internal list."""
for place in places:
fields = []
fields.append(fun)
mark[1] = typ
fields.append(''.join(mark))
fields.append(point)
mark[1] = place.file.replace('"', '""')
fields.append(''.join(mark))
fields.append(place.line)
fields.append(str(int(place.column) + 1))
result.append(delimiter.join(fields))@safety_check@
identifier work, input;
type data_type;
position pos;
@@
void work at pos(...,data_type input,...)
{
...
(
if (!input) return;
|
if (input) { ... }
|
if (input) { ... } else { ... }
|
switch (input) { case 0: return; ... }
)
...
}
@script:python collection depends on safety_check@ typ << safety_check.data_type;
fun << safety_check.work;
point << safety_check.input;
places << safety_check.pos;
@@store_positions(fun, typ, point, places)
@finalize:python@
@@
if result:
result.insert(0, delimiter.join(("function", '"data type"', '"parameter"',
'"source file"', "line", "column")))
print("\r\n".join(result))
else:
sys.stderr.write("No result for this analysis!\n")
-----
spatch version 1.0.0-rc20 with Python support and with PCRE supportinit_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/fs/btrfs/extent_map.c
No result for this analysis!
Why is the function "free_extent_map" not displayed here? Do I need to adjust my SmPL rule "safety_check" anyhow?
Regards,
Markus
Something goes wrong with the switch pattern. I would have to look into why. But I think that a switch is highly improbable for making such a test, so you could just drop it. You may also want to specify that input has pointer type, since you are actually looking for NULL tests, not zero tests.
julia
Quoted 83 lines · SF Markus Elfring
Quoted 1 line
Not sure what you mean by extended.
I would also like to try another source code search approach like the following.
elfring at Sonne:~/Projekte/Coccinelle/janitor> LINE='-----' && echo $LINE && PAT=list_input_parameter_validation1.cocci && cat $PAT && echo $LINE && SP=/usr/local/bin/spatch && $SP --version && $SP --sp-file $PAT
/usr/src/linux-stable/fs/btrfs/extent_map.c
-----
@initialize:python@
@@
import sys
result = []
mark = ['"', '', '"']
delimiter = '|'def
store_positions(fun, typ, point, places):"""Add source code positions to an internal list.""" for place in places: fields = [] fields.append(fun) mark[1] = typ fields.append(''.join(mark)) fields.append(point) mark[1] = place.file.replace('"', '""') fields.append(''.join(mark)) fields.append(place.line) fields.append(str(int(place.column) + 1)) result.append(delimiter.join(fields))@safety_check@
identifier work, input;
typedata_type;
position pos;
@@
void work atpos(...,data_type input,...)
{
...
(
if (!input) return;
|
if (input) { ... }
|
if (input) { ... } else { ... }
|
switch (input) { case 0: return; ... }
)
...
}@script:python collection depends on safety_check@ typ << safety_check.data_type;
fun << safety_check.work;
point << safety_check.input;
places << safety_check.pos;
@@store_positions(fun, typ, point, places)@finalize:python@
@@
if result:result.insert(0, delimiter.join(("function", '"data type"', '"parameter"','"source file"', "line", "column")))
print("\r\n".join(result))
else:
sys.stderr.write("No result for this analysis!\n")
-----
spatch version 1.0.0-rc20 with Python support and with PCRE supportinit_defs_builtins:/usr/local/share/coccinelle/standard.h
HANDLING:/usr/src/linux-stable/fs/btrfs/extent_map.c
No result for this analysis!Why is the function "
free_extent_map" not displayed here? Do I need to adjust my SmPL rule "safety_check" anyhow?Regards,
Markus
Quoted 1 line
Something goes wrong with the switch pattern. I would have to look into why.
Thanks for your quick feedback.
Quoted 2 lines
But I think that a switch is highly improbable for making such a test, so you could just drop it.
I just try to make the discussed filter patterns as complete as possible.
Quoted 2 lines
You may also want to specify that input has pointer type, since you are actually looking for NULL tests, not zero tests.
This is an important implementation detail which I would like to generalise so that also functions like "btrfsic_process_written_block" will be safely found by further source code searches.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/check-integrity.c?id=878a876b2e10888afe53766dcca33f723ae20edc#n1835
This one was found by the previous simple pattern for example despite I expected it to handle primarily pointer data types instead of an "unsigned int" in this case.
Regards,
Markus
Quoted 10 lines
Quoted 2 lines
You may also want to specify that input has pointer type, since you are actually looking for NULL tests, not zero tests.
This is an important implementation detail which I would like to generalise so that also functions like "
btrfsic_process_written_block" will be safely found by further source code searches.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/check-integrity.c?id=878a876b2e10888afe53766dcca33f723ae20edc#n1835This one was found by the previous simple pattern for example despite I expected it to handle primarily pointer data types instead of an "unsigned int" in this case.
As you like. As a general principle, I think it is better to work on fewer things at once. There are many reason why values may be null or 0, and if you lump too many of them together, you will end up with more information than is manageable. No bugs are involved here, you are only making the code simpler, and if you miss some possibilities for making the code simpler, it doesn't matter. You can just work on them later.
julia
Quoted 2 lines
But I think that a switch is highly improbable for making such a test, so you could just drop it.
I have got another idea for a bit of fine-tuning. I got the impression from the manual that the SmPL syntax element "singleton" might be applicable.
elfring at Sonne:~/Projekte/Coccinelle/janitor> LINE='-----' && echo $LINE && PAT=list_input_parameter_validation2.cocci && cat $PAT && echo $LINE && SP=/usr/local/bin/spatch && $SP --version && $SP --sp-file $PAT /usr/src/linux-stable/fs/btrfs/extent_map.c
-----
@initialize:python@
@@
import sys
result = []
mark = ['"', '', '"']
delimiter = '|'
def store_positions(fun, typ, point, places):
"""Add source code positions to an internal list."""
for place in places:
fields = []
fields.append(fun)
mark[1] = typ
fields.append(''.join(mark))
fields.append(point)
mark[1] = place.file.replace('"', '""')
fields.append(''.join(mark))
fields.append(place.line)
fields.append(str(int(place.column) + 1))
result.append(delimiter.join(fields))@safety_check@
identifier work, input;
type data_type;
position pos;
statement is, es;
@@
void work at pos(...,data_type input,...)
{
...
( if (!input) return;
| if (input) is
? else es
;
)
...
}
@script:python collection depends on safety_check@ typ << safety_check.data_type;
fun << safety_check.work;
point << safety_check.input;
places << safety_check.pos;
@@store_positions(fun, typ, point, places)
@finalize:python@
@@
if result:
result.insert(0, delimiter.join(("function", '"data type"', '"parameter"',
'"source file"', "line", "column")))
print("\r\n".join(result))
else:
sys.stderr.write("No result for this analysis!\n")
-----
spatch version 1.0.0-rc20 with Python support and with PCRE supportinit_defs_builtins: /usr/local/share/coccinelle/standard.h
warning: incompatible arity found on line 36
?safety_check:es
Fatal error: exception Failure("get_before_e: not supported")
Can this situation be improved?
Regards,
Markus
Quoted 10 lines · SF Markus Elfring
Quoted 2 lines
But I think that a switch is highly improbable for making such a test, so you could just drop it.
I have got another idea for a bit of fine-tuning. I got the impression from the manual that the SmPL syntax element "singleton" might be applicable.
elfring at Sonne:~/Projekte/Coccinelle/janitor> LINE='-----' && echo $LINE && PAT=list_input_parameter_validation2.cocci && cat $PAT && echo $LINE && SP=/usr/local/bin/spatch && $SP --version && $SP --sp-file $PAT
/usr/src/linux-stable/fs/btrfs/extent_map.c
Please don't put all of this noise in your messages. The only thing that is interesting is the file on which you have run Coccinelle.
Quoted 28 lines
-----
@initialize:python@
@@
import sys
result = []
mark = ['"', '', '"']
delimiter = '|'def
store_positions(fun, typ, point, places):"""Add source code positions to an internal list.""" for place in places: fields = [] fields.append(fun) mark[1] = typ fields.append(''.join(mark)) fields.append(point) mark[1] = place.file.replace('"', '""') fields.append(''.join(mark)) fields.append(place.line) fields.append(str(int(place.column) + 1)) result.append(delimiter.join(fields))
Quoted 13 lines
@safety_check@
identifier work, input;
typedata_type;
position pos;
statement is, es;
@@
void work atpos(...,data_type input,...)
{
...
( if (!input) return;
| if (input) is
? else es
;
There is no need to put the ? else es. If you put if (intput) is else es then an isomorphism will consider the case where else es is not there.
Also, the semicolon after is/es does not look right. Notmally one does not put an extra semicolon after an if.
julia
Quoted 34 lines
)
...
}@script:python collection depends on safety_check@ typ << safety_check.data_type;
fun << safety_check.work;
point << safety_check.input;
places << safety_check.pos;
@@store_positions(fun, typ, point, places)@finalize:python@
@@
if result:result.insert(0, delimiter.join(("function", '"data type"', '"parameter"','"source file"', "line", "column")))
print("\r\n".join(result))
else:
sys.stderr.write("No result for this analysis!\n")
-----
spatch version 1.0.0-rc20 with Python support and with PCRE supportinit_defs_builtins:/usr/local/share/coccinelle/standard.h
warning: incompatible arity found on line 36 ?safety_check:es
Fatal error: exceptionFailure("get_before_e: not supported")Can this situation be improved?
Regards,
Markus
Quoted 1 line
There is no need to put the ? else es.
Thanks for your explanation.
I get a "surprise" if I try out the following SmPL variant.
@safety_check@
identifier function, input;
type data_type;
position pos;
statement is, es;
@@
void function at pos(...,data_type input,...)
{
...
( if (!input) return;
| if (input) is else es
)
...
}
@script:python collection depends on safety_check@ typ << safety_check.data_type;
fun << safety_check.function;
point << safety_check.input;
places << safety_check.pos;
@@store_positions(fun, typ, point, places)
Response:
875 883
Fatal error: exception Failure("scriptmeta: parse error:
= File "list_input_parameter_validation3.cocci", line 43, column 20, charpos = 875
around = 'function', whole content = fun << safety_check.function;
Can such names be reused which are key words@other places?
Regards,
Markus
Quoted 30 lines · SF Markus Elfring
Quoted 1 line
There is no need to put the ? else es.
Thanks for your explanation.
I get a "surprise" if I try out the following SmPL variant.
@safety_check@
identifier function, input;
typedata_type;
position pos;
statement is, es;
@@
void function atpos(...,data_type input,...)
{
...
( if (!input) return;
| if (input) is else es
)
...
}@script:python collection depends on safety_check@ typ << safety_check.data_type;
fun << safety_check.function;
point << safety_check.input;
places << safety_check.pos;
@@store_positions(fun, typ, point, places)
Quoted 8 lines
Response:
875 883
Fatal error: exception Failure("scriptmeta: parse error:
= File "list_input_parameter_validation3.cocci", line 43, column 20, charpos = 875around = 'function', whole content = fun << safety_check.function;Can such names be reused which are key words at other places?
Apparently there is a problem in this case. I will make a note of it. In the meantime, just use another name.
julia
Quoted 1 line
There is no need to put the ? else es.
I get the following result for the adjusted search pattern.
void work at pos(...,data_type input,...)
{
...
( if (!input) return;
| if (input) is else es
)
...
}
elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch --sp-file list_input_parameter_validation2.cocci /usr/src/linux-stable/arch/um/kernel/sysrq.c
...
function|"data type"|"parameter"|"source file"|line|column show_stack|"unsigned long *"|stack|"/usr/src/linux-stable/arch/um/kernel/sysrq.c"|67|6
This example does not fit to my expectation because it seems that the function implementation does not refer to the passed values.
Do you get any idea for this potential mismatch?
Regards,
Markus
Quoted 22 lines · SF Markus Elfring
Quoted 1 line
There is no need to put the ? else es.
I get the following result for the adjusted search pattern.
void work at
pos(...,data_type input,...)
{
...
( if (!input) return;
| if (input) is else es
)
...
}elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch --sp-file
list_input_parameter_validation2.cocci/usr/src/linux-stable/arch/um/kernel/sysrq.c
...
function|"data type"|"parameter"|"source file"|line|column show_stack|"unsigned long *"|stack|"/usr/src/linux-stable/arch/um/kernel/sysrq.c"|67|6
Quoted 3 lines
This example does not fit to my expectation because it seems that the function implementation does not refer to the passed values.
Do you get any idea for this potential mismatch?
I'm not sure, but I think it has to do with the fact that the entire function is an if where both branches leave the function. It seems to be considering that to be error-handling code. It does not require to find the complete pattern on execution paths that correspond to error-handling code. So it doesn't require to find the pattern at all.
In your case, I think you want to be completely sure that regardless of the execution path chosen, the test is performed. So you should put when string after the first ... (ie the one after the first { ).
julia
Quoted 2 lines
Quoted 2 lines
This example does not fit to my expectation because it seems that the function implementation does not refer to the passed values.
I must correct my conclusion here. One function parameter is actually used in the condition "!stack" while the second parameter is forwarded to other function calls.
Is this source code line 83 handled by a SmPL isomorphism?
Quoted 3 lines
In your case, I think you want to be completely sure that regardless of the execution path chosen, the test is performed. So you should put when string after the first ... (ie the one after the first { ).
I'm sorry. I do not really understand your suggestion.
Regards,
Markus
Quoted 22 lines · SF Markus Elfring
Quoted 1 line
There is no need to put the ? else es.
I get the following result for the adjusted search pattern.
void work at
pos(...,data_type input,...)
{
...
( if (!input) return;
| if (input) is else es
)
...
}elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch --sp-file
list_input_parameter_validation2.cocci/usr/src/linux-stable/arch/um/kernel/sysrq.c
...
function|"data type"|"parameter"|"source file"|line|column show_stack|"unsigned long *"|stack|"/usr/src/linux-stable/arch/um/kernel/sysrq.c"|67|6
Quoted 3 lines
This example does not fit to my expectation because it seems that the function implementation does not refer to the passed values.
Do you get any idea for this potential mismatch?
Sorry, I had been looking at the wrong function when I wrote my previous response.
Indeed, there are some uses of isomorphisms at work here. First the
if (input) is else es
is changed to
if (!input) es else is
and then that is changed to
if (!input) es
which matches the code at line 83.
I'm not sure what is the point of the if (input) is else es pattern. I would think you only want to find cases where the function does nothing until it tests input and aborts the function is the value is 0. So you only want the return case. Before it, you would want
... when != S
where S is a statement typed metavariable. That way the ... will only match declarations.
julia
Quoted 1 line
I'm not sure what is the point of the if (input) is else es pattern.
Now it seems that I added it because of too few considerations for isomorphisms.
Quoted 8 lines
I would think you only want to find cases where the function does nothing until it tests input and aborts the function is the value is 0. So you only want the return case. Before it, you would want
... when != S
where S is a statement typed metavariable. That way the ... will only match declarations.
We have got different expectations about the amount of source code before the statement "return". A bit more fine-tuning with the SmPL construct "when" might be needed to achieve further constraints.
Regards,
Markus
Quoted 2 lines
Quoted 2 lines
This example does not fit to my expectation because it seems that the function implementation does not refer to the passed values.
I'm sorry that I overlooked information somehow there.
The implementations of the function "show_stack" can be nice source code examples for further fine-tuning of proposed filter patterns.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/um/kernel/sysrq.c?id=8ed12fcc194d93c6a17714120a7027ee4d76a881#n67
Its interface contains two pointer parameters.
Quoted 1 line
I'm not sure what is the point of the if (input) is else es pattern.
I can also adjust the search approach like the following.
@safety_check@
identifier work, input;
type data_type;
position pos;
statement is, es;
@@
void work at pos(...,data_type input,...)
{
...
( if (input) is
| if (likely(input)) is
)
else es
...
}
Quoted 2 lines
I would think you only want to find cases where the function does nothing until it tests input and aborts the function is the value is 0.
I guess that the interpretation of "nothing relevant" will need further considerations, won't it?
Quoted 1 line
So you only want the return case.
Not "only" this one ...
I have got a feeling for a need to introspect the else branch for useful properties. I am unsure about better analysis of the metavariable "es" with the semantic patch language.
Regards,
Markus
Quoted 15 lines
I can also adjust the search approach like the following.
@safety_check@
identifier work, input;
typedata_type;
position pos;
statement is, es;
@@
void work atpos(...,data_type input,...)
{
...
( if (input) is
| if (likely(input)) is
)
else es
This is not allowed. Inside a disjunction you need to have complete terms.
Quoted 11 lines
...
}Quoted 2 lines
I would think you only want to find cases where the function does nothing until it tests input and aborts the function is the value is 0.
I guess that the interpretation of "nothing relevant" will need further considerations, won't it?
Quoted 7 lines
Quoted 1 line
So you only want the return case.
Not "only" this one ...
I have got a feeling for a need to introspect the else branch for useful properties. I am unsure about better analysis of the metavariable "es" with the semantic patch language.
I'm not sure to understand your goal. If the code currently has:
if (x != NULL)
call(x);
then the developer does not want to execute any of the code within call if x is NULL. If you just check that there is a NULL test on x somewhere within the definition of call, then that is not enough to ensure that nothing is executed within call. If you remove the NULL test, you could drastically change the behavior of the program.
julia
Quoted 1 line
This is not allowed. Inside a disjunction you need to have complete terms.
Thanks for your information. I guess that another adjustment will fit to the SmPL syntax then.
( if (input) is else es
| if (likely(input)) is else es
)
Quoted 7 lines
I'm not sure to understand your goal. If the code currently has:
if (x != NULL)
call(x);then the developer does not want to execute any of the code within call if x is NULL.
Yes. - This is one of the use cases I am trying to improve. It depends on the knowledge if something unwanted will happen if a null pointer (or zero) would be passed. If it is documented for example that an implementation of the function "call" checks the condition "!= NULL", I find the same check by the caller redundant.
Quoted 2 lines
If you just check that there is a NULL test on x somewhere within the definition of call, then that is not enough to ensure that nothing is executed within call.
Would you like to suggest any more fine-tuning?
Quoted 1 line
If you remove the NULL test, you could drastically change the behavior of the program.
I agree in principle.
But I would like to delete redundant checks from some source files.
Regards,
Markus
Quoted 1 line
I'm not sure to understand your goal.
I get an interesting result for example if I try the following source code search pattern out. Do you find it useful?
@Delete_unnecessary_checks@
expression x;
identifier release =~ "^(?x)
(?:
(?:kz?|slob_)free
|
(?:
abc
| xyz
)
)$";
@@
-if (x)
release(...,x,...);
elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch --sp-file delete_unnecessary_checks1.cocci /usr/src/linux-stable/fs/btrfs/inode.cinit_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/fs/btrfs/inode.c
tmp/cocci-output-3740-5d95d8-inode.c renamed from usr/src/linux-stable/fs/btrfs/inode.c +1 -2
@@ -5137,8 +5137,7 @@ static int btrfs_dentry_delete(const strstatic void btrfs_dentry_release (struct dentry *dentry) { -if (dentry->d_fsdata) -kfree (dentry->d_fsdata); +kfree (dentry->d_fsdata); }
Quoted 2 lines
If you remove the NULL test, you could drastically change the behavior of the program.
But it seems that I stumble on a software debug challenge after I replaced the dummy alternation in the regular expression above by the real list of 5142 function names which were found by the other discussed pattern.
elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch --sp-file delete_unnecessary_checks2.cocci /usr/src/linux-stable/fs/btrfs/inode.cinit_defs_builtins: /usr/local/share/coccinelle/standard.h Fatal error: exception Pcre.Error(_)
Regards,
Markus
Quoted 40 lines · SF Markus Elfring
Quoted 1 line
I'm not sure to understand your goal.
I get an interesting result for example if I try the following source code search pattern out. Do you find it useful?
@Delete_unnecessary_checks@
expression x;
identifier release =~ "^(?x)
(?:(?:kz?|slob_)free|
(?:
abc
| xyz
)
)$";
@@
-if (x)release(...,x,...);elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch --sp-file
delete_unnecessary_checks1.cocci/usr/src/linux-stable/fs/btrfs/inode.cinit_defs_builtins:/usr/local/share/coccinelle/standard.h
HANDLING:/usr/src/linux-stable/fs/btrfs/inode.c
diff =tmp/cocci-output-3740-5d95d8-inode.c renamed from usr/src/linux-stable/fs/btrfs/inode.c +1
-2@@ -5137,8 +5137,7 @@ static int btrfs_dentry_delete(const strstatic void btrfs_dentry_release (struct dentry *dentry) { -if (dentry->d_fsdata) -kfree (dentry->d_fsdata); +kfree (dentry->d_fsdata); }Quoted 2 lines
If you remove the NULL test, you could drastically change the behavior of the program.
Quoted 8 lines
But it seems that I stumble on a software debug challenge after I replaced the dummy alternation in the regular expression above by the real list of 5142 function names which were found by the other discussed pattern.
elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch --sp-file
delete_unnecessary_checks2.cocci/usr/src/linux-stable/fs/btrfs/inode.cinit_defs_builtins:/usr/local/share/coccinelle/standard.hFatal error: exceptionPcre.Error(_)
I don't think it is a good approach to do anything related to 5142 different functions at once. It would be better to pick a small set of functions, and work on them carefully.
julia
Quoted 2 lines
I don't think it is a good approach to do anything related to 5142 different functions at once.
A source code search with the following pattern found only six functions for further consideration.
@is_unnecessary_check@
expression data;
identifier work;
identifier release =~ "^kz?free$";
position pos;
type t;
@@
t work at pos(...)
{
...
( if (data) release(data);
| if (likely(data)) release(data);
)
...
}
I wonder a bit about this analysis result because the SmPL pattern I started this discussion thread with showed a few more update candidates.
Quoted 1 line
It would be better to pick a small set of functions, and work on them carefully.
I would prefer to handle a more complete fix pattern.
By the way: I read about corresponding software update approaches in an article "Best practices for a big patch series" by Wolfram Sang.
How are the chances to resolve the message "Fatal error: exception Pcre.Error(_)" with a proposed long alternation?
Regards,
Markus
Quoted 23 lines · SF Markus Elfring
Quoted 2 lines
I don't think it is a good approach to do anything related to 5142 different functions at once.
A source code search with the following pattern found only six functions for further consideration.
@is_unnecessary_check@
expression data;
identifier work;
identifier release =~ "^kz?free$";
position pos;
type t;
@@
t work at pos(...)
{
...
( if (data) release(data);
| if (likely(data)) release(data);
)
...
}
Quoted 2 lines
I wonder a bit about this analysis result because the SmPL pattern I started this discussion thread with showed a few more update candidates.
Remember that ... matches the shortest path between what is before and what is after. So if there is another if test on the same data in the function, that will cause a failure. If yo udon't care to have this constraint, you can put when any on a ...
Quoted 4 lines
Quoted 2 lines
It would be better to pick a small set of functions, and work on them carefully.
I would prefer to handle a more complete fix pattern.
As you like, but I think that no Linux maintainer will accept a patch that makes more than a few changes, so doing them all at once is a waste of time. Anyway, you would have to split up the patches according to maintainer.
Quoted 6 lines
By the way: I read about corresponding software update approaches in an article "Best practices for a big patch series" by Wolfram Sang.
How are the chances to resolve the message "Fatal error: exception
Pcre.Error(_)" with a proposed long alternation?
Pcre is a standard library. I know nothing about its implementation. But it is not surprising that a regular expression with over 5000 options exceeds its capacity.
julia
[Cocci] Source code analysis with big regular expressions?
Quoted 3 lines
Pcre is a standard library. I know nothing about its implementation. But it is not surprising that a regular expression with over 5000 options exceeds its capacity.
Are there any chances to find the source code place from which the exception "Pcre.Error(_)" was thrown?
Regards,
Markus
[Cocci] Source code analysis with big regular expressions?
Quoted 6 lines · SF Markus Elfring
Quoted 3 lines
Pcre is a standard library. I know nothing about its implementation. But it is not surprising that a regular expression with over 5000 options exceeds its capacity.
Are there any chances to find the source code place from which the exception "
Pcre.Error(_)" was thrown?
Set the OCAMLRUNPARAM environment variable to b in your shell. I don't know if it is necessary to recompile coccinelle. Then when it crashes you will get a backtrace.
julia
[Cocci] Source code analysis with big regular expressions?
Quoted 3 lines
Set the OCAMLRUNPARAM environment variable to b in your shell. I don't know if it is necessary to recompile coccinelle. Then when it crashes you will get a backtrace.
elfring at Sonne:~/Projekte/Coccinelle/janitor> export OCAMLRUNPARAM=b && spatch --sp-file delete_unnecessary_checks2.cocci /usr/src/linux-stable/fs/btrfs/inode.cinit_defs_builtins:/usr/local/share/coccinelle/standard.h
Fatal error: exception Pcre.Error(_)
Called from file "engine.ml", line 206, characters 1-27
Called from file "engine.ml", line 359, characters 23-36
How much can this information help us here?
Regards,
Markus
[Cocci] Source code analysis with big regular expressions?
Quoted 13 lines · SF Markus Elfring
Quoted 3 lines
Set the OCAMLRUNPARAM environment variable to b in your shell. I don't know if it is necessary to recompile coccinelle. Then when it crashes you will get a backtrace.
elfring at Sonne:~/Projekte/Coccinelle/janitor> export OCAMLRUNPARAM=b && spatch --sp-file
delete_unnecessary_checks2.cocci/usr/src/linux-stable/fs/btrfs/inode.cinit_defs_builtins:/usr/local/share/coccinelle/standard.h
Fatal error: exceptionPcre.Error(_)
Called from file "engine.ml", line 206, characters 1-27
Called from file "engine.ml", line 359, characters 23-36
Quoted 1 line
How much can this information help us here?
Those two lines at least are not from Coccinelle, so I guess that they are from the PCRE implementation. But I don't think there is anything to do. The regular expression engine is just not likely to be designed to support such a large regular expression.
If you like you can give each of the function names one by one as a command line argument. Eg
spatch file.cocci file.c -D fn=whatever
and then in your semantic patch
@@
identifier virtual.fn;
@@
... use fn as an identifier ...
julia
[Cocci] Source code analysis with big regular expressions?
Quoted 2 lines
Those two lines at least are not from Coccinelle, so I guess that they are from the PCRE implementation.
Are there any chances to retrieve a more detailed error information?
Quoted 2 lines
The regular expression engine is just not likely to be designed to support such a large regular expression.
I would try to compare the processing of big patterns with similar interfaces from other software.
Quoted 2 lines
If you like you can give each of the function names one by one as a command line argument.
I imagine that this approach will result also in different opinions about a useful patch granularity.
http://lwn.net/Articles/585782/
Regards,
Markus
[Cocci] Source code analysis with big regular expressions?
Quoted 13 lines · SF Markus Elfring
Quoted 2 lines
Those two lines at least are not from Coccinelle, so I guess that they are from the PCRE implementation.
Are there any chances to retrieve a more detailed error information?
Quoted 2 lines
The regular expression engine is just not likely to be designed to support such a large regular expression.
I would try to compare the processing of big patterns with similar interfaces from other software.
Quoted 6 lines
Quoted 2 lines
If you like you can give each of the function names one by one as a command line argument.
I imagine that this approach will result also in different opinions about a useful patch granularity.
http://lwn.net/Articles/585782/
In my opinion, the change you are proposing is controversial. Particular code instances may be corrected in a better way. If you try to do everything at once then the kernel maintainer will have a big block that he has to either accept or reject. If there is one change that is not made in the best way, then he will have to reject it.
On the other hand, if you do a few things at a time, then most of the individual things you do will perhaps be noncontroversial.
julia
Quoted 4 lines
Remember that ... matches the shortest path between what is before and what is after. So if there is another if test on the same data in the function, that will cause a failure. If yo udon't care to have this constraint, you can put when any on a ...
Which SmPL "when variant" would you recommend here?
Regards,
Markus
Quoted 6 lines · SF Markus Elfring
Quoted 4 lines
Remember that ... matches the shortest path between what is before and what is after. So if there is another if test on the same data in the function, that will cause a failure. If yo udon't care to have this constraint, you can put when any on a ...
Which SmPL "when variant" would you recommend here?
when any
Quoted 4 lines
Remember that ... matches the shortest path between what is before and what is after. So if there is another if test on the same data in the function, that will cause a failure. If yo udon't care to have this constraint, you can put when any on a ...
The following pattern variant does not show a different analysis result.
@is_unnecessary_check@
expression data;
identifier work;
identifier release =~ "^kz?free$";
position pos;
type t;
@@
t work at pos(...)
{
... when any
( if (data) release(data);
| if (likely(data)) release(data);
)
... when any
}
Regards,
Markus
Quoted 2 lines
But it is not surprising that a regular expression with over 5000 options exceeds its capacity.
A source code search with the following pattern found 893 functions which check their single parameter.
@safety_check@
identifier work, input;
type data_type;
position pos;
statement is, es;
@@
void work at pos(data_type input)
{
... when any
( if (input) is else es
| if (likely(input)) is else es
)
... when any
}
Such a name list could be integrated into the following pattern variant.
@Delete_unnecessary_checks@
expression x;
identifier release =~ "^(?x)
(?:
(?:kz?|slob_)free
|
(?:
# alternation/disjunction of 893 strings ...
)
)$";
@@
-if (x)
release(x);I get an interesting result for example. Do you find it useful?
elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch.opt --sp-file delete_unnecessary_checks3.cocci /usr/src/linux-stable/fs/btrfs/inode.cinit_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/fs/btrfs/inode.c
tmp/cocci-output-5030-250c49-inode.c renamed from usr/src/linux-stable/fs/btrfs/inode.c +3 -6
@@ -819,8 +819,7 @@ static u64 get_extent_allocation_hint(st em =search_extent_mapping (em_tree,0 ,0 );if (em && em->block_start <EXTENT_MAP_LAST_BYTE ) alloc_hint = em->block_start; -if (em) -free_extent_map (em); +free_extent_map (em); }else { alloc_hint = em->block_start;free_extent_map (em);
@@ -5137,8 +5136,7 @@ static int btrfs_dentry_delete(const strstatic void btrfs_dentry_release (struct dentry *dentry) { -if (dentry->d_fsdata) -kfree (dentry->d_fsdata); +kfree (dentry->d_fsdata); } static struct dentry *btrfs_lookup(struct inode *dir, struct dentry *dentry,
@@ -6362,8 +6360,7 @@ out:trace_btrfs_get_extent (root, em); -if (path) -btrfs_free_path (path); +btrfs_free_path (path);if (trans) { ret =btrfs_end_transaction (trans, root);if (!err)
Does the following pattern variant show also around 70 update candidates on your software development system?
@is_unnecessary_check@
expression data;
identifier work;
identifier release =~ "^(?x)
(?:
# Big regular expression for a metavariable constraint ...
)$";
position pos;
type t;
@@
t work at pos(...)
{
... when any
( if (data) release(data);
| if (likely(data)) release(data);
)
... when any
}
elfring at Sonne:~/Projekte/Coccinelle/janitor> date && spatch.opt --sp-file list_functions_with_unnecessary_checks1.cocci --dir /usr/src/linux-stable > list_functions_with_unnecessary_checks1.txt 2> list_functions_with_unnecessary_checks1-errors.txt && date
Mi 26. Feb 11:38:14 CET 2014
Mi 26. Feb 12:13:47 CET 2014
The log file contains messages like 'EXN:Invalid_argument("equal: abstract value")'. Do they need further considerations?
Is this intermediate source code analysis result good enough to expand the constructive discussion to a mailing list like "kernel janitors"?
Regards,
Markus
Quoted 1 line
I get an interesting result for example. Do you find it useful?
I checks on the three examples. They seem technically correct, in that the called function does immediately do a null test on the argument value. Personally, I still think that the null test at the call site conveys useful information, so I would rather have it there, but others may think differently.
On the other hand, you should not be using linux-stable when working on the Linux kernel. Patches should apply to linux-next, ie the very latest version of all of the code.
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists. Use scripts/get_maintainers.pl in the Linux kernel to find out who to sent it to. And study the documentation on submitting patches very carefully.
Quoted 2 lines
The log file contains messages like 'EXN:Invalid_argument("equal: abstract value")'. Do they need further considerations?
This is an unfortunate constraint on the use of PCRE regular expressions. I will try to track it down. Thanks for the report.
Quoted 2 lines
Is this intermediate source code analysis result good enough to expand the constructive discussion to a mailing list like "kernel janitors"?
I don't think people on the mailing list want to discuss the issue in a general sense. They just want patches, and may comment on them.
julia
Quoted 4 lines
On the other hand, you should not be using linux-stable when working on the Linux kernel. Patches should apply to linux-next, ie the very latest version of all of the code.
The discussed semantic patches can be tried out with every version a software developer or reviewer might be interested in. I am going to retry them with the newest source files as you suggest.
Quoted 2 lines
This is an unfortunate constraint on the use of PCRE regular expressions. I will try to track it down.
Thanks for your feedback.
- Do you need any excerpt from my log files?
- Does the message 'EXN:Invalid_argument("equal: abstractvalue")' indicate that the desired source code analysis is influenced in unwanted ways?
Regards,
Markus
Quoted 4 lines
- Do you need any excerpt from my log files?
- Does the message 'EXN:Invalid_argument("equal: abstractvalue")' indicate that the desired source code analysis is influenced in unwanted ways?
No, the semantic patch should be enough to reproduce the problem. If I need more information, I will ask. The problem has no impact on the quality of the answers actually obtained.
julia
Quoted 6 lines
Quoted 3 lines
- Does the message 'EXN:Invalid_argument("equal: abstractvalue")' indicate that the desired source code analysis is influenced in unwanted ways?
No, the semantic patch should be enough to reproduce the problem. If I need more information, I will ask.
I have looked into my log files once more so that I can give you another feedback for a "regexp problem".
Quoted 1 line
The problem has no impact on the quality of the answers actually obtained.
Now I make a different observation for the processing of SmPL constraints with a long function name list in the regular expression.
elfring at Sonne:~/Projekte/Coccinelle/janitor> OCAMLRUNPARAM=b spatch.opt --sp-file delete_unnecessary_checks3.cocci /usr/src/linux-stable/fs/proc/proc_sysctl.cinit_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/fs/proc/proc_sysctl.c
tmp/cocci-output-5200-eacf04-proc_sysctl.c renamed from usr/src/linux-stable/fs/proc/proc_sysctl.c +1 -2
@@ -470,8 +470,7 @@ static struct dentry *proc_sys_lookup(std_add (dentry, inode); out: -if (h) -sysctl_head_finish (h); +sysctl_head_finish (h);sysctl_head_finish (head);return err; }
elfring at Sonne:~/Projekte/Coccinelle/janitor> OCAMLRUNPARAM=b spatch.opt --sp-file list_functions_with_unnecessary_checks1.cocci /usr/src/linux-stable/fs/proc/proc_sysctl.cinit_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/fs/proc/proc_sysctl.c
Fatal error: exception Invalid_argument("equal: abstract value") Called from file "list.ml", line 86, characters 24-34
Called from file "list.ml", line 86, characters 24-34
Called from file "list.ml", line 86, characters 24-34
Called from file "list.ml", line 57, characters 20-23
Regards,
Markus
Quoted 9 lines · SF Markus Elfring
Quoted 6 lines
Quoted 3 lines
- Does the message 'EXN:Invalid_argument("equal: abstractvalue")' indicate that the desired source code analysis is influenced in unwanted ways?
No, the semantic patch should be enough to reproduce the problem. If I need more information, I will ask.
I have looked into my log files once more so that I can give you another feedback for a "regexp problem".
I can't reproduce this. I need the semantic patch.
julia
Quoted 40 lines
Quoted 3 lines
The problem has no impact on the quality of the answers actually obtained.
Now I make a different observation for the processing of SmPL constraints with a long function name list in the regular expression.
elfring at Sonne:~/Projekte/Coccinelle/janitor> OCAMLRUNPARAM=b spatch.opt --sp-file
delete_unnecessary_checks3.cocci/usr/src/linux-stable/fs/proc/proc_sysctl.cinit_defs_builtins:/usr/local/share/coccinelle/standard.h
HANDLING:/usr/src/linux-stable/fs/proc/proc_sysctl.c
diff =tmp/cocci-output-5200-eacf04-proc_sysctl.c renamed from usr/src/linux-stable/fs/proc/proc_sysctl.c +1
-2@@ -470,8 +470,7 @@ static struct dentry *proc_sys_lookup(std_add (dentry, inode); out: -if (h) -sysctl_head_finish (h); +sysctl_head_finish (h);sysctl_head_finish (head);return err; }elfring at Sonne:~/Projekte/Coccinelle/janitor> OCAMLRUNPARAM=b spatch.opt --sp-file
list_functions_with_unnecessary_checks1.cocci/usr/src/linux-stable/fs/proc/proc_sysctl.cinit_defs_builtins:/usr/local/share/coccinelle/standard.h
HANDLING:/usr/src/linux-stable/fs/proc/proc_sysctl.c
Fatal error: exceptionInvalid_argument("equal: abstract value")Called from file "list.ml", line 86, characters 24-34
Called from file "list.ml", line 86, characters 24-34
Called from file "list.ml", line 86, characters 24-34
Called from file "list.ml", line 57, characters 20-23Regards,
Markus
Quoted 1 line
I can't reproduce this. I need the semantic patch.
How do you think about to try out the scripts which I published yesterday evening?
Regards,
Markus
[Cocci] Fix for "lexing: empty token" needed?
In reply to Julia LawallQuoted 4 lines
Quoted 2 lines
I have looked into my log files once more so that I can give you another feedback for a "regexp problem".
I can't reproduce this. I need the semantic patch.
It seems that you could fix this issue with the software release "1.0.0-rc22".
I have tried out the discussed approach on the source files for the operating system "Linux 3.16.3" once more. Now I stumble on another error message.
elfring at Sonne:~/Projekte/Coccinelle/janitor> spatch.opt --version && OCAMLRUNPARAM=b spatch.opt --sp-file list_functions_with_unnecessary_checks1.cocci /usr/src/linux-stable/crypto/fcrypt.c spatch version 1.0.0-rc22 with Python support and with PCRE supportinit_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/crypto/fcrypt.c
Fatal error: exception Failure("lexing: empty token")
Raised at file "lexing.ml", line 65, characters 15-37
Can this detail also be improved?
Regards,
Markus
Re: [PATCH with Coccinelle?] Deletion of unnecessary checks before specific function calls
In reply to Julia LawallQuoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
Hello,
A couple of functions perform input parameter validation before their implementations will try further actions with side effects. Some calling functions perform similar safety checks.
Functions which release a system resource are often documented in the way that they tolerate the passing of a null pointer for example. I do not see a need because of this fact that a function caller repeats a corresponding check.
Now I would like to propose such a change again.
1. Extension of the infrastructure for the analysis tool "coccicheck" Semantic patch patterns can help to identify update candidates also in the
Linux source file hierarchy.
2. Clarification for some automated update suggestions
My source code search approach found seventy functions at least which might
need another review and corresponding corrections for Linux 3.14-rc5. Further software development will point out even more potentially open issues.
Regards,
Markus
Re: [coccicheck Linux 3.14-rc5 PATCH 1 of 5] Deletion of unnecessary checks before specific function calls
Quoted 5 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
48c9c4f61a7d7ea98538e02631a981a429281005Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 18:15:34 +0100
Subject: [PATCH 1/5] Addition of a semantic patch file for showing unnecessary
checks before a few known functions
This semantic patch pattern tries to find source code places where a check is performed for an expression that is passed to a function (like "kfree") which checks this single parameter itself for usability. Redundant value or pointer checks can be avoided here.
The pattern contains a special comment in a regular expression for a SmPL constraint which supports extensions.
--- .../deletions/delete_unnecessary_checks_template1.cocci | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644
scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci
diff --git a/scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci b/scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci new file mode 100644
index 0000000..b092051
scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci new file +13 -0
@@ -0,0 +1,13 @@ + at Delete_unnecessary_checks@ +expression x; +identifier release =~ "^(?x) +(?: + (?:kz?|slob_)free +| + (?: +# Alternation placeholder + ) +)$"; +@@ +-if (x) + release(x);
Signature · 1 line
1.9.0
Re: [coccicheck Linux 3.14-rc5 PATCH 2 of 5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
1d2de3c3cfa43cc3c78a91200c41cef438b26a8fMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 18:38:43 +0100
Subject: [PATCH 2/5] Addition of a semantic patch file for listing of
functions that check their single parameter
This semantic patch pattern tries to find functions that check their single parameter for usability.
Example:
Null pointer checks are often performed as input parameter validation.
It uses Python statements to write information about the found source code places in a data format that is a variant of a CSV text file.
--- .../list_input_parameter_validation1.cocci | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644
scripts/coccinelle/deletions/list_input_parameter_validation1.cocci
(quoted diff) +0 -0
b/scripts/coccinelle/deletions/list_input_parameter_validation1.cocci new file mode 100644
index 0000000..b0a5a52
scripts/coccinelle/deletions/list_input_parameter_validation1.cocci new file +52 -0
52 lines not on this page · raw message
'"source file"', "line", "column")))
+ print("\r\n".join(result))
+else:
+ sys.stderr.write("No result for this analysis!\n")
Signature · 1 line
1.9.0
Re: [coccicheck Linux 3.14-rc5 PATCH 3 of 5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
f4608fceec40b2b94aa9b4abe3bbb6d98ed5eed9Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 18:58:30 +0100
Subject: [PATCH 3/5] Addition of a SQLite script for a text file import
A script was added so that a text file which was previously generated can be imported into a SQLite data base table.
http://sqlite.org/sqlite.html
The shown file name can be adjusted by a make file for example.
--- .../coccinelle/deletions/handle_function_list_template.sqlite | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644
scripts/coccinelle/deletions/handle_function_list_template.sqlite
(quoted diff) +0 -0
b/scripts/coccinelle/deletions/handle_function_list_template.sqlite new file mode 100644
index 0000000..bec366c
scripts/coccinelle/deletions/handle_function_list_template.sqlite new file +9 -0
@@ -0,0 +1,9 @@ +create table positions(function text, + data_type text, + parameter text, + source_file text, + line integer, + column integer); +.separator "|" +.import list_input_pointer_validation1.txt positions +.header OFF
Signature · 1 line
1.9.0
Re: [coccicheck Linux 3.14-rc5 PATCH 4 of 5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
e6a21b920fcca2f6f01c9528909dc036a9b3bc41Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 19:10:32 +0100
Subject: [PATCH 4/5] Addition of a semantic patch file for listing of
unnecessary checks before a few known functions
This semantic patch pattern tries to find source code places where a check is performed for an expression that is passed to a function (like "kfree") which checks this single parameter itself for usability. Redundant value or pointer checks can be avoided here.
The pattern contains a special comment in a regular expression for a SmPL constraint which supports extensions.
It uses Python statements to write information about the found places in a data format that is a variant of a CSV text file.
--- ...nctions_with_unnecessary_checks_template1.cocci | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644
scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci
diff --git a/scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci b/scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci new file mode 100644
index 0000000..d2637e8
--- /dev/null
+++b/scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci @@ -0,0 +1,59 @@
+ at initialize:python@
+@@
+import sys
+result = []
+mark = ['"', '', '"']
+delimiter = '|'
+
+def store_positions(fun, point, places):
+ """Add source code positions to an internal list."""
+ for place in places:
+ fields = []
+ fields.append(fun)
+
+ fields.append(point)
+
+ mark[1] = place.file.replace('"', '""')
+ fields.append(''.join(mark))
+
+ fields.append(place.line) + fields.append(str(int(place.column) + 1)) + result.append(delimiter.join(fields))
+
+ at is_unnecessary_check@
+expression data;
+identifier work;
+identifier release =~ "^(?x)
+(?:
+ (?:kz?|slob_)free
+|
+ (?:
+# Alternation placeholder
+ )
+)$";
+position pos;
+type t;
+@@
+ t work at pos(...)
+ {
+ ... when any
+( if (data) release(data);
+| if (likely(data)) release(data);
+)
+ ... when any
+ }
+
+ at script:python collection depends on is_unnecessary_check@ +fun << is_unnecessary_check.work;
+point << is_unnecessary_check.data;
+places << is_unnecessary_check.pos;
+@@
+store_positions(fun, point, places)
+
+@finalize:python@
+@@
+if result:
+ result.insert(0, delimiter.join(("function", '"parameter"', '"source file"',
"line", "column")))
+ print("\r\n".join(result))
+else:
+ sys.stderr.write("No result for this analysis!\n")
Signature · 1 line
1.9.0
Re: [coccicheck Linux 3.14-rc5 PATCH 5 of 5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
bedf1cb3ddd162ee3b4c31cbb98d97431f70103dMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 19:40:43 +0100
Subject: [PATCH 5/5] Addition of a make file for build automation
This script can be used to combine some input files for the desired data output which will eventually show update candidates for further source code review. Some build targets were defined. Values for the used make variables can be adjusted by parameters on the command line as usual.
A few implementation details might need more fine-tuning.
- Automatic determination of the Linux source directory from a calling make process
- Setting of an extra output directory for the generated files
--- scripts/coccinelle/deletions/makefile | 126 ++++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 scripts/coccinelle/deletions/makefile
(quoted diff) +0 -0
b/scripts/coccinelle/deletions/makefile
new file mode 100644
index 0000000..6464bae
scripts/coccinelle/deletions/makefile new file +39 -0
@@ -0,0 +1,126 @@ +SED=sed +SPATCH=spatch.opt --sp-file +RM=rm -f +LINUX_SOURCE_DIR=/usr/src/linux-stable +EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER=list_input_parameter_validation1.cocci +SQLITE=sqlite3 +SQLITE_IMPORT_SCRIPT=handle_function_list.sqlite +SQLITE_IMPORT_SCRIPT_TEMPLATE=handle_function_list_template.sqlite +RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER=list_input_parameter_validation1.txt +RESULT_SQL_DATA_BASE=result.db +RESULT_FUNCTIONS_WITH_PREFIX=add_prefix-SQL.txt +RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_LIST=list_functions_with_unnecessary_checks1.txt +RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_PATCH=functions_with_unnecessary_checks1.diff +LOG_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER=list_input_parameter_validation1-errors.txt +LOG_LIST_FUNCTIONS_WITH_UNNECESSARY_CHECKS=list_functions_with_unnecessary_checks1-errors.txt +LOG_PATCH_FUNCTIONS_WITH_UNNECESSARY_CHECKS=functions_with_unnecessary_checks1-errors.txt +LIST_PATTERN_TEMPLATE=list_functions_with_unnecessary_checks_template1.cocci +LIST_PATTERN=list_functions_with_unnecessary_checks1.cocci +PATCH_PATTERN_TEMPLATE=delete_unnecessary_checks_template1.cocci +PATCH_PATTERN=delete_unnecessary_checks1.cocci +ESCAPING=XY=$$(< $(RESULT_FUNCTIONS_WITH_PREFIX)) \ + && XY=$${XY/|/ } \ + && XY=$${XY//%/\\%} \ + && $(SED) "s%\# Alternation placeholder%$${XY//$$'\n'/$$'\\\\\n'}%" +TEXT1=A pattern file was built from which a +TEXT2=was generated. Good luck with source code review! + +default: build_update_candidate_list + +$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER): \ +$(EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) + $(SPATCH) $(EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \ +-dir $(LINUX_SOURCE_DIR) \ +> $@ 2> $(LOG_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) + +# This replacement action is needed for the use case that the corresponding +# variable was overridden. +$(SQLITE_IMPORT_SCRIPT): $(SQLITE_IMPORT_SCRIPT_TEMPLATE) + $(SED) "s%import list_input_pointer_validation1\.txt%import $(subst
%,\%,$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER))%" \
+$(SQLITE_IMPORT_SCRIPT_TEMPLATE) > $@
+
+$(RESULT_SQL_DATA_BASE) $(RESULT_FUNCTIONS_WITH_PREFIX): \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \
+$(SQLITE_IMPORT_SCRIPT)
+ @$(RM) $(RESULT_SQL_DATA_BASE)
+ $(SQLITE) -init $(SQLITE_IMPORT_SCRIPT) $(RESULT_SQL_DATA_BASE) \
+'select '\'' | '\'' || function from positions group by function order by
function desc;' \
+> $(RESULT_FUNCTIONS_WITH_PREFIX)
+
+$(LIST_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
+ $(ESCAPING) $(LIST_PATTERN_TEMPLATE) > $@
+
+$(PATCH_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
+ $(ESCAPING) $(PATCH_PATTERN_TEMPLATE) > $@
+
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_LIST): $(LIST_PATTERN)
+ $(SPATCH) $(LIST_PATTERN) -dir $(LINUX_SOURCE_DIR) \
+> $@ 2> $(LOG_LIST_FUNCTIONS_WITH_UNNECESSARY_CHECKS)
+
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_PATCH): $(PATCH_PATTERN)
+ $(SPATCH) $(PATCH_PATTERN) -dir $(LINUX_SOURCE_DIR) \
+> $@ 2> $(LOG_PATCH_FUNCTIONS_WITH_UNNECESSARY_CHECKS)
+
+build_check_list generate_list_of_functions_which_check_their_single_parameter: \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER)
+ @echo 'The list of functions which check their single parameter was generated.'
+
+build_import_script: $(SQLITE_IMPORT_SCRIPT)
+ @echo 'A script was generated which should contain appropriate parameters for
a data base.'
+
+build_data_base: $(RESULT_SQL_DATA_BASE)
+ @echo 'A SQL data base was built.'
+
+build_alternation add_prefix_to_functions: build_data_base
+ @echo 'The function name list was converted to a component for a regular
expression.'
+
+build_list_pattern: $(LIST_PATTERN)
+ @echo '$(TEXT1) list can be generated.'
+
+build_patch_pattern: $(PATCH_PATTERN)
+ @echo '$(TEXT1) patch can be generated.'
+
+build_update_candidate_list show_list_of_update_candidates: build_list_pattern \
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_LIST)
+ @echo 'The list of update candidates $(TEXT2)'
+
+build_patch show_update_suggestion: build_patch_pattern \
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_PATCH)
+ @echo 'A patch file $(TEXT2)'
+
+all: build_update_candidate_list build_patch
+
+clean:
+ $(RM) *-errors.txt \
+$(LIST_PATTERN) \
+$(PATCH_PATTERN) \
+$(RESULT_FUNCTIONS_WITH_PREFIX) \
+$(RESULT_SQL_DATA_BASE) \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \
+$(SQLITE_IMPORT_SCRIPT)
+
+delete_data_base:
+ $(RM) $(RESULT_SQL_DATA_BASE) \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER)
+
+.PHONY: all \
+build_check_list \
+build_data_base \
+build_import_script \
+build_list_pattern \
+build_patch \
+build_patch_pattern \
+build_update_candidate_list \
+clean \
+default \
+delete_data_base \
+generate_list_of_functions_which_check_their_single_parameter \
+show_list_of_update_candidates \
+show_update_suggestion
+
+
+# The following input files should not need further actions here. +$(EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \
+$(SQLITE_IMPORT_SCRIPT_TEMPLATE) \
+$(LIST_PATTERN_TEMPLATE) \
+$(PATCH_PATTERN_TEMPLATE): ;
Signature · 1 line
1.9.0
Re: [PATCH with Coccinelle?] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
Hello,
A couple of functions perform input parameter validation before their implementations will try further actions with side effects. Some calling functions perform similar safety checks.
Functions which release a system resource are occasionally documented in the way that they tolerate the passing of a null pointer for example.
I do not see a need because of this fact that a function caller repeats a corresponding check.
Now I would like to propose such a change again.
1. Extension of the infrastructure for the analysis tool "coccicheck" Semantic patch patterns can help to identify update candidates also in the
Linux source file hierarchy.
Would you like to reconsider an approach which was discussed with a subject
like "scripts/coccinelle/free: Delete NULL test before freeing functions?" a while ago?
https://lkml.org/lkml/2014/8/9/36
https://groups.google.com/d/msg/linux.kernel/rIWfYsRRW6I/cTs6y0STf2cJ
2. Clarification for some automated update suggestions
My source code search approach found 227 functions with the help of the
software "Coccinelle 1.0.0-rc22" at least which might need another review and corresponding corrections for Linux 3.16.3. Further software development will point out even more potentially open issues.
Regards,
Markus
Re: [coccicheck PATCH 1/5] Deletion of unnecessary checks before specific function calls
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
48c9c4f61a7d7ea98538e02631a981a429281005Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 18:15:34 +0100
Subject: [PATCH 1/5] Addition of a semantic patch file for showing unnecessary
checks before a few known functions
This semantic patch pattern tries to find source code places where a check is performed for an expression that is passed to a function (like "kfree") which checks this single parameter itself for usability. Redundant value or pointer checks can be avoided here.
The pattern contains a special comment in a regular expression for a SmPL constraint which supports extensions.
--- .../deletions/delete_unnecessary_checks_template1.cocci | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644
scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci
diff --git a/scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci b/scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci new file mode 100644
index 0000000..b092051
scripts/coccinelle/deletions/delete_unnecessary_checks_template1.cocci new file +13 -0
@@ -0,0 +1,13 @@ + at Delete_unnecessary_checks@ +expression x; +identifier release =~ "^(?x) +(?: + (?:kz?|slob_)free +| + (?: +# Alternation placeholder + ) +)$"; +@@ +-if (x) + release(x);
Signature · 1 line
1.9.0
Re: [coccicheck PATCH 2/5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
1d2de3c3cfa43cc3c78a91200c41cef438b26a8fMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 18:38:43 +0100
Subject: [PATCH 2/5] Addition of a semantic patch file for listing of
functions that check their single parameter
This semantic patch pattern tries to find functions that check their single parameter for usability.
Example:
Null pointer checks are often performed as input parameter validation.
It uses Python statements to write information about the found source code places in a data format that is a variant of a CSV text file.
--- .../list_input_parameter_validation1.cocci | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644
scripts/coccinelle/deletions/list_input_parameter_validation1.cocci
(quoted diff) +0 -0
b/scripts/coccinelle/deletions/list_input_parameter_validation1.cocci new file mode 100644
index 0000000..b0a5a52
scripts/coccinelle/deletions/list_input_parameter_validation1.cocci new file +52 -0
52 lines not on this page · raw message
'"source file"', "line", "column")))
+ print("\r\n".join(result))
+else:
+ sys.stderr.write("No result for this analysis!\n")
Signature · 1 line
1.9.0
Re: [coccicheck PATCH 3/5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
f4608fceec40b2b94aa9b4abe3bbb6d98ed5eed9Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 18:58:30 +0100
Subject: [PATCH 3/5] Addition of a SQLite script for a text file import
A script was added so that a text file which was previously generated can be imported into a SQLite data base table.
http://sqlite.org/sqlite.html
The shown file name can be adjusted by a make file for example.
--- .../coccinelle/deletions/handle_function_list_template.sqlite | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644
scripts/coccinelle/deletions/handle_function_list_template.sqlite
(quoted diff) +0 -0
b/scripts/coccinelle/deletions/handle_function_list_template.sqlite new file mode 100644
index 0000000..bec366c
scripts/coccinelle/deletions/handle_function_list_template.sqlite new file +9 -0
@@ -0,0 +1,9 @@ +create table positions(function text, + data_type text, + parameter text, + source_file text, + line integer, + column integer); +.separator "|" +.import list_input_pointer_validation1.txt positions +.header OFF
Signature · 1 line
1.9.0
Re: [coccicheck PATCH 4/5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
e6a21b920fcca2f6f01c9528909dc036a9b3bc41Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 19:10:32 +0100
Subject: [PATCH 4/5] Addition of a semantic patch file for listing of
unnecessary checks before a few known functions
This semantic patch pattern tries to find source code places where a check is performed for an expression that is passed to a function (like "kfree") which checks this single parameter itself for usability. Redundant value or pointer checks can be avoided here.
The pattern contains a special comment in a regular expression for a SmPL constraint which supports extensions.
It uses Python statements to write information about the found places in a data format that is a variant of a CSV text file.
--- ...nctions_with_unnecessary_checks_template1.cocci | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644
scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci
diff --git a/scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci b/scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci new file mode 100644
index 0000000..d2637e8
--- /dev/null
+++b/scripts/coccinelle/deletions/list_functions_with_unnecessary_checks_template1.cocci @@ -0,0 +1,59 @@
+ at initialize:python@
+@@
+import sys
+result = []
+mark = ['"', '', '"']
+delimiter = '|'
+
+def store_positions(fun, point, places):
+ """Add source code positions to an internal list."""
+ for place in places:
+ fields = []
+ fields.append(fun)
+
+ fields.append(point)
+
+ mark[1] = place.file.replace('"', '""')
+ fields.append(''.join(mark))
+
+ fields.append(place.line) + fields.append(str(int(place.column) + 1)) + result.append(delimiter.join(fields))
+
+ at is_unnecessary_check@
+expression data;
+identifier work;
+identifier release =~ "^(?x)
+(?:
+ (?:kz?|slob_)free
+|
+ (?:
+# Alternation placeholder
+ )
+)$";
+position pos;
+type t;
+@@
+ t work at pos(...)
+ {
+ ... when any
+( if (data) release(data);
+| if (likely(data)) release(data);
+)
+ ... when any
+ }
+
+ at script:python collection depends on is_unnecessary_check@ +fun << is_unnecessary_check.work;
+point << is_unnecessary_check.data;
+places << is_unnecessary_check.pos;
+@@
+store_positions(fun, point, places)
+
+@finalize:python@
+@@
+if result:
+ result.insert(0, delimiter.join(("function", '"parameter"', '"source file"',
"line", "column")))
+ print("\r\n".join(result))
+else:
+ sys.stderr.write("No result for this analysis!\n")
Signature · 1 line
1.9.0
Re: [coccicheck PATCH 5/5] Deletion of unnecessary checks before specific function calls
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
bedf1cb3ddd162ee3b4c31cbb98d97431f70103dMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 5 Mar 2014 19:40:43 +0100
Subject: [PATCH 5/5] Addition of a make file for build automation
This script can be used to combine some input files for the desired data output which will eventually show update candidates for further source code review. Some build targets were defined. Values for the used make variables can be adjusted by parameters on the command line as usual.
A few implementation details might need more fine-tuning.
- Automatic determination of the Linux source directory from a calling make process
- Setting of an extra output directory for the generated files
--- scripts/coccinelle/deletions/makefile | 126 ++++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 scripts/coccinelle/deletions/makefile
(quoted diff) +0 -0
b/scripts/coccinelle/deletions/makefile
new file mode 100644
index 0000000..6464bae
scripts/coccinelle/deletions/makefile new file +39 -0
@@ -0,0 +1,126 @@ +SED=sed +SPATCH=spatch.opt --sp-file +RM=rm -f +LINUX_SOURCE_DIR=/usr/src/linux-stable +EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER=list_input_parameter_validation1.cocci +SQLITE=sqlite3 +SQLITE_IMPORT_SCRIPT=handle_function_list.sqlite +SQLITE_IMPORT_SCRIPT_TEMPLATE=handle_function_list_template.sqlite +RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER=list_input_parameter_validation1.txt +RESULT_SQL_DATA_BASE=result.db +RESULT_FUNCTIONS_WITH_PREFIX=add_prefix-SQL.txt +RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_LIST=list_functions_with_unnecessary_checks1.txt +RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_PATCH=functions_with_unnecessary_checks1.diff +LOG_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER=list_input_parameter_validation1-errors.txt +LOG_LIST_FUNCTIONS_WITH_UNNECESSARY_CHECKS=list_functions_with_unnecessary_checks1-errors.txt +LOG_PATCH_FUNCTIONS_WITH_UNNECESSARY_CHECKS=functions_with_unnecessary_checks1-errors.txt +LIST_PATTERN_TEMPLATE=list_functions_with_unnecessary_checks_template1.cocci +LIST_PATTERN=list_functions_with_unnecessary_checks1.cocci +PATCH_PATTERN_TEMPLATE=delete_unnecessary_checks_template1.cocci +PATCH_PATTERN=delete_unnecessary_checks1.cocci +ESCAPING=XY=$$(< $(RESULT_FUNCTIONS_WITH_PREFIX)) \ + && XY=$${XY/|/ } \ + && XY=$${XY//%/\\%} \ + && $(SED) "s%\# Alternation placeholder%$${XY//$$'\n'/$$'\\\\\n'}%" +TEXT1=A pattern file was built from which a +TEXT2=was generated. Good luck with source code review! + +default: build_update_candidate_list + +$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER): \ +$(EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) + $(SPATCH) $(EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \ +-dir $(LINUX_SOURCE_DIR) \ +> $@ 2> $(LOG_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) + +# This replacement action is needed for the use case that the corresponding +# variable was overridden. +$(SQLITE_IMPORT_SCRIPT): $(SQLITE_IMPORT_SCRIPT_TEMPLATE) + $(SED) "s%import list_input_pointer_validation1\.txt%import $(subst
%,\%,$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER))%" \
+$(SQLITE_IMPORT_SCRIPT_TEMPLATE) > $@
+
+$(RESULT_SQL_DATA_BASE) $(RESULT_FUNCTIONS_WITH_PREFIX): \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \
+$(SQLITE_IMPORT_SCRIPT)
+ @$(RM) $(RESULT_SQL_DATA_BASE)
+ $(SQLITE) -init $(SQLITE_IMPORT_SCRIPT) $(RESULT_SQL_DATA_BASE) \
+'select '\'' | '\'' || function from positions group by function order by
function desc;' \
+> $(RESULT_FUNCTIONS_WITH_PREFIX)
+
+$(LIST_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
+ $(ESCAPING) $(LIST_PATTERN_TEMPLATE) > $@
+
+$(PATCH_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
+ $(ESCAPING) $(PATCH_PATTERN_TEMPLATE) > $@
+
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_LIST): $(LIST_PATTERN)
+ $(SPATCH) $(LIST_PATTERN) -dir $(LINUX_SOURCE_DIR) \
+> $@ 2> $(LOG_LIST_FUNCTIONS_WITH_UNNECESSARY_CHECKS)
+
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_PATCH): $(PATCH_PATTERN)
+ $(SPATCH) $(PATCH_PATTERN) -dir $(LINUX_SOURCE_DIR) \
+> $@ 2> $(LOG_PATCH_FUNCTIONS_WITH_UNNECESSARY_CHECKS)
+
+build_check_list generate_list_of_functions_which_check_their_single_parameter: \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER)
+ @echo 'The list of functions which check their single parameter was generated.'
+
+build_import_script: $(SQLITE_IMPORT_SCRIPT)
+ @echo 'A script was generated which should contain appropriate parameters for
a data base.'
+
+build_data_base: $(RESULT_SQL_DATA_BASE)
+ @echo 'A SQL data base was built.'
+
+build_alternation add_prefix_to_functions: build_data_base
+ @echo 'The function name list was converted to a component for a regular
expression.'
+
+build_list_pattern: $(LIST_PATTERN)
+ @echo '$(TEXT1) list can be generated.'
+
+build_patch_pattern: $(PATCH_PATTERN)
+ @echo '$(TEXT1) patch can be generated.'
+
+build_update_candidate_list show_list_of_update_candidates: build_list_pattern \
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_LIST)
+ @echo 'The list of update candidates $(TEXT2)'
+
+build_patch show_update_suggestion: build_patch_pattern \
+$(RESULT_FUNCTIONS_WITH_UNNECESSARY_CHECKS_AS_PATCH)
+ @echo 'A patch file $(TEXT2)'
+
+all: build_update_candidate_list build_patch
+
+clean:
+ $(RM) *-errors.txt \
+$(LIST_PATTERN) \
+$(PATCH_PATTERN) \
+$(RESULT_FUNCTIONS_WITH_PREFIX) \
+$(RESULT_SQL_DATA_BASE) \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \
+$(SQLITE_IMPORT_SCRIPT)
+
+delete_data_base:
+ $(RM) $(RESULT_SQL_DATA_BASE) \
+$(RESULT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER)
+
+.PHONY: all \
+build_check_list \
+build_data_base \
+build_import_script \
+build_list_pattern \
+build_patch \
+build_patch_pattern \
+build_update_candidate_list \
+clean \
+default \
+delete_data_base \
+generate_list_of_functions_which_check_their_single_parameter \
+show_list_of_update_candidates \
+show_update_suggestion
+
+
+# The following input files should not need further actions here. +$(EXTRACT_FUNCTIONS_THAT_CHECK_THEIR_SINGLE_PARAMETER) \
+$(SQLITE_IMPORT_SCRIPT_TEMPLATE) \
+$(LIST_PATTERN_TEMPLATE) \
+$(PATCH_PATTERN_TEMPLATE): ;
Signature · 1 line
1.9.0
Re: [PATCH 1/1] GPU-DRM-nouveau: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringQuoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
Would you like to integrate the following proposal into your source code repository?
Regards,
Markus
Quoted 1 line
From
29e61d5ccc44cd5e5961acff61b6938e0705044dMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 22 Oct 2014 15:45:22 +0200
Subject: [PATCH] GPU-DRM-nouveau: Deletion of unnecessary checks before two
function calls
A semantic patch approach was proposed with the subject "[PATCH with Coccinelle?] Deletion of unnecessary checks before specific function calls" on 2014-03-05.
https://lkml.org/lkml/2014/3/5/344
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
This patch pattern application was repeated with the help of the software "Coccinelle 1.0.0-rc22" on the source files for Linux 3.17.1. An extract of the automatically generated update suggestions is shown here.
It was determined that the affected source code places call functions which perform input parameter validation already. It is therefore not needed that a similar safety check is repeated at the call site.
--- drivers/gpu/drm/nouveau/core/core/handle.c | 3 +-- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
(quoted diff) +0 -0
b/drivers/gpu/drm/nouveau/core/core/handle.c
index a490b80..75d0c2c 100644
drivers/gpu/drm/nouveau/core/core/handle.c +0 -0
@@ -219,8 +219,7 @@ nouveau_handle_get_cinst(struct nouveau_object *engctx, u32
cinst)
void
nouveau_handle_put(struct nouveau_handle *handle) {
- if (handle)
- nouveau_namedb_put(handle);
+ nouveau_namedb_put(handle);
}
int
(quoted diff) +0 -0
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 5723807..5c29079 100644
drivers/gpu/drm/nouveau/nouveau_drm.c +1 -2
@@ -512,8 +512,7 @@ nouveau_drm_unload(struct drm_device *dev)nouveau_vga_fini (drm);nvif_device_fini (&drm->device); -if (drm->hdmi_device) -pci_dev_put (drm->hdmi_device); +pci_dev_put (drm->hdmi_device);nouveau_cli_destroy (&drm->client);return 0 ; }
Signature · 1 line
2.1.2
PATCH 1/1 GPU-DRM-nouveau: Delete unnecessary checks before two function calls
From: Markus Elfring <[email protected]>
Date: Sun, 5 Jul 2015 20:15:12 +0200
The functions nvkm_namedb_put() and pci_dev_put() test whether their argument is NULL and then return immediately.
Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +-- drivers/gpu/drm/nouveau/nvkm/core/handle.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
drivers/gpu/drm/nouveau/nouveau_drm.c +1 -2
@@ -515,8 +515,7 @@ nouveau_drm_unload(struct drm_device *dev)nouveau_vga_fini (drm);nvif_device_fini (&drm->device); -if (drm->hdmi_device) -pci_dev_put (drm->hdmi_device); +pci_dev_put (drm->hdmi_device);nouveau_cli_destroy (&drm->client);return 0 ; }
drivers/gpu/drm/nouveau/nvkm/core/handle.c +1 -2
@@ -216,6 +216,5 @@ nvkm_handle_get_cinst(struct nvkm_object *engctx, u32 cinst)void nvkm_handle_put (struct nvkm_handle *handle) { -if (handle) -nvkm_namedb_put (handle); +nvkm_namedb_put (handle); }
Signature · 1 line
2.4.5
PATCH 1/1 GPU-DRM-nouveau: Delete an unnecessary check before the function call "pci_dev_put"
From: Markus Elfring <[email protected]>
Date: Wed, 20 Jul 2016 19:43:27 +0200
The pci_dev_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_drm.c +1 -2
@@ -525,8 +525,7 @@ nouveau_drm_unload(struct drm_device *dev)nouveau_vga_fini (drm);nvif_device_fini (&drm->device); -if (drm->hdmi_device) -pci_dev_put (drm->hdmi_device); +pci_dev_put (drm->hdmi_device);nouveau_cli_destroy (&drm->client);return 0 ; }
Signature · 1 line
2.9.2
Re: [PATCH 1/1] GPU-DRM-GMA500: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringQuoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
Would you like to integrate the following proposal into your source code repository?
Regards,
Markus
Quoted 1 line
From
e61965bbcb143a54696fbd468989110519e41497Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 22 Oct 2014 18:28:12 +0200
Subject: [PATCH] GPU-DRM-GMA500: Deletion of unnecessary checks before two
function calls
A semantic patch approach was proposed with the subject "[PATCH with Coccinelle?] Deletion of unnecessary checks before specific function calls" on 2014-03-05.
https://lkml.org/lkml/2014/3/5/344
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
This patch pattern application was repeated with the help of the software "Coccinelle 1.0.0-rc22" on the source files for Linux 3.17.1. An extract of the automatically generated update suggestions is shown here.
It was determined that the affected source code places call functions which perform input parameter validation already. It is therefore not needed that a similar safety check is repeated at the call site.
--- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +-- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 +++------ drivers/gpu/drm/gma500/oaktrail_lvds.c | 3 +-- drivers/gpu/drm/gma500/psb_drv.c | 3 +-- drivers/gpu/drm/gma500/psb_intel_lvds.c | 9 +++------ 5 files changed, 9 insertions(+), 18 deletions(-)
(quoted diff) +0 -0
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 4268bf2..0d69624 100644
drivers/gpu/drm/gma500/cdv_intel_hdmi.c +1 -2
@@ -246,8 +246,7 @@ static void cdv_hdmi_destroy(struct drm_connector *connector) {struct gma_encoder *gma_encoder =gma_attached_encoder (connector); -if (gma_encoder->i2c_bus) -psb_intel_i2c_destroy (gma_encoder->i2c_bus); +psb_intel_i2c_destroy (gma_encoder->i2c_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);
(quoted diff) +0 -0
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 0b77039..8f24013 100644
drivers/gpu/drm/gma500/cdv_intel_lvds.c +0 -0
@@ -444,8 +444,7 @@ static void cdv_intel_lvds_destroy(struct drm_connector
*connector)
{
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
@@ -780,12 +779,10 @@ out:
failed_find:
mutex_unlock(&dev->mode_config.mutex);
printk(KERN_ERR "Failed find\n");
- if (gma_encoder->ddc_bus)
- psb_intel_i2c_destroy(gma_encoder->ddc_bus);
+ psb_intel_i2c_destroy(gma_encoder->ddc_bus);
failed_ddc:
printk(KERN_ERR "Failed DDC\n");
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
failed_blc_i2c:
printk(KERN_ERR "Failed BLC\n");
drm_encoder_cleanup(encoder);
(quoted diff) +0 -0
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index 0d39da6..49c5c415 100644
drivers/gpu/drm/gma500/oaktrail_lvds.c +1 -2
@@ -411,8 +411,7 @@ failed_find:mutex_unlock (&dev->mode_config.mutex);dev_dbg (dev->dev,"No LVDS modes found, disabling.\n" ); -if (gma_encoder->ddc_bus) -psb_intel_i2c_destroy (gma_encoder->ddc_bus); +psb_intel_i2c_destroy (gma_encoder->ddc_bus);/* failed_ddc: */
drivers/gpu/drm/gma500/psb_drv.c +1 -2
@@ -210,8 +210,7 @@ static int psb_driver_unload(struct drm_device *dev)iounmap (dev_priv->aux_reg); dev_priv->aux_reg =NULL ; } -if (dev_priv->aux_pdev) -pci_dev_put (dev_priv->aux_pdev); +pci_dev_put (dev_priv->aux_pdev);/* Destroy VBT data */ psb_intel_destroy_bios (dev);
(quoted diff) +0 -0
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index 88aad95..e73c3f9 100644
drivers/gpu/drm/gma500/psb_intel_lvds.c +3 -6
@@ -561,8 +561,7 @@ void psb_intel_lvds_destroy(struct drm_connector *connector)struct gma_encoder *gma_encoder =gma_attached_encoder (connector);struct psb_intel_lvds_priv *lvds_priv = gma_encoder->dev_priv; -if (lvds_priv->ddc_bus) -psb_intel_i2c_destroy (lvds_priv->ddc_bus); +psb_intel_i2c_destroy (lvds_priv->ddc_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);
@@ -834,11 +833,9 @@ out: failed_find:mutex_unlock (&dev->mode_config.mutex); -if (lvds_priv->ddc_bus) -psb_intel_i2c_destroy (lvds_priv->ddc_bus); +psb_intel_i2c_destroy (lvds_priv->ddc_bus); failed_ddc: -if (lvds_priv->i2c_bus) -psb_intel_i2c_destroy (lvds_priv->i2c_bus); +psb_intel_i2c_destroy (lvds_priv->i2c_bus); failed_blc_i2c:drm_encoder_cleanup (encoder);drm_connector_cleanup (connector);
Signature · 1 line
2.1.2
Re: [PATCH 1/1] GPU-DRM-GMA500: Deletion of unnecessary checks before two function calls
Quoted 5 lines · On Wed, 22 Oct 2014 18:48:21 +0200 SF Markus Elfring…
Quoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
Would you like to integrate the following proposal into your source code repository?
What platforms have you tested the code on at this point ?
Alan
Re: [PATCH 1/1] GPU-DRM-GMA500: Deletion of unnecessary checks before two function calls
Quoted 1 line
What platforms have you tested the code on at this point ?
None. - My "test computer" does not provide the corresponding hardware for the affected driver source files.
Regards,
Markus
PATCH 1/1 GPU-DRM-GMA500: Deletion of unnecessary checks before two function calls
I still have the hardware in use and I am willing to test.
If necessary, please send me a URL to the snapshot of the kernel with the modified code. I can compile this (takes about 8 hours ;-) on the high speed atom n2600) and run a couple of random tests, such as starting the WM, browsing some webpages, changing resolution, and run a 2D benchmark.
Greetings,
Arthur Borsboom
Quoted 9 lines · SF Markus Elfring
Quoted 1 line
What platforms have you tested the code on at this point ?
None. - My "test computer" does not provide the corresponding hardware for the
affected driver source files.Regards,
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20141026/a28726a1/attachment-0001.html>
PATCH 1/1 GPU-DRM-GMA500: Delete unnecessary checks before two function calls
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Fri, 22 Jul 2016 10:30:30 +0200
The functions pci_dev_put() and psb_intel_i2c_destroy() test whether their argument is NULL and then return immediately.
Thus the tests around their calls are not needed.
This issue was detected by using the Coccinelle software.
--- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +-- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 +++------ drivers/gpu/drm/gma500/psb_drv.c | 6 ++---- drivers/gpu/drm/gma500/psb_intel_lvds.c | 9 +++------ 4 files changed, 9 insertions(+), 18 deletions(-)
drivers/gpu/drm/gma500/cdv_intel_hdmi.c +1 -2
@@ -246,8 +246,7 @@ static void cdv_hdmi_destroy(struct drm_connector *connector) {struct gma_encoder *gma_encoder =gma_attached_encoder (connector); -if (gma_encoder->i2c_bus) -psb_intel_i2c_destroy (gma_encoder->i2c_bus); +psb_intel_i2c_destroy (gma_encoder->i2c_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);
drivers/gpu/drm/gma500/cdv_intel_lvds.c +3 -6
@@ -444,8 +444,7 @@ static void cdv_intel_lvds_destroy(struct drm_connector *connector) {struct gma_encoder *gma_encoder =gma_attached_encoder (connector); -if (gma_encoder->i2c_bus) -psb_intel_i2c_destroy (gma_encoder->i2c_bus); +psb_intel_i2c_destroy (gma_encoder->i2c_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);
@@ -780,12 +779,10 @@ out: failed_find:mutex_unlock (&dev->mode_config.mutex);printk (KERN_ERR "Failed find\n" ); -if (gma_encoder->ddc_bus) -psb_intel_i2c_destroy (gma_encoder->ddc_bus); +psb_intel_i2c_destroy (gma_encoder->ddc_bus); failed_ddc:printk (KERN_ERR "Failed DDC\n" ); -if (gma_encoder->i2c_bus) -psb_intel_i2c_destroy (gma_encoder->i2c_bus); +psb_intel_i2c_destroy (gma_encoder->i2c_bus); failed_blc_i2c:printk (KERN_ERR "Failed BLC\n" );drm_encoder_cleanup (encoder);
drivers/gpu/drm/gma500/psb_drv.c +2 -4
@@ -210,10 +210,8 @@ static int psb_driver_unload(struct drm_device *dev)iounmap (dev_priv->aux_reg); dev_priv->aux_reg =NULL ; } -if (dev_priv->aux_pdev) -pci_dev_put (dev_priv->aux_pdev); -if (dev_priv->lpc_pdev) -pci_dev_put (dev_priv->lpc_pdev); +pci_dev_put (dev_priv->aux_pdev); +pci_dev_put (dev_priv->lpc_pdev);/* Destroy VBT data */ psb_intel_destroy_bios (dev);
drivers/gpu/drm/gma500/psb_intel_lvds.c +3 -6
@@ -561,8 +561,7 @@ void psb_intel_lvds_destroy(struct drm_connector *connector)struct gma_encoder *gma_encoder =gma_attached_encoder (connector);struct psb_intel_lvds_priv *lvds_priv = gma_encoder->dev_priv; -if (lvds_priv->ddc_bus) -psb_intel_i2c_destroy (lvds_priv->ddc_bus); +psb_intel_i2c_destroy (lvds_priv->ddc_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);
@@ -835,11 +834,9 @@ out: failed_find:mutex_unlock (&dev->mode_config.mutex); -if (lvds_priv->ddc_bus) -psb_intel_i2c_destroy (lvds_priv->ddc_bus); +psb_intel_i2c_destroy (lvds_priv->ddc_bus); failed_ddc: -if (lvds_priv->i2c_bus) -psb_intel_i2c_destroy (lvds_priv->i2c_bus); +psb_intel_i2c_destroy (lvds_priv->i2c_bus); failed_blc_i2c:drm_encoder_cleanup (encoder);drm_connector_cleanup (connector);
Signature · 1 line
2.9.2
Re: [PATCH] GPU-DRM-GMA500: Delete unnecessary checks before two function calls
Quoted 10 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Fri, 22 Jul 2016 10:30:30 +0200The functions
pci_dev_put()andpsb_intel_i2c_destroy()test whether their argument is NULL and then return immediately.
Thus the tests around their calls are not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>
Two more applied. And your threading still looks funny, all the patches are in-reply to one I don't even have.
-Daniel
Quoted 98 lines
--- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +-- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 +++------ drivers/gpu/drm/gma500/psb_drv.c | 6 ++---- drivers/gpu/drm/gma500/psb_intel_lvds.c | 9 +++------ 4 files changed, 9 insertions(+), 18 deletions(-)drivers/gpu/drm/gma500/cdv_intel_hdmi.c +1
-2@@ -246,8 +246,7 @@ static void cdv_hdmi_destroy(struct drm_connector *connector) {struct gma_encoder *gma_encoder =gma_attached_encoder (connector); -if (gma_encoder->i2c_bus) -psb_intel_i2c_destroy (gma_encoder->i2c_bus); +psb_intel_i2c_destroy (gma_encoder->i2c_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);drivers/gpu/drm/gma500/cdv_intel_lvds.c +3
-6@@ -444,8 +444,7 @@ static void cdv_intel_lvds_destroy(struct drm_connector *connector) {struct gma_encoder *gma_encoder =gma_attached_encoder (connector); -if (gma_encoder->i2c_bus) -psb_intel_i2c_destroy (gma_encoder->i2c_bus); +psb_intel_i2c_destroy (gma_encoder->i2c_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);@@ -780,12 +779,10 @@ out: failed_find:mutex_unlock (&dev->mode_config.mutex);printk (KERN_ERR "Failed find\n" ); -if (gma_encoder->ddc_bus) -psb_intel_i2c_destroy (gma_encoder->ddc_bus); +psb_intel_i2c_destroy (gma_encoder->ddc_bus); failed_ddc:printk (KERN_ERR "Failed DDC\n" ); -if (gma_encoder->i2c_bus) -psb_intel_i2c_destroy (gma_encoder->i2c_bus); +psb_intel_i2c_destroy (gma_encoder->i2c_bus); failed_blc_i2c:printk (KERN_ERR "Failed BLC\n" );drm_encoder_cleanup (encoder);drivers/gpu/drm/gma500/psb_drv.c +2
-4@@ -210,10 +210,8 @@ static int psb_driver_unload(struct drm_device *dev)iounmap (dev_priv->aux_reg); dev_priv->aux_reg =NULL ; } -if (dev_priv->aux_pdev) -pci_dev_put (dev_priv->aux_pdev); -if (dev_priv->lpc_pdev) -pci_dev_put (dev_priv->lpc_pdev); +pci_dev_put (dev_priv->aux_pdev); +pci_dev_put (dev_priv->lpc_pdev);/* Destroy VBT data */ psb_intel_destroy_bios (dev);drivers/gpu/drm/gma500/psb_intel_lvds.c +3
-6@@ -561,8 +561,7 @@ void psb_intel_lvds_destroy(struct drm_connector *connector)struct gma_encoder *gma_encoder =gma_attached_encoder (connector);struct psb_intel_lvds_priv *lvds_priv = gma_encoder->dev_priv; -if (lvds_priv->ddc_bus) -psb_intel_i2c_destroy (lvds_priv->ddc_bus); +psb_intel_i2c_destroy (lvds_priv->ddc_bus);drm_connector_unregister (connector);drm_connector_cleanup (connector);kfree (connector);@@ -835,11 +834,9 @@ out: failed_find:mutex_unlock (&dev->mode_config.mutex); -if (lvds_priv->ddc_bus) -psb_intel_i2c_destroy (lvds_priv->ddc_bus); +psb_intel_i2c_destroy (lvds_priv->ddc_bus); failed_ddc: -if (lvds_priv->i2c_bus) -psb_intel_i2c_destroy (lvds_priv->i2c_bus); +psb_intel_i2c_destroy (lvds_priv->i2c_bus); failed_blc_i2c:drm_encoder_cleanup (encoder);drm_connector_cleanup (connector);Signature · 1 line
2.9.2
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 1/1] IOMMU-MSM: Deletion of unnecessary checks before the function call "clk_disable"
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
af73fb59d5d4b2c2890000fb236d0752522b6b38Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 22 Oct 2014 19:39:21 +0200
Subject: [PATCH] IOMMU-MSM: Deletion of unnecessary checks before the function
call "clk_disable"
A semantic patch approach was proposed with the subject "[PATCH with Coccinelle?] Deletion of unnecessary checks before specific function calls" on 2014-03-05.
https://lkml.org/lkml/2014/3/5/344
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
This patch pattern application was repeated with the help of the software "Coccinelle 1.0.0-rc22" on the source files for Linux 3.17.1. An extract of the automatically generated update suggestions is shown here.
It was determined that the affected source code places call functions which perform input parameter validation already. It is therefore not needed that a similar safety check is repeated at the call site.
--- drivers/iommu/msm_iommu.c | 3 +-- drivers/iommu/msm_iommu_dev.c | 6 ++---- 2 files changed, 3 insertions(+), 6 deletions(-)
drivers/iommu/msm_iommu.c +1 -2
@@ -73,8 +73,7 @@ fail:static void __disable_clocks (struct msm_iommu_drvdata *drvdata) { -if (drvdata->clk) -clk_disable (drvdata->clk); +clk_disable (drvdata->clk);clk_disable (drvdata->pclk); }
drivers/iommu/msm_iommu_dev.c +2 -4
@@ -224,8 +224,7 @@ static int msm_iommu_probe(struct platform_device *pdev)platform_set_drvdata (pdev, drvdata); -if (iommu_clk) -clk_disable (iommu_clk); +clk_disable (iommu_clk);clk_disable (iommu_pclk);
@@ -323,8 +322,7 @@ static int msm_iommu_ctx_probe(struct platform_device *pdev)SET_NSCFG (drvdata->base, mid,3 ); } -if (drvdata->clk) -clk_disable (drvdata->clk); +clk_disable (drvdata->clk);clk_disable (drvdata->pclk);dev_info (&pdev->dev,"context %s using bank %d\n" , c->name, c->num);
Signature · 1 line
2.1.2
Re: [PATCH 1/1] IOMMU-MSM: Deletion of unnecessary checks before the function call "clk_disable"
Quoted 3 lines · SF Markus Elfring
drivers/iommu/msm_iommu.c | 3 +-- drivers/iommu/msm_iommu_dev.c | 6 ++---- 2 files changed, 3 insertions(+), 6 deletions(-)
Applied to arm/msm, thanks.
PATCH 1/1 SCSI-QLA2XXX: Deletion of unnecessary checks before the function call "vfree"
In reply to SF Markus ElfringQuoted 5 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
From
ff44962f88ac2dae9324e30819629da4fb33f0ffMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 22 Oct 2014 20:40:31 +0200
Subject: [PATCH] SCSI-QLA2XXX: Deletion of unnecessary checks before the
function call "vfree"
A semantic patch approach was proposed with the subject "[PATCH with Coccinelle?] Deletion of unnecessary checks before specific function calls" on 2014-03-05.
https://lkml.org/lkml/2014/3/5/344
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
This patch pattern application was repeated with the help of the software "Coccinelle 1.0.0-rc22" on the source files for Linux 3.17.1. An extract of the automatically generated update suggestions is shown here.
It was determined that the affected source code places call functions which perform input parameter validation already. It is therefore not needed that a similar safety check is repeated at the call site.
--- drivers/scsi/qla2xxx/qla_attr.c | 6 ++---- drivers/scsi/qla2xxx/qla_init.c | 18 ++++++------------ drivers/scsi/qla2xxx/qla_os.c | 6 ++---- 3 files changed, 10 insertions(+), 20 deletions(-)
drivers/scsi/qla2xxx/qla_attr.c +0 -0
@@ -175,10 +175,8 @@ qla2x00_sysfs_write_fw_dump_template(struct file *filp,
struct kobject *kobj,
uint32_t size;
if (off == 0) {
- if (ha->fw_dump)
- vfree(ha->fw_dump);
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump);
+ vfree(ha->fw_dump_template);
ha->fw_dump = NULL;
ha->fw_dump_len = 0;
drivers/scsi/qla2xxx/qla_init.c +0 -0
@@ -5256,8 +5256,7 @@ qla24xx_load_risc_flash(scsi_qla_host_t *vha, uint32_t
*srisc_addr,
if (!IS_QLA27XX(ha))
return rval;
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5307,8 +5306,7 @@ qla24xx_load_risc_flash(scsi_qla_host_t *vha, uint32_t *srisc_addr,
default_template:
ql_log(ql_log_warn, vha, 0x0168, "Using default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5342,8 +5340,7 @@ default_template:
failed_template:
ql_log(ql_log_warn, vha, 0x016d, "Failed default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
return rval;
@@ -5559,8 +5556,7 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha, uint32_t *srisc_addr)
if (!IS_QLA27XX(ha))
return rval;
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5609,8 +5605,7 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha, uint32_t *srisc_addr)
default_template:
ql_log(ql_log_warn, vha, 0x0178, "Using default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5644,8 +5639,7 @@ default_template:
failed_template:
ql_log(ql_log_warn, vha, 0x017d, "Failed default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
return rval;
drivers/scsi/qla2xxx/qla_os.c +2 -4
@@ -3676,10 +3676,8 @@ qla2x00_free_fw_dump(struct qla_hw_data *ha)dma_free_coherent (&ha->pdev->dev,EFT_SIZE , ha->eft, ha->eft_dma); -if (ha->fw_dump) -vfree (ha->fw_dump); -if (ha->fw_dump_template) -vfree (ha->fw_dump_template); +vfree (ha->fw_dump); +vfree (ha->fw_dump_template); ha->fce =NULL ; ha->fce_dma =0 ;
Signature · 1 line
2.1.2
Re: [PATCH 1/1] SCSI-QLA2...: Deletion of unnecessary checks before the function call "vfree"
In reply to SF Markus ElfringQuoted 3 lines
Quoted 3 lines
If you are convinced that dropping the null tests is a good idea, then you can submit the patch that makes the change to the relevant maintainers and mailing lists.
I resent the request once more because another "Triple-X" software development adventure might follow ...?
Regards,
Markus
Quoted 1 line
From
ff44962f88ac2dae9324e30819629da4fb33f0ffMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Wed, 22 Oct 2014 20:40:31 +0200
Subject: [PATCH] SCSI-QLA2XXX: Deletion of unnecessary checks before the
function call "vfree"
A semantic patch approach was proposed with the subject "[PATCH with Coccinelle?] Deletion of unnecessary checks before specific function calls" on 2014-03-05.
https://lkml.org/lkml/2014/3/5/344
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
This patch pattern application was repeated with the help of the software "Coccinelle 1.0.0-rc22" on the source files for Linux 3.17.1. An extract of the automatically generated update suggestions is shown here.
It was determined that the affected source code places call functions which perform input parameter validation already. It is therefore not needed that a similar safety check is repeated at the call site.
--- drivers/scsi/qla2xxx/qla_attr.c | 6 ++---- drivers/scsi/qla2xxx/qla_init.c | 18 ++++++------------ drivers/scsi/qla2xxx/qla_os.c | 6 ++---- 3 files changed, 10 insertions(+), 20 deletions(-)
drivers/scsi/qla2xxx/qla_attr.c +0 -0
@@ -175,10 +175,8 @@ qla2x00_sysfs_write_fw_dump_template(struct file *filp,
struct kobject *kobj,
uint32_t size;
if (off == 0) {
- if (ha->fw_dump)
- vfree(ha->fw_dump);
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump);
+ vfree(ha->fw_dump_template);
ha->fw_dump = NULL;
ha->fw_dump_len = 0;
drivers/scsi/qla2xxx/qla_init.c +0 -0
@@ -5256,8 +5256,7 @@ qla24xx_load_risc_flash(scsi_qla_host_t *vha, uint32_t
*srisc_addr,
if (!IS_QLA27XX(ha))
return rval;
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5307,8 +5306,7 @@ qla24xx_load_risc_flash(scsi_qla_host_t *vha, uint32_t *srisc_addr,
default_template:
ql_log(ql_log_warn, vha, 0x0168, "Using default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5342,8 +5340,7 @@ default_template:
failed_template:
ql_log(ql_log_warn, vha, 0x016d, "Failed default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
return rval;
@@ -5559,8 +5556,7 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha, uint32_t *srisc_addr)
if (!IS_QLA27XX(ha))
return rval;
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5609,8 +5605,7 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha, uint32_t *srisc_addr)
default_template:
ql_log(ql_log_warn, vha, 0x0178, "Using default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
@@ -5644,8 +5639,7 @@ default_template:
failed_template:
ql_log(ql_log_warn, vha, 0x017d, "Failed default fwdump template\n");
- if (ha->fw_dump_template)
- vfree(ha->fw_dump_template);
+ vfree(ha->fw_dump_template);
ha->fw_dump_template = NULL;
ha->fw_dump_template_len = 0;
return rval;
drivers/scsi/qla2xxx/qla_os.c +2 -4
@@ -3676,10 +3676,8 @@ qla2x00_free_fw_dump(struct qla_hw_data *ha)dma_free_coherent (&ha->pdev->dev,EFT_SIZE , ha->eft, ha->eft_dma); -if (ha->fw_dump) -vfree (ha->fw_dump); -if (ha->fw_dump_template) -vfree (ha->fw_dump_template); +vfree (ha->fw_dump); +vfree (ha->fw_dump_template); ha->fce =NULL ; ha->fce_dma =0 ;
Signature · 1 line
2.1.2
Re: [PATCH 1/1] staging - rtl8188eu: Deletion of unnecessary checks before three function calls
In reply to SF Markus ElfringQuoted 1 line
From
45970693cad6c12da2d5ac7da3d2bd7a566170d7Mon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Thu, 23 Oct 2014 20:55:13 +0200
Subject: [PATCH] staging - rtl8188eu: Deletion of unnecessary checks before
three function calls
The functions kfree(), rtw_free_netdev() and vfree() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 5 ++--- 5 files changed, 7 insertions(+), 13 deletions(-)
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 7006088..77f7552 100644
drivers/staging/rtl8188eu/core/rtw_efuse.c +0 -0
@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16
_size_byte, u8 *pbuf)
exit:
kfree(efuseTbl);
- if (eFuseWord)
- kfree(eFuseWord);
+ kfree(eFuseWord);
}
static void efuse_read_phymap_from_txpktbuf(
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 149c271..df54350 100644
drivers/staging/rtl8188eu/core/rtw_mlme.c +1 -2
@@ -122,8 +122,7 @@ void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv)rtw_free_mlme_priv_ie_data (pmlmepriv);if (pmlmepriv) { -if (pmlmepriv->free_bss_buf) -vfree (pmlmepriv->free_bss_buf); +vfree (pmlmepriv->free_bss_buf); } }
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index e1dc8fa..af1de9c 100644
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c +1 -2
@@ -201,8 +201,7 @@ u32 _rtw_free_sta_priv(struct sta_priv *pstapriv)rtw_mfree_sta_priv_lock (pstapriv); -if (pstapriv->pallocated_stainfo_buf) -vfree (pstapriv->pallocated_stainfo_buf); +vfree (pstapriv->pallocated_stainfo_buf); }return _SUCCESS;
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 639ace0..011c9cf 100644
drivers/staging/rtl8188eu/core/rtw_xmit.c +2 -4
@@ -246,11 +246,9 @@ void _rtw_free_xmit_priv (struct xmit_priv *pxmitpriv) pxmitbuf++; } -if (pxmitpriv->pallocated_frame_buf) -vfree (pxmitpriv->pallocated_frame_buf); +vfree (pxmitpriv->pallocated_frame_buf); -if (pxmitpriv->pallocated_xmitbuf) -vfree (pxmitpriv->pallocated_xmitbuf); +vfree (pxmitpriv->pallocated_xmitbuf);/* free xmit extension buff */ pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmit_extbuf;
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 407a318..cdb70e4 100644
drivers/staging/rtl8188eu/os_dep/usb_intf.c +2 -3
@@ -456,7 +456,7 @@ free_adapter:if (status != _SUCCESS) {if (pnetdev)rtw_free_netdev (pnetdev); -else if (padapter) +else vfree (padapter); padapter =NULL ; }
@@ -487,8 +487,7 @@ static void rtw_usb_if1_deinit(struct adapter *if1)DBG_88E ("+r871xu_dev_remove, hw_init_completed=%d\n" , if1->hw_init_completed);rtw_free_drv_sw (if1); -if (pnetdev) -rtw_free_netdev (pnetdev); +rtw_free_netdev (pnetdev); } static int rtw_drv_init(struct usb_interface *pusb_intf, const struct
usb_device_id *pdid)
Signature · 1 line
2.1.2
Greg Kroah-Hartman
maintainerRe: [PATCH 1/1] staging - rtl8188eu: Deletion of unnecessary checks before three function calls
Quoted 5 lines · SF Markus Elfring
Quoted 1 line
From
45970693cad6c12da2d5ac7da3d2bd7a566170d7Mon Sep 17 00:00:00 2001From: Markus Elfring <[email protected]>
Date: Thu, 23 Oct 2014 20:55:13 +0200
Subject: [PATCH] staging - rtl8188eu: Deletion of unnecessary checks before
three function calls
Why is this here? Please use git send-email to send a patch, so I don't have to hand-edit the text in it.
Also, your Subject is a bit odd, it has a "Re:" in it for no reason, and your From: doesn't match the name you used here.
Please fix up and resend.
thanks,
greg k-h
PATCH 1/1 staging: rtl8188eu: Deletion of unnecessary checks before three function calls
The functions kfree(), rtw_free_netdev() and vfree() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 5 ++--- 5 files changed, 7 insertions(+), 13 deletions(-)
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 7006088..77f7552 100644
drivers/staging/rtl8188eu/core/rtw_efuse.c +0 -0
@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16
_size_byte, u8 *pbuf)
exit:
kfree(efuseTbl);
- if (eFuseWord)
- kfree(eFuseWord);
+ kfree(eFuseWord);
}
static void efuse_read_phymap_from_txpktbuf(
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 149c271..df54350 100644
drivers/staging/rtl8188eu/core/rtw_mlme.c +1 -2
@@ -122,8 +122,7 @@ void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv)rtw_free_mlme_priv_ie_data (pmlmepriv);if (pmlmepriv) { -if (pmlmepriv->free_bss_buf) -vfree (pmlmepriv->free_bss_buf); +vfree (pmlmepriv->free_bss_buf); } }
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index e1dc8fa..af1de9c 100644
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c +1 -2
@@ -201,8 +201,7 @@ u32 _rtw_free_sta_priv(struct sta_priv *pstapriv)rtw_mfree_sta_priv_lock (pstapriv); -if (pstapriv->pallocated_stainfo_buf) -vfree (pstapriv->pallocated_stainfo_buf); +vfree (pstapriv->pallocated_stainfo_buf); }return _SUCCESS;
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 639ace0..011c9cf 100644
drivers/staging/rtl8188eu/core/rtw_xmit.c +2 -4
@@ -246,11 +246,9 @@ void _rtw_free_xmit_priv (struct xmit_priv *pxmitpriv) pxmitbuf++; } -if (pxmitpriv->pallocated_frame_buf) -vfree (pxmitpriv->pallocated_frame_buf); +vfree (pxmitpriv->pallocated_frame_buf); -if (pxmitpriv->pallocated_xmitbuf) -vfree (pxmitpriv->pallocated_xmitbuf); +vfree (pxmitpriv->pallocated_xmitbuf);/* free xmit extension buff */ pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmit_extbuf;
(quoted diff) +0 -0
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 407a318..cdb70e4 100644
drivers/staging/rtl8188eu/os_dep/usb_intf.c +2 -3
@@ -456,7 +456,7 @@ free_adapter:if (status != _SUCCESS) {if (pnetdev)rtw_free_netdev (pnetdev); -else if (padapter) +else vfree (padapter); padapter =NULL ; }
@@ -487,8 +487,7 @@ static void rtw_usb_if1_deinit(struct adapter *if1)DBG_88E ("+r871xu_dev_remove, hw_init_completed=%d\n" , if1->hw_init_completed);rtw_free_drv_sw (if1); -if (pnetdev) -rtw_free_netdev (pnetdev); +rtw_free_netdev (pnetdev); } static int rtw_drv_init(struct usb_interface *pusb_intf, const struct
usb_device_id *pdid)
Signature · 1 line
2.1.2
Re: [PATCH resent] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
Quoted 21 lines · SF Markus Elfring
The functions
kfree(),rtw_free_netdev()andvfree()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 5 ++--- 5 files changed, 7 insertions(+), 13 deletions(-)drivers/staging/rtl8188eu/core/rtw_efuse.c +0
-0
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 · line 216
Quoted 7 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-2@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) exit:kfree (efuseTbl); -if (eFuseWord) -kfree (eFuseWord); +kfree (eFuseWord);
I think that this code has been updated already. It would be better to add labels so that kfree is only executed when needed.
julia
Quoted 85 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c +0
-0}static void efuse_read_phymap_from_txpktbuf(
drivers/staging/rtl8188eu/core/rtw_mlme.c +1
-2@@ -122,8 +122,7 @@ void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv)rtw_free_mlme_priv_ie_data (pmlmepriv);if (pmlmepriv) { -if (pmlmepriv->free_bss_buf) -vfree (pmlmepriv->free_bss_buf); +vfree (pmlmepriv->free_bss_buf); } }drivers/staging/rtl8188eu/core/rtw_sta_mgt.c +1
-2@@ -201,8 +201,7 @@ u32 _rtw_free_sta_priv(struct sta_priv *pstapriv)rtw_mfree_sta_priv_lock (pstapriv); -if (pstapriv->pallocated_stainfo_buf) -vfree (pstapriv->pallocated_stainfo_buf); +vfree (pstapriv->pallocated_stainfo_buf); }return _SUCCESS;drivers/staging/rtl8188eu/core/rtw_xmit.c +2
-4@@ -246,11 +246,9 @@ void _rtw_free_xmit_priv (struct xmit_priv *pxmitpriv) pxmitbuf++; } -if (pxmitpriv->pallocated_frame_buf) -vfree (pxmitpriv->pallocated_frame_buf); +vfree (pxmitpriv->pallocated_frame_buf); -if (pxmitpriv->pallocated_xmitbuf) -vfree (pxmitpriv->pallocated_xmitbuf); +vfree (pxmitpriv->pallocated_xmitbuf);/* free xmit extension buff */ pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmit_extbuf;drivers/staging/rtl8188eu/os_dep/usb_intf.c +2
-3@@ -456,7 +456,7 @@ free_adapter:if (status != _SUCCESS) {if (pnetdev)rtw_free_netdev (pnetdev); -else if (padapter) +else vfree (padapter); padapter =NULL ; }@@ -487,8 +487,7 @@ static void rtw_usb_if1_deinit(struct adapter *if1)DBG_88E ("+r871xu_dev_remove, hw_init_completed=%d\n" , if1->hw_init_completed);rtw_free_drv_sw (if1); -if (pnetdev) -rtw_free_netdev (pnetdev); +rtw_free_netdev (pnetdev); } static int rtw_drv_init(struct usb_interface *pusb_intf, const struct
usb_device_id*pdid)
--
2.1.2--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resent] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
Quoted 25 lines
Quoted 25 lines
The functions
kfree(),rtw_free_netdev()andvfree()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 5 ++--- 5 files changed, 7 insertions(+), 13 deletions(-)drivers/staging/rtl8188eu/core/rtw_efuse.c +0
-0@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) exit:kfree (efuseTbl);
Quoted 6 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 · line 216
Quoted 3 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-2-if (eFuseWord) -kfree (eFuseWord); +kfree (eFuseWord);I think that this code has been updated already. It would be better to add labels so that kfree is only executed when needed.
Are there any chances to achieve the suggested fine-tuning for jump labels also with another semantic patch approach?
Regards,
Markus
Re: [PATCH resent] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
Quoted 32 lines · SF Markus Elfring
Quoted 25 lines
Quoted 25 lines
The functions
kfree(),rtw_free_netdev()andvfree()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 5 ++--- 5 files changed, 7 insertions(+), 13 deletions(-)drivers/staging/rtl8188eu/core/rtw_efuse.c +0
-0@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) exit:kfree (efuseTbl);Quoted 6 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 · line 216
Quoted 3 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-2-if (eFuseWord) -kfree (eFuseWord); +kfree (eFuseWord);I think that this code has been updated already. It would be better to add labels so that kfree is only executed when needed.
Quoted 2 lines
Are there any chances to achieve the suggested fine-tuning for jump labels also with another semantic patch approach?
No, I don't think so. The pattern is not regular enough.
julia
Re: [PATCH with SmPL?] staging: rtl8188eu: Adjustments around jump labels
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Review efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 · line 216
Quoted 8 lines
(quoted diff) +1
-2@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) exit: kfree(efuseTbl); - if (eFuseWord) - kfree(eFuseWord); + kfree(eFuseWord);I think that this code has been updated already. It would be better to add labels so that kfree is only executed when needed.
Quoted 4 lines
Quoted 2 lines
Are there any chances to achieve the suggested fine-tuning for jump labels also with another semantic patch approach?
No, I don't think so. The pattern is not regular enough.
Now I have got a different impression for corresponding improvement possibilities.
elfring at Sonne:~/Projekte/Linux/stable-patched> spatch.opt -debug -sp-file ~/Projekte/Coccinelle/janitor/move_function_call_before_jump_label1.cocci drivers/staging/rtl8188eu/core/rtw_efuse.cinit_defs_builtins: /usr/local/share/coccinelle/standard.h
-----------------------------------------------------------------------
processing semantic patch file: /home/elfring/Projekte/Coccinelle/janitor/move_function_call_before_jump_label1.cocci
with isos from: /usr/local/share/coccinelle/standard.iso
-----------------------------------------------------------------------
@move_function_call_before_jump_label@
expression x;
identifier fu, label;
type t;
@@
t fu(...)
{
... when any
x = kzalloc(...);
if (x == NULL) {
...
goto label; }
... when any
+ kfree(x);
label:
- kfree(x);
...
}
HANDLING: drivers/staging/rtl8188eu/core/rtw_efuse.c
-----------------------------------------------------------------------
let's go
-----------------------------------------------------------------------
-----------------------------------------------------------------------
-----------------------------------------------------------------------move_function_call_before_jump_label =
-----------------------------------------------------------------------
dependencies for rule move_function_call_before_jump_label satisfied:
binding in = []
binding relevant in = []
(ONCE) USING optional_storage builtin isomorphism
transformation info returned:
transform state: 5
with rule_elem:
<<< kfree(move_function_call_before_jump_label:x);
move_function_call_before_jump_label:label:
with binding: [move_function_call_before_jump_label.x --> efuseTbl]
transform state: 204
with rule_elem: -kfree-(-move_function_call_before_jump_label:x-)-; with binding: [move_function_call_before_jump_label.x --> efuseTbl]
binding out = []
transform one node: 204
transform one node: 5
-----------------------------------------------------------------------
Finished
-----------------------------------------------------------------------
tmp/cocci-output-4498-349827-rtw_efuse.c renamed from staging/rtl8188eu/core/rtw_efuse.c +1 -1
@@ -209,8 +209,8 @@ efuse_phymap_to_logical(u8 *phymap, u16/* 5. Calculate Efuse utilization. */ /* */ +kfree (efuseTbl); exit: -kfree (efuseTbl);kfree (eFuseWord); }
Check duplication for 1 files
Can my update suggestion be generalised a bit more for the movement of specific jump labels towards the end of a function implementation like in the use case "efuse_phymap_to_logical()"?
Regards,
Markus
v2 cover staging: rtl8188eu: Deletion of a few unnecessary checks
In reply to Julia LawallFrom: Markus Elfring <[email protected]>
Date: Wed, 12 Nov 2014 20:42:18 +0100
Another update suggestion was taken into account after patches were applied from static source code analysis.
Markus Elfring (2):
staging: rtl8188eu: Deletion of unnecessary checks before three
function calls
staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
drivers/staging/rtl8188eu/core/rtw_efuse.c | 13 ++++++++----- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 6 +++--- 5 files changed, 15 insertions(+), 16 deletions(-)
Signature · 1 line
2.1.3
PATCH v2 1/2 staging: rtl8188eu: Deletion of unnecessary checks before three function calls
From: Markus Elfring <[email protected]>
Date: Wed, 12 Nov 2014 20:25:49 +0100
The functions kfree(), rtw_free_netdev() and vfree() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 6 +++--- 5 files changed, 8 insertions(+), 13 deletions(-)
drivers/staging/rtl8188eu/core/rtw_efuse.c +1 -2
@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) exit:kfree (efuseTbl); -if (eFuseWord) -kfree (eFuseWord); +kfree (eFuseWord); } static void efuse_read_phymap_from_txpktbuf(
drivers/staging/rtl8188eu/core/rtw_mlme.c +1 -2
@@ -122,8 +122,7 @@ void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv)rtw_free_mlme_priv_ie_data (pmlmepriv);if (pmlmepriv) { -if (pmlmepriv->free_bss_buf) -vfree (pmlmepriv->free_bss_buf); +vfree (pmlmepriv->free_bss_buf); } }
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c +1 -2
@@ -201,8 +201,7 @@ u32 _rtw_free_sta_priv(struct sta_priv *pstapriv)rtw_mfree_sta_priv_lock (pstapriv); -if (pstapriv->pallocated_stainfo_buf) -vfree (pstapriv->pallocated_stainfo_buf); +vfree (pstapriv->pallocated_stainfo_buf); }return _SUCCESS;
drivers/staging/rtl8188eu/core/rtw_xmit.c +2 -4
@@ -246,11 +246,9 @@ void _rtw_free_xmit_priv (struct xmit_priv *pxmitpriv) pxmitbuf++; } -if (pxmitpriv->pallocated_frame_buf) -vfree (pxmitpriv->pallocated_frame_buf); +vfree (pxmitpriv->pallocated_frame_buf); -if (pxmitpriv->pallocated_xmitbuf) -vfree (pxmitpriv->pallocated_xmitbuf); +vfree (pxmitpriv->pallocated_xmitbuf);/* free xmit extension buff */ pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmit_extbuf;
drivers/staging/rtl8188eu/os_dep/usb_intf.c +3 -3
@@ -456,8 +456,9 @@ free_adapter:if (status != _SUCCESS) {if (pnetdev)rtw_free_netdev (pnetdev); -else if (padapter) +else vfree (padapter); + padapter =NULL ; } exit:
@@ -487,8 +488,7 @@ static void rtw_usb_if1_deinit(struct adapter *if1)DBG_88E ("+r871xu_dev_remove, hw_init_completed=%d\n" , if1->hw_init_completed);rtw_free_drv_sw (if1); -if (pnetdev) -rtw_free_netdev (pnetdev); +rtw_free_netdev (pnetdev); }static int rtw_drv_init (struct usb_interface *pusb_intf,const struct usb_device_id *pdid)
Signature · 1 line
2.1.3
Re: [PATCH v2 1/2] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
drivers/staging/rtl8188eu/os_dep/usb_intf.c static void rtw_usb_if1_deinit(struct adapter *if1) · line 491
Quoted 7 lines · SF Markus Elfring
drivers/staging/rtl8188eu/os_dep/usb_intf.c +1
-2@@ -487,8 +488,7 @@ static void rtw_usb_if1_deinit(struct adapter *if1)DBG_88E ("+r871xu_dev_remove, hw_init_completed=%d\n" , if1->hw_init_completed);rtw_free_drv_sw (if1); -if (pnetdev) -rtw_free_netdev (pnetdev); +rtw_free_netdev (pnetdev);
I still feel that hiding the if statement inside the function call makes the code more subtle and it is a bad harmful thing to do. This is especially true if you have trained yourself to know that free_netdev() can't accept NULL pointers.
regards,
dan carpenter
Re: [PATCH v2 1/2] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
Quoted 10 lines
drivers/staging/rtl8188eu/os_dep/usb_intf.c static void rtw_usb_if1_deinit(struct adapter *if1) · line 491
Quoted 7 lines
drivers/staging/rtl8188eu/os_dep/usb_intf.c +1
-2@@ -487,8 +488,7 @@ static void rtw_usb_if1_deinit(struct adapter *if1)DBG_88E ("+r871xu_dev_remove, hw_init_completed=%d\n" , if1->hw_init_completed);rtw_free_drv_sw (if1); -if (pnetdev) -rtw_free_netdev (pnetdev); +rtw_free_netdev (pnetdev);I still feel that hiding the if statement inside the function call makes the code more subtle and it is a bad harmful thing to do.
I find your feedback interesting.
Quoted 2 lines
This is especially true if you have trained yourself to know that
free_netdev()can't accept NULL pointers.
Do you need to adjust your concerns a bit over time when function variants provide a corresponding safety check in their implementations?
Regards,
Markus
Re: [PATCH v2 1/2] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
Quoted 5 lines
Quoted 2 lines
This is especially true if you have trained yourself to know that
free_netdev()can't accept NULL pointers.Do you need to adjust your concerns a bit over time when function variants provide a corresponding safety check in their implementations?
There would not seem to be any _need_ to do so. An unnecessary null test is always safe. The only real problem that I can see with an unnecessary null test in error handling code (intrinsically not critical performance wise) is if it gives the illusion that a value can be null when it cannot.
julia
Re: [PATCH v2 1/2] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
In reply to SF Markus ElfringQuoted 5 lines · SF Markus Elfring
Quoted 2 lines
This is especially true if you have trained yourself to know that
free_netdev()can't accept NULL pointers.Do you need to adjust your concerns a bit over time when function variants provide a corresponding safety check in their implementations?
No. Really, free_netdev vs rtw_free_netdev is just an example where it is really bad, but I feel that all of these patches are misguided and harmful.
We should have an if statement if the allocation is optional, we should not have an if statement if the allocation is required.
regards,
dan carpenter
Re: [PATCH v2 1/2] staging: rtl8188eu: Deletion of unnecessary checks before three function calls
In reply to SF Markus ElfringQuoted 23 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Wed, 12 Nov 2014 20:25:49 +0100The functions
kfree(),rtw_free_netdev()andvfree()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 3 +-- drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++---- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 6 +++--- 5 files changed, 8 insertions(+), 13 deletions(-)drivers/staging/rtl8188eu/core/rtw_efuse.c +0
-0
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) · line 216
Quoted 7 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-2@@ -212,8 +212,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) exit:kfree (efuseTbl); -if (eFuseWord) -kfree (eFuseWord); +kfree (eFuseWord); }
As far as I can tell, the 2/2 patch in this series proposes a completely different fix for this code. When you send a series, patch n+1/m is supposed to apply to the result of patch n/m.
In any case, you can let this one go, because the problem has been fixed already.
julia
PATCH v2 2/2 staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Wed, 12 Nov 2014 20:40:12 +0100
Memory releases were handled in an inefficient way by the implementation of the efuse_phymap_to_logical() function in case of an allocation failure. The corresponding clean-up was improved by reordering of kfree() calls and a few adjustments for jump labels.
--- drivers/staging/rtl8188eu/core/rtw_efuse.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/staging/rtl8188eu/core/rtw_efuse.c +8 -4
@@ -112,7 +112,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) eFuseWord = (u16 **)rtw_malloc2d (EFUSE_MAX_SECTION_88E ,EFUSE_MAX_WORD_UNIT ,sizeof (u16));if (eFuseWord ==NULL ) {DBG_88E ("%s: alloc eFuseWord fail!\n" , __func__); - goto exit; + goto cleanup1; }/* 0. Refresh efuse init map as all oxFF. */
@@ -130,7 +130,7 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) eFuse_Addr++; }else {DBG_88E ("EFUSE is empty efuse_Addr-%d efuse_data =%x\n" , eFuse_Addr, rtemp8); - goto exit; + goto cleanup2; }/* */
@@ -209,10 +209,14 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf)/* 5. Calculate Efuse utilization. */ /* */ -exit: +cleanup2: +kfree (eFuseWord); + +cleanup1:kfree (efuseTbl); -kfree (eFuseWord); +exit: + ; } static void efuse_read_phymap_from_txpktbuf(
Signature · 1 line
2.1.3
Re: [PATCH v2 2/2] staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
Quoted 1 line · SF Markus Elfring
From: Markus Elfring <[email protected]>
Please fix your email client instead.
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) · line 115
Quoted 1 line
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-0+ goto cleanup1;
1) Don't use GW-BASIC label names. Label names should reflect what the label does such as free_fuse_word or free_fuse_tabel.
2) Don't use do-nothing labels. Just return directly.
regards,
dan carpenter
Re: [PATCH v2 2/2] staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
Quoted 6 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) · line 115
Quoted 1 line
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-0+ goto cleanup1;1) Don't use GW-BASIC label names. Label names should reflect what the label does such as
free_fuse_wordorfree_fuse_tabel.2) Don't use do-nothing labels. Just return directly.
Does the document "CodingStyle" need any extensions for special cases? Are there any update candidates in the chapter "7: Centralized exiting of functions"?
Regards,
Markus
Re: [PATCH v2 2/2] staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
Quoted 8 lines · SF Markus Elfring
Quoted 6 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) · line 115
Quoted 1 line
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-0+ goto cleanup1;1) Don't use GW-BASIC label names. Label names should reflect what the label does such as
free_fuse_wordorfree_fuse_tabel.2) Don't use do-nothing labels. Just return directly.
Does the document "CodingStyle" need any extensions for special cases?
I don't understand.
Quoted 1 line
Are there any update candidates in the chapter "7: Centralized exiting of functions"?
CodingStyle says:
"If there is no cleanup needed then just return directly."
What is not clear about that?
regards,
dan carpenter
Re: [PATCH v2 2/2] staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
Quoted 10 lines
Quoted 8 lines
Quoted 6 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) · line 115
Quoted 1 line
drivers/staging/rtl8188eu/core/rtw_efuse.c +1
-0+ goto cleanup1;1) Don't use GW-BASIC label names. Label names should reflect what the label does such as
free_fuse_wordorfree_fuse_tabel.2) Don't use do-nothing labels. Just return directly.
Does the document "CodingStyle" need any extensions for special cases?
I don't understand.
Should the naming convention become more explicit for jump labels?
Quoted 3 lines
CodingStyle says:
"If there is no cleanup needed then just return directly."
Do you want that I send another update suggestion with other corrections for jump labels in the affected function implementation?
Regards,
Markus
Re: [PATCH v2 2/2] staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
In reply to SF Markus ElfringQuoted 4 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c +0
-0
[...]
drivers/staging/rtl8188eu/core/rtw_efuse.c efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 _size_byte, u8 *pbuf) · line 220
Quoted 11 lines
drivers/staging/rtl8188eu/core/rtw_efuse.c +6
-2-exit: +cleanup2: +kfree (eFuseWord); + +cleanup1:kfree (efuseTbl); -kfree (eFuseWord); +exit: + ; }
You are not using the most recent version of the code. The issue has already been fixed. Concretely, this part of the function now reads:
exit:
kfree(eFuseWord);
eFuseWord_failed:
kfree(efuseTbl);
julia
Re: [PATCH v2 2/2] staging: rtl8188eu: Better memory clean-up in efuse_phymap_to_logical()
Quoted 2 lines
You are not using the most recent version of the code. The issue has already been fixed.
Thanks for your reminder.
Regards,
Markus
PATCH 1/1 staging: rtl8188eu: Delete an unnecessary check before the function call "vfree"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Mon, 25 Jul 2016 22:20:24 +0200
The vfree() function performs also input parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/staging/rtl8188eu/core/rtw_xmit.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/staging/rtl8188eu/core/rtw_xmit.c +1 -4
@@ -252,10 +252,7 @@ void _rtw_free_xmit_priv(struct xmit_priv *pxmitpriv) pxmitbuf++; } -if (pxmitpriv->pallocated_xmit_extbuf) { -vfree (pxmitpriv->pallocated_xmit_extbuf); - } - +vfree (pxmitpriv->pallocated_xmit_extbuf);rtw_free_hwxmits (padapter);mutex_destroy (&pxmitpriv->ack_tx_mutex);
Signature · 1 line
2.9.2
Re: [PATCH 1/1] s390/net: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringThe functions debug_unregister() and kfree_fsm() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/s390/net/claw.c | 6 ++---- drivers/s390/net/ctcm_main.c | 6 ++---- drivers/s390/net/lcs.c | 6 ++---- drivers/s390/net/netiucv.c | 12 ++++-------- 4 files changed, 10 insertions(+), 20 deletions(-)
drivers/s390/net/claw.c +2 -4
@@ -109,10 +109,8 @@ static debug_info_t *claw_dbf_trace;static void claw_unregister_debug_facility (void ) { -if (claw_dbf_setup) -debug_unregister (claw_dbf_setup); -if (claw_dbf_trace) -debug_unregister (claw_dbf_trace); +debug_unregister (claw_dbf_setup); +debug_unregister (claw_dbf_trace); } static int
drivers/s390/net/ctcm_main.c +2 -4
@@ -1074,8 +1074,7 @@ static void ctcm_free_netdevice(struct net_device *dev)if (priv) { grp = priv->mpcg;if (grp) { -if (grp->fsm) -kfree_fsm (grp->fsm); +kfree_fsm (grp->fsm);if (grp->xid_skb)dev_kfree_skb (grp->xid_skb);if (grp->rcvd_xid_skb)
@@ -1672,8 +1671,7 @@ static int ctcm_shutdown_device(struct ccwgroup_device *cgdev)ctcm_free_netdevice (dev); } -if (priv->fsm) -kfree_fsm (priv->fsm); +kfree_fsm (priv->fsm);ccw_device_set_offline (cgdev->cdev[1 ]);ccw_device_set_offline (cgdev->cdev[0 ]);
drivers/s390/net/lcs.c +2 -4
@@ -88,10 +88,8 @@ static debug_info_t *lcs_dbf_trace;static void lcs_unregister_debug_facility (void ) { -if (lcs_dbf_setup) -debug_unregister (lcs_dbf_setup); -if (lcs_dbf_trace) -debug_unregister (lcs_dbf_trace); +debug_unregister (lcs_dbf_setup); +debug_unregister (lcs_dbf_trace); } static int
drivers/s390/net/netiucv.c +4 -8
@@ -487,12 +487,9 @@ DEFINE_PER_CPU(char[256], iucv_dbf_txt_buf);static void iucv_unregister_dbf_views (void ) { -if (iucv_dbf_setup) -debug_unregister (iucv_dbf_setup); -if (iucv_dbf_data) -debug_unregister (iucv_dbf_data); -if (iucv_dbf_trace) -debug_unregister (iucv_dbf_trace); +debug_unregister (iucv_dbf_setup); +debug_unregister (iucv_dbf_data); +debug_unregister (iucv_dbf_trace); }static int iucv_register_dbf_views (void ) {
@@ -1975,8 +1972,7 @@ static void netiucv_free_netdevice(struct net_device *dev)if (privptr) {if (privptr->conn)netiucv_remove_connection (privptr->conn); -if (privptr->fsm) -kfree_fsm (privptr->fsm); +kfree_fsm (privptr->fsm); privptr->conn =NULL ; privptr->fsm =NULL ;/* privptr gets freed by free_netdev() */ }
Signature · 1 line
2.1.3
Re: [PATCH 1/1] s390/net: Deletion of unnecessary checks before two function calls
This one is buggy.
I'm sorry, but please stop sending these.
For kfree(), at least we all know that kfree() accepts NULL pointer. But for this one:
1) I don't know what the functions do so I have to look at the code.
2) It's in a arch that I don't compile so cscope isn't set up meaning it's hard to find the functions.
You're sending a lot of patches and they are all hard to review and some of them are buggy and none of them really add any value. It's a waste of your time and it's a waste of my time.
regards,
dan carpenter
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 1 line
This one is buggy.
I am still interested to clarify this opinion a bit more.
Quoted 1 line
I'm sorry, but please stop sending these.
I am going to improve more implementation details in affected source files.
Quoted 2 lines
But for this one:
1) I don't know what the functions do so I have to look at the code.
I hope that static source code analysis can help here.
Quoted 2 lines
2) It's in a arch that I don't compile so cscope isn't set up meaning it's hard to find the functions.
Do you find the Coccinelle software also useful for your area?
Quoted 2 lines
You're sending a lot of patches and they are all hard to review and some of them are buggy and none of them really add any value.
Thanks for your feedback.
The suggested source code clean-up might result in a measurable effect depending on the call frequency for the changed functions. Can I help you in any ways to make corresponding review easier?
Quoted 1 line
It's a waste of your time and it's a waste of my time.
It can be your choice to reject my update suggestion.
Regards,
Markus
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 4 lines · SF Markus Elfring
Quoted 1 line
This one is buggy.
I am still interested to clarify this opinion a bit more.
After your patch then it will print warning messages.
The truth is I think that all these patches are bad and they make the code harder to read.
Before: The code is clear and there is no NULL dereference.
After: You have to remember that rtw_free_netdev() accepts NULL
pointers but free_netdev() does not accept NULL pointers.
The if statements are there for *human* readers to understand and you are making it harder for humans to understand the code.
Even for kfree(), just removing the if statement is not really the right fix. We do it because everyone knows kfree(), but what Julia Lawall said is the real correct way change the code and make it simpler for people to understand:
https://lkml.org/lkml/2014/10/31/452
I know it's fun to send automated patches but these make the code worse and they waste reviewer time.
regards,
dan carpenter
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 1 line
After your patch then it will print warning messages.
To which messages do you refer to?
Quoted 4 lines
The truth is I think that all these patches are bad and they make the code harder to read.
Before: The code is clear and there is no NULL dereference.
Where do you stumble on a null pointer access?
Quoted 2 lines
After: You have to remember that
rtw_free_netdev()accepts NULL
pointers butfree_netdev()does not accept NULL pointers.
Are any improvements needed for the corresponding documentation to make it better accessible besides the source code?
Quoted 2 lines
The if statements are there for *human* readers to understand and you are making it harder for humans to understand the code.
Is there a target conflict between source code understandability and software efficiency?
Quoted 6 lines
Even for
kfree(), just removing the if statement is not really the right fix. We do it because everyone knowskfree(), but what Julia Lawall said is the real correct way change the code and make it simpler for people to understand:
You refer to another update suggestion for the software area "staging: rtl8188eu".
Do you find adjustments for jump labels easier to accept than the simple deletion of specific null pointer checks?
Quoted 2 lines
I know it's fun to send automated patches but these make the code worse and they waste reviewer time.
I hope that small automated changes can also help to improve affected source files.
Regards,
Markus
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 6 lines
Quoted 3 lines
After your patch then it will print warning messages.
After: You have to remember thatrtw_free_netdev()accepts NULL
pointers butfree_netdev()does not accept NULL pointers.Are any improvements needed for the corresponding documentation to make it better accessible besides the source code?
When people are writing or reading code, they will not necessarily look at the documentation for every function that they use.
Quoted 5 lines
Quoted 2 lines
The if statements are there for *human* readers to understand and you are making it harder for humans to understand the code.
Is there a target conflict between source code understandability and software efficiency?
Efficiency is not an issue. This code is all in rare error handling paths or in service removal functions. None of it is in a critical path. What is important is to be able to easily check that what needs to be done is actually done. Removing null tests makes it more obscure what needs to be done, because it means that the conditions under which a function needs to be called (which may be different than the conditions under which it can be called) are less apparent.
julia
Re: s390/net: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringQuoted 4 lines · SF Markus Elfring
Quoted 1 line
After your patch then it will print warning messages.
To which messages do you refer to?
Open your eyeballs up and read the code.
Quoted 8 lines
Quoted 5 lines
The truth is I think that all these patches are bad and they make the code harder to read.
Before: The code is clear and there is no NULL dereference.
Where do you stumble on a null pointer access?
I'm not talking about bugs, I'm talking about code clarity. Before is more clear than after.
Quoted 7 lines
Quoted 3 lines
After: You have to remember that
rtw_free_netdev()accepts NULL
pointers butfree_netdev()does not accept NULL pointers.Are any improvements needed for the corresponding documentation to make it better accessible besides the source code?
Documentation doesn't reduce the number of things to remember it just documents it. Meanwhile if we leave the code as-is there is no need for documentation because the code is clear.
Quoted 6 lines
Quoted 3 lines
The if statements are there for *human* readers to understand and you are making it harder for humans to understand the code.
Is there a target conflict between source code understandability and software efficiency?
If you can benchmark the code and the new code is faster then, yes, this patch is good and we will apply it. If you have no benchmarks then do not send the patch.
Quoted 6 lines
Quoted 6 lines
Even for
kfree(), just removing the if statement is not really the right fix. We do it because everyone knowskfree(), but what Julia Lawall said is the real correct way change the code and make it simpler for people to understand:
Quoted 6 lines
Quoted 1 line
You refer to another update suggestion for the software area "staging: rtl8188eu".
Do you find adjustments for jump labels easier to accept than the simple deletion of specific null pointer checks?
Yes.
Quoted 7 lines
Quoted 4 lines
I know it's fun to send automated patches but these make the code worse and they waste reviewer time.
I hope that small automated changes can also help to improve affected source files.
No. The changes make the code less clear.
regards,
dan carpenter
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 2 lines
If you can benchmark the code and the new code is faster then, yes, this patch is good and we will apply it.
I guess that I do not have enough resources myself to measure different run time effects in a S390 environment.
Quoted 1 line
If you have no benchmarks then do not send the patch.
Are other software developers and testers eventually interested to try a few pointer check adjustments out a bit more?
Regards,
Markus
[Cocci] s390/net: Deletion of unnecessary checks before two function calls
In reply to Dan CarpenterDan
Quoted 2 lines
The truth is I think that all these patches are bad and they make the code harder to read.
I disagree, I think the code requires less effort to read without the if test.
A developer reading the code will wonder why kfree does not handle the case when its argument is NULL. This takes effort.
Now there might be a reason while kfree (or any other function) does not handle NULL, in which case the test is necessary for that reason. Or perhaps calling kfree has other consequences and this means it is good to minimise the number of calls, fair enough.
Quoted 2 lines
The if statements are there for *human* readers to understand and you are making it harder for humans to understand the code.
The reverse is true.
But if there are other reasons, then leave the test in.
Signature · 3 lines
Derek M. Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd blog:shape-of-code.coding-guidelines.com Software analysis http://www.knosof.co.uk
[Cocci] s390/net: Deletion of unnecessary checks before two function calls
Quoted 8 lines · Derek M Jones
Dan
Quoted 2 lines
The truth is I think that all these patches are bad and they make the code harder to read.
I disagree, I think the code requires less effort to read without the if test.
Quoted 7 lines
A developer reading the code will wonder why kfree does not handle the case when its argument is NULL. This takes effort.
Now there might be a reason while kfree (or any other function) does not handle NULL, in which case the test is necessary for that reason. Or perhaps calling kfree has other consequences and this means it is good to minimise the number of calls, fair enough.
This may be true in general, but the standard assumption about kernel functions is that they are not defensive. Everything used in the kernel is defined in the kernel, and is normally written in a way to be optimal for in-kernel usage.
Quoted 6 lines
Quoted 2 lines
The if statements are there for *human* readers to understand and you are making it harder for humans to understand the code.
The reverse is true.
But if there are other reasons, then leave the test in.
The point about a null test is that it makes it apparent at the current point that the value can be null. The default assumption is that it cannot, ie that functions are only called when doing so is useful.
Actually, this assumption can be exploited by automatic tools for finding out what needs to be done when:
Suman Saha, Jean-Pierre Lozi, Ga?l Thomas, Julia L. Lawall, Gilles Muller:
Hector: Detecting Resource-Release Omission Faults in error-handling code for systems software. DSN 2013: 1-12
The point is that Linux code contains a huge number of alloc and free functions, many of which are not very well known. If free functions are only called when they are useful, then you can infer which free functions go with which alloc functions. If all free functions are just lumped together and called at random, then you lose a lot of information.
Similarly, as a human, when I look at code I don't know, it is very confusing to have functions called when as far as I can tell they don't need to be. A bunch of validity tests at the beginning of the called function doesn't really help, because as Dan points out the code is not always easy to find, and in the function definition itself one doesn't know in what contexts that code is intended to be used.
In separate cleanup functions (destroy_xxx) perhaps the tests are more or less noise. But in the error handling code of an initialization function, no test means to me that the call is needed at the current point, and a test means to me that for some reason it is not statically known whether a call is needed or not. This is information that is really useful for understanding the code, for both humans and for tools.
julia
[Cocci] Are defensive checks treated differently in specific areas?
In reply to Derek M JonesQuoted 8 lines
Quoted 2 lines
The truth is I think that all these patches are bad and they make the code harder to read.
I disagree, I think the code requires less effort to read without the if test.
A developer reading the code will wonder why kfree does not handle the case when its argument is NULL. This takes effort.
Does it make a difference for you where such safety checks should be finally placed in the source code?
Do you consider different assumptions for function implementations from an operating system in comparison to user applications?
How much will corresponding expectations need adjustments with the software evolution?
Regards,
Markus
Re: [PATCH 1/1] s390/net: Deletion of unnecessary checks before two function calls
In reply to Dan CarpenterI went digging through some of Markus's old patch history, and noticed this...
Quoted 3 lines · Dan Carpenter
This one is buggy.
I'm sorry, but please stop sending these.
I'm tending to concur.
Quoted 9 lines
For
kfree(), at least we all know thatkfree()accepts NULL pointer. But for this one:
1) I don't know what the functions do so I have to look at the code.
2) It's in a arch that I don't compile so cscope isn't set up meaning it's hard to find the functions.You're sending a lot of patches and they are all hard to review and some of them are buggy and none of them really add any value. It's a waste of your time and it's a waste of my time.
And you're still sending buggy patches that exhibit the same qualities. They're still wasting Dan's time, and now they're wasting mine.
I appreciate automated checkers where they provide added value, but I really feel you haven't done your diligence on them.
Regards,
Brian
Re: [PATCH 1/1] s390/net: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringI agree with your proposed debug_unregister() changes, but not with your kfree_fsm() change.
Regards, Ursula Braun
Quoted 102 lines · SF Markus Elfring
The functions
debug_unregister()andkfree_fsm()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- drivers/s390/net/claw.c | 6 ++---- drivers/s390/net/ctcm_main.c | 6 ++---- drivers/s390/net/lcs.c | 6 ++---- drivers/s390/net/netiucv.c | 12 ++++-------- 4 files changed, 10 insertions(+), 20 deletions(-)drivers/s390/net/claw.c +2
-4@@ -109,10 +109,8 @@ static debug_info_t *claw_dbf_trace;static void claw_unregister_debug_facility (void ) { -if (claw_dbf_setup) -debug_unregister (claw_dbf_setup); -if (claw_dbf_trace) -debug_unregister (claw_dbf_trace); +debug_unregister (claw_dbf_setup); +debug_unregister (claw_dbf_trace); } static intdrivers/s390/net/ctcm_main.c +2
-4@@ -1074,8 +1074,7 @@ static void ctcm_free_netdevice(struct net_device *dev)if (priv) { grp = priv->mpcg;if (grp) { -if (grp->fsm) -kfree_fsm (grp->fsm); +kfree_fsm (grp->fsm);if (grp->xid_skb)dev_kfree_skb (grp->xid_skb);if (grp->rcvd_xid_skb)@@ -1672,8 +1671,7 @@ static int ctcm_shutdown_device(struct ccwgroup_device *cgdev)ctcm_free_netdevice (dev); } -if (priv->fsm) -kfree_fsm (priv->fsm); +kfree_fsm (priv->fsm);ccw_device_set_offline (cgdev->cdev[1 ]);ccw_device_set_offline (cgdev->cdev[0 ]);drivers/s390/net/lcs.c +2
-4@@ -88,10 +88,8 @@ static debug_info_t *lcs_dbf_trace;static void lcs_unregister_debug_facility (void ) { -if (lcs_dbf_setup) -debug_unregister (lcs_dbf_setup); -if (lcs_dbf_trace) -debug_unregister (lcs_dbf_trace); +debug_unregister (lcs_dbf_setup); +debug_unregister (lcs_dbf_trace); } static intdrivers/s390/net/netiucv.c +4
-8@@ -487,12 +487,9 @@ DEFINE_PER_CPU(char[256], iucv_dbf_txt_buf);static void iucv_unregister_dbf_views (void ) { -if (iucv_dbf_setup) -debug_unregister (iucv_dbf_setup); -if (iucv_dbf_data) -debug_unregister (iucv_dbf_data); -if (iucv_dbf_trace) -debug_unregister (iucv_dbf_trace); +debug_unregister (iucv_dbf_setup); +debug_unregister (iucv_dbf_data); +debug_unregister (iucv_dbf_trace); }static int iucv_register_dbf_views (void ) {@@ -1975,8 +1972,7 @@ static void netiucv_free_netdevice(struct net_device *dev)if (privptr) {if (privptr->conn)netiucv_remove_connection (privptr->conn); -if (privptr->fsm) -kfree_fsm (privptr->fsm); +kfree_fsm (privptr->fsm); privptr->conn =NULL ; privptr->fsm =NULL ;/* privptr gets freed by free_netdev() */ }
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 2 lines
I agree with your proposed
debug_unregister()changes, but not with yourkfree_fsm()change.
Why do you want to keep an additional null pointer check before the call of the kfree_fsm() function within the implementation of the netiucv_free_netdevice() function?
Regards,
Markus
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 6 lines · SF Markus Elfring
Quoted 2 lines
I agree with your proposed
debug_unregister()changes, but not with yourkfree_fsm()change.Why do you want to keep an additional null pointer check before the call of the
kfree_fsm()function within the implementation of thenetiucv_free_netdevice()function?
Think about how long it takes you to figure this out what the bug is and then remember that we have to spend that same amount of time multiplied by the number of patches you have sent.
regards,
dan carpenter
PATCH 1/1 btrfs: Deletion of unnecessary checks before six function calls
In reply to SF Markus ElfringThe following functions test whether their argument is NULL and then return immediately.
* btrfs_free_path()
* free_extent_buffer()
* free_extent_map()
* free_extent_state()
* iput()
* kfree()
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/btrfs/dev-replace.c | 3 +-- fs/btrfs/extent_io.c | 12 ++++-------- fs/btrfs/file.c | 6 ++---- fs/btrfs/free-space-cache.c | 7 +++---- fs/btrfs/inode.c | 6 ++---- fs/btrfs/reada.c | 3 +-- fs/btrfs/relocation.c | 3 +-- fs/btrfs/tests/btrfs-tests.c | 3 +-- fs/btrfs/tree-defrag.c | 3 +-- fs/btrfs/tree-log.c | 6 ++---- 10 files changed, 18 insertions(+), 34 deletions(-)
fs/btrfs/dev-replace.c +1 -2
@@ -183,8 +183,7 @@ no_valid_dev_replace_entry_found: } out: -if (path) -btrfs_free_path (path); +btrfs_free_path (path);return ret; }
fs/btrfs/extent_io.c +4 -8
@@ -704,8 +704,7 @@ next: out:spin_unlock (&tree->lock); -if (prealloc) -free_extent_state (prealloc); +free_extent_state (prealloc);return 0 ;
@@ -1006,8 +1005,7 @@ hit_next: out:spin_unlock (&tree->lock); -if (prealloc) -free_extent_state (prealloc); +free_extent_state (prealloc);return err;
@@ -1223,8 +1221,7 @@ hit_next: out:spin_unlock (&tree->lock); -if (prealloc) -free_extent_state (prealloc); +free_extent_state (prealloc);return err;
@@ -4146,8 +4143,7 @@ int extent_readpages(struct extent_io_tree *tree,__extent_readpages (tree, pagepool, nr, get_extent, &em_cached, &bio,0 , &bio_flags,READ ); -if (em_cached) -free_extent_map (em_cached); +free_extent_map (em_cached);BUG_ON (!list_empty (pages));if (bio)
fs/btrfs/file.c +2 -4
@@ -677,10 +677,8 @@ next:/* once for the tree*/ free_extent_map (em); } -if (split) -free_extent_map (split); -if (split2) -free_extent_map (split2); +free_extent_map (split); +free_extent_map (split2); }/*
fs/btrfs/free-space-cache.c +3 -4
@@ -1943,8 +1943,7 @@ new_bitmap: out:if (info) { -if (info->bitmap) -kfree (info->bitmap); +kfree (info->bitmap);kmem_cache_free (btrfs_free_space_cachep, info); }
@@ -3322,8 +3321,8 @@ again:if (info)kmem_cache_free (btrfs_free_space_cachep, info); -if (map) -kfree (map); + +kfree (map);return 0 ; }
fs/btrfs/inode.c +0 -0
@@ -857,8 +857,7 @@ static u64 get_extent_allocation_hint(struct inode *inode,
u64 start,
em = search_extent_mapping(em_tree, 0, 0); if (em && em->block_start < EXTENT_MAP_LAST_BYTE)
alloc_hint = em->block_start;
- if (em)
- free_extent_map(em);
+ free_extent_map(em);
} else {
alloc_hint = em->block_start; free_extent_map(em);
@@ -6573,8 +6572,7 @@ out:
trace_btrfs_get_extent(root, em);
- if (path)
- btrfs_free_path(path);
+ btrfs_free_path(path);
if (trans) {
ret = btrfs_end_transaction(trans, root); if (!err)
fs/btrfs/reada.c +0 -0
@@ -731,8 +731,7 @@ static int reada_start_machine_dev(struct btrfs_fs_info
*fs_info,
else if (eb)
__readahead_hook(fs_info->extent_root, eb, eb->start, ret);
- if (eb)
- free_extent_buffer(eb);
+ free_extent_buffer(eb);
return 1;
fs/btrfs/relocation.c +1 -2
@@ -4158,8 +4158,7 @@ out:btrfs_end_transaction (trans, root);btrfs_btree_balance_dirty (root);if (err) { -if (inode) -iput (inode); +iput (inode); inode =ERR_PTR (err); }return inode;
fs/btrfs/tests/btrfs-tests.c +1 -2
@@ -162,8 +162,7 @@ void btrfs_free_dummy_root(struct btrfs_root *root) {if (!root)return ; -if (root->node) -free_extent_buffer (root->node); +free_extent_buffer (root->node);if (root->fs_info)btrfs_free_dummy_fs_info (root->fs_info);kfree (root);
fs/btrfs/tree-defrag.c +1 -2
@@ -118,8 +118,7 @@ int btrfs_defrag_leaves(struct btrfs_trans_handle *trans, ret = -EAGAIN ; } out: -if (path) -btrfs_free_path (path); +btrfs_free_path (path);if (ret == -EAGAIN ) {if (root->defrag_max.objectid > root->defrag_progress.objectid) goto done;
fs/btrfs/tree-log.c +0 -0
@@ -736,8 +736,7 @@ static noinline int replay_one_extent(struct
btrfs_trans_handle *trans,
inode_add_bytes(inode, nbytes);
ret = btrfs_update_inode(trans, root, inode);
out:
- if (inode)
- iput(inode);
+ iput(inode);
return ret;
}
@@ -2210,8 +2209,7 @@ static noinline int walk_down_log_tree(struct btrfs_trans_handle *trans,
}
WARN_ON(*level <= 0);
- if (path->nodes[*level-1])
- free_extent_buffer(path->nodes[*level-1]);
+ free_extent_buffer(path->nodes[*level-1]);
path->nodes[*level-1] = next; *level = btrfs_header_level(next); path->slots[*level] = 0;
Signature · 1 line
2.1.3
Re: [Cocci] [PATCH 1/1] btrfs: Deletion of unnecessary checks before six function calls
Quoted 32 lines · SF Markus Elfring
The following functions test whether their argument is NULL and then return immediately.
*btrfs_free_path()
*free_extent_buffer()
*free_extent_map()
*free_extent_state()
*iput()
*kfree()Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- fs/btrfs/dev-replace.c | 3 +-- fs/btrfs/extent_io.c | 12 ++++-------- fs/btrfs/file.c | 6 ++---- fs/btrfs/free-space-cache.c | 7 +++---- fs/btrfs/inode.c | 6 ++---- fs/btrfs/reada.c | 3 +-- fs/btrfs/relocation.c | 3 +-- fs/btrfs/tests/btrfs-tests.c | 3 +-- fs/btrfs/tree-defrag.c | 3 +-- fs/btrfs/tree-log.c | 6 ++---- 10 files changed, 18 insertions(+), 34 deletions(-)fs/btrfs/dev-replace.c +0
-0
fs/btrfs/dev-replace.c no_valid_dev_replace_entry_found: · line 186
Quoted 6 lines
fs/btrfs/dev-replace.c +1
-2@@ -183,8 +183,7 @@ no_valid_dev_replace_entry_found: } out: -if (path) -btrfs_free_path (path); +btrfs_free_path (path);
It appears to be statically apparent whether btrfs_free_path is needed or not. The code could be changed both not to have the test and not to have the jump and call to btrfs_free_path.
This is probably the case for the other occurrences next to labels.
julia
Quoted 206 lines
fs/btrfs/dev-replace.c +0
-0return ret; }fs/btrfs/extent_io.c +4
-8@@ -704,8 +704,7 @@ next: out:spin_unlock (&tree->lock); -if (prealloc) -free_extent_state (prealloc); +free_extent_state (prealloc);return 0 ;@@ -1006,8 +1005,7 @@ hit_next: out:spin_unlock (&tree->lock); -if (prealloc) -free_extent_state (prealloc); +free_extent_state (prealloc);return err;@@ -1223,8 +1221,7 @@ hit_next: out:spin_unlock (&tree->lock); -if (prealloc) -free_extent_state (prealloc); +free_extent_state (prealloc);return err;@@ -4146,8 +4143,7 @@ int extent_readpages(struct extent_io_tree *tree,__extent_readpages (tree, pagepool, nr, get_extent, &em_cached, &bio,0 , &bio_flags,READ ); -if (em_cached) -free_extent_map (em_cached); +free_extent_map (em_cached);BUG_ON (!list_empty (pages));if (bio)fs/btrfs/file.c +2
-4@@ -677,10 +677,8 @@ next:/* once for the tree*/ free_extent_map (em); } -if (split) -free_extent_map (split); -if (split2) -free_extent_map (split2); +free_extent_map (split); +free_extent_map (split2); }/* fs/btrfs/free-space-cache.c +3
-4@@ -1943,8 +1943,7 @@ new_bitmap: out:if (info) { -if (info->bitmap) -kfree (info->bitmap); +kfree (info->bitmap);kmem_cache_free (btrfs_free_space_cachep, info); }@@ -3322,8 +3321,8 @@ again:if (info)kmem_cache_free (btrfs_free_space_cachep, info); -if (map) -kfree (map); + +kfree (map);return 0 ; }fs/btrfs/inode.c +1
-2@@ -857,8 +857,7 @@ static u64 get_extent_allocation_hint(struct inode *inode,u64 start, em =search_extent_mapping (em_tree,0 ,0 );if (em && em->block_start <EXTENT_MAP_LAST_BYTE ) alloc_hint = em->block_start; -if (em) -free_extent_map (em); +free_extent_map (em); }else { alloc_hint = em->block_start;fs/btrfs/inode.c +1
-2free_extent_map (em);@@ -6573,8 +6572,7 @@ out:trace_btrfs_get_extent (root, em); -if (path) -btrfs_free_path (path); +btrfs_free_path (path);if (trans) { ret =btrfs_end_transaction (trans, root);if (!err)fs/btrfs/reada.c +1
-2@@ -731,8 +731,7 @@ static int reada_start_machine_dev(struct btrfs_fs_info *fs_info, else if (eb)__readahead_hook (fs_info->extent_root, eb, eb->start, ret); -if (eb) -free_extent_buffer (eb); +free_extent_buffer (eb);return 1 ;fs/btrfs/relocation.c +1
-2@@ -4158,8 +4158,7 @@ out:btrfs_end_transaction (trans, root);btrfs_btree_balance_dirty (root);if (err) { -if (inode) -iput (inode); +iput (inode); inode =ERR_PTR (err); }return inode;fs/btrfs/tests/btrfs-tests.c +1
-2@@ -162,8 +162,7 @@ void btrfs_free_dummy_root(struct btrfs_root *root) {if (!root)return ; -if (root->node) -free_extent_buffer (root->node); +free_extent_buffer (root->node);if (root->fs_info)btrfs_free_dummy_fs_info (root->fs_info);kfree (root);fs/btrfs/tree-defrag.c +1
-2@@ -118,8 +118,7 @@ int btrfs_defrag_leaves(struct btrfs_trans_handle *trans, ret = -EAGAIN ; } out: -if (path) -btrfs_free_path (path); +btrfs_free_path (path);if (ret == -EAGAIN ) {if (root->defrag_max.objectid > root->defrag_progress.objectid) goto done;fs/btrfs/tree-log.c +2
-4@@ -736,8 +736,7 @@ static noinline int replay_one_extent(structbtrfs_trans_handle *trans,inode_add_bytes (inode ,nbytes ); ret =btrfs_update_inode (trans, root, inode); out: -if (inode) -iput (inode); +iput (inode);return ret; }@@ -2210,8 +2209,7 @@ static noinline int walk_down_log_tree(struct btrfs_trans_handle *trans, }WARN_ON (*level <=0 ); -if (path->nodes[*level-1 ]) -free_extent_buffer (path->nodes[*level-1 ]); +free_extent_buffer (path->nodes[*level-1 ]); path->nodes[*level-1 ] = next; *level =btrfs_header_level (next);path->slots[*level] = 0;
Signature · 7 lines
2.1.3 _______________________________________________ Cocci mailing list Cocci at systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
PATCH 1/1 ocfs2: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringThe functions iput() and ocfs2_free_path() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/ocfs2/alloc.c | 15 +++++---------- fs/ocfs2/ioctl.c | 3 +-- fs/ocfs2/journal.c | 9 +++------ fs/ocfs2/localalloc.c | 9 +++------ fs/ocfs2/namei.c | 3 +-- fs/ocfs2/slot_map.c | 3 +-- fs/ocfs2/super.c | 3 +-- 7 files changed, 15 insertions(+), 30 deletions(-)
fs/ocfs2/alloc.c +5 -10
@@ -3453,8 +3453,7 @@ static int ocfs2_merge_rec_right(struct ocfs2_path *left_path, subtree_index); } out: -if (right_path) -ocfs2_free_path (right_path); +ocfs2_free_path (right_path);return ret; }
@@ -3647,8 +3646,7 @@ static int ocfs2_merge_rec_left(struct ocfs2_path *right_path, right_path, subtree_index); } out: -if (left_path) -ocfs2_free_path (left_path); +ocfs2_free_path (left_path);return ret; }
@@ -4431,10 +4429,8 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et, } out: -if (left_path) -ocfs2_free_path (left_path); -if (right_path) -ocfs2_free_path (right_path); +ocfs2_free_path (left_path); +ocfs2_free_path (right_path);return ret; }
@@ -6157,8 +6153,7 @@ int ocfs2_begin_truncate_log_recovery(struct ocfs2_super *osb, } bail: -if (tl_inode) -iput (tl_inode); +iput (tl_inode);brelse (tl_bh);if (status <0 && (*tl_copy)) {
fs/ocfs2/ioctl.c +1 -2
@@ -606,8 +606,7 @@ bail:if (gb_inode)mutex_unlock (&gb_inode->i_mutex); -if (gb_inode) -iput (gb_inode); +iput (gb_inode);brelse (bh);
fs/ocfs2/journal.c +3 -6
@@ -1009,8 +1009,7 @@ void ocfs2_journal_shutdown(struct ocfs2_super *osb)// up_write(&journal->j_trans_barrier); done: -if (inode) -iput (inode); +iput (inode); } static void ocfs2_clear_journal_error(struct super_block *sb,
@@ -1646,8 +1645,7 @@ done:if (got_lock)ocfs2_inode_unlock (inode,1 ); -if (inode) -iput (inode); +iput (inode);brelse (bh);
@@ -1755,8 +1753,7 @@ static int ocfs2_trylock_journal(struct ocfs2_super *osb,ocfs2_inode_unlock (inode,1 ); bail: -if (inode) -iput (inode); +iput (inode);return status; }
fs/ocfs2/localalloc.c +3 -6
@@ -358,8 +358,7 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb) bail:if (status <0 )brelse (alloc_bh); -if (inode) -iput (inode); +iput (inode);trace_ocfs2_load_local_alloc (osb->local_alloc_bits);
@@ -473,8 +472,7 @@ out_mutex:iput (main_bm_inode); out: -if (local_alloc_inode) -iput (local_alloc_inode); +iput (local_alloc_inode);kfree (alloc_copy); }
@@ -1328,8 +1326,7 @@ bail:brelse (main_bm_bh); -if (main_bm_inode) -iput (main_bm_inode); +iput (main_bm_inode);kfree (alloc_copy);
fs/ocfs2/namei.c +1 -2
@@ -1607,8 +1607,7 @@ bail:if (new_inode)sync_mapping_buffers (old_inode->i_mapping); -if (new_inode) -iput (new_inode); +iput (new_inode);ocfs2_free_dir_lookup_result (&target_lookup_res);ocfs2_free_dir_lookup_result (&old_entry_lookup);
fs/ocfs2/slot_map.c +1 -2
@@ -322,8 +322,7 @@ static void __ocfs2_free_slot_info(struct ocfs2_slot_info *si)if (si ==NULL )return ; -if (si->si_inode) -iput (si->si_inode); +iput (si->si_inode);if (si->si_bh) {for (i =0 ; i < si->si_blocks; i++) {if (si->si_bh[i]) {
fs/ocfs2/super.c +0 -0
@@ -1723,8 +1723,7 @@ static int ocfs2_statfs(struct dentry *dentry, struct
kstatfs *buf)
ocfs2_inode_unlock(inode, 0);
status = 0;
bail:
- if (inode)
- iput(inode);
+ iput(inode);
if (status)
mlog_errno(status);
Signature · 1 line
2.1.3
Re: [PATCH 1/1] ocfs2: Deletion of unnecessary checks before two function calls
Quoted 3 lines · SF Markus Elfring
The functions
iput()andocfs2_free_path()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
Please check whether more labels could be added to avoid executing unnecessary code.
julia
Quoted 194 lines
This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- fs/ocfs2/alloc.c | 15 +++++---------- fs/ocfs2/ioctl.c | 3 +-- fs/ocfs2/journal.c | 9 +++------ fs/ocfs2/localalloc.c | 9 +++------ fs/ocfs2/namei.c | 3 +-- fs/ocfs2/slot_map.c | 3 +-- fs/ocfs2/super.c | 3 +-- 7 files changed, 15 insertions(+), 30 deletions(-)fs/ocfs2/alloc.c +5
-10@@ -3453,8 +3453,7 @@ static int ocfs2_merge_rec_right(struct ocfs2_path *left_path, subtree_index); } out: -if (right_path) -ocfs2_free_path (right_path); +ocfs2_free_path (right_path);return ret; }@@ -3647,8 +3646,7 @@ static int ocfs2_merge_rec_left(struct ocfs2_path *right_path, right_path, subtree_index); } out: -if (left_path) -ocfs2_free_path (left_path); +ocfs2_free_path (left_path);return ret; }@@ -4431,10 +4429,8 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et, } out: -if (left_path) -ocfs2_free_path (left_path); -if (right_path) -ocfs2_free_path (right_path); +ocfs2_free_path (left_path); +ocfs2_free_path (right_path);return ret; }@@ -6157,8 +6153,7 @@ int ocfs2_begin_truncate_log_recovery(struct ocfs2_super *osb, } bail: -if (tl_inode) -iput (tl_inode); +iput (tl_inode);brelse (tl_bh);if (status <0 && (*tl_copy)) {fs/ocfs2/ioctl.c +1
-2@@ -606,8 +606,7 @@ bail:if (gb_inode)mutex_unlock (&gb_inode->i_mutex); -if (gb_inode) -iput (gb_inode); +iput (gb_inode);brelse (bh);fs/ocfs2/journal.c +3
-6@@ -1009,8 +1009,7 @@ void ocfs2_journal_shutdown(struct ocfs2_super *osb)// up_write(&journal->j_trans_barrier); done: -if (inode) -iput (inode); +iput (inode); } static void ocfs2_clear_journal_error(struct super_block *sb,@@ -1646,8 +1645,7 @@ done:if (got_lock)ocfs2_inode_unlock (inode,1 ); -if (inode) -iput (inode); +iput (inode);brelse (bh);@@ -1755,8 +1753,7 @@ static int ocfs2_trylock_journal(struct ocfs2_super *osb,ocfs2_inode_unlock (inode,1 ); bail: -if (inode) -iput (inode); +iput (inode);return status; }fs/ocfs2/localalloc.c +3
-6@@ -358,8 +358,7 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb) bail:if (status <0 )brelse (alloc_bh); -if (inode) -iput (inode); +iput (inode);trace_ocfs2_load_local_alloc (osb->local_alloc_bits);@@ -473,8 +472,7 @@ out_mutex:iput (main_bm_inode); out: -if (local_alloc_inode) -iput (local_alloc_inode); +iput (local_alloc_inode);kfree (alloc_copy); }@@ -1328,8 +1326,7 @@ bail:brelse (main_bm_bh); -if (main_bm_inode) -iput (main_bm_inode); +iput (main_bm_inode);kfree (alloc_copy);fs/ocfs2/namei.c +1
-2@@ -1607,8 +1607,7 @@ bail:if (new_inode)sync_mapping_buffers (old_inode->i_mapping); -if (new_inode) -iput (new_inode); +iput (new_inode);ocfs2_free_dir_lookup_result (&target_lookup_res);ocfs2_free_dir_lookup_result (&old_entry_lookup);fs/ocfs2/slot_map.c +1
-2@@ -322,8 +322,7 @@ static void __ocfs2_free_slot_info(struct ocfs2_slot_info *si)if (si ==NULL )return ; -if (si->si_inode) -iput (si->si_inode); +iput (si->si_inode);if (si->si_bh) {for (i =0 ; i < si->si_blocks; i++) {if (si->si_bh[i]) {fs/ocfs2/super.c +1
-2@@ -1723,8 +1723,7 @@ static int ocfs2_statfs(struct dentry *dentry, struct kstatfs *buf) ocfs2_inode_unlock(inode, 0); status =0 ; bail: -if (inode) -iput (inode); +iput (inode);if (status)
mlog_errno(status);Signature · 7 lines
2.1.3 -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cover ocfs2: Deletion of some unnecessary checks
From: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 20:15:16 +0100
Further update suggestions were taken into account after a patch was applied from static source code analysis.
Markus Elfring (7):
Deletion of unnecessary checks before three function calls Less function calls in ocfs2_convert_inline_data_to_extents()
after error detection
Less function calls in ocfs2_figure_merge_contig_type()
after error detection
One function call less in ocfs2_merge_rec_left()
after error detection
One function call less in ocfs2_merge_rec_right()
after error detection
One function call less in ocfs2_init_slot_info()
after error detection
One function call less in user_cluster_connect()
after error detection
fs/ocfs2/alloc.c | 48 ++++++++++++++++++++++-------------------------- fs/ocfs2/slot_map.c | 4 ++-- fs/ocfs2/stack_user.c | 8 +++----- 3 files changed, 27 insertions(+), 33 deletions(-)
Signature · 1 line
2.3.0
PATCH 1/7 ocfs2: Deletion of unnecessary checks before three function calls
From: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 17:40:57 +0100
The functions kfree(), ocfs2_free_path() and __ocfs2_free_slot_info() test whether their argument is NULL and then return immediately. Thus the test around their calls is not needed.
This issue was detected by using the Coccinelle software.
--- fs/ocfs2/alloc.c | 17 +++++------------ fs/ocfs2/slot_map.c | 2 +- fs/ocfs2/stack_user.c | 2 +- 3 files changed, 7 insertions(+), 14 deletions(-)
fs/ocfs2/alloc.c +5 -12
@@ -3453,8 +3453,7 @@ static int ocfs2_merge_rec_right(struct ocfs2_path *left_path, subtree_index); } out: -if (right_path) -ocfs2_free_path (right_path); +ocfs2_free_path (right_path);return ret; }
@@ -3647,8 +3646,7 @@ static int ocfs2_merge_rec_left(struct ocfs2_path *right_path, right_path, subtree_index); } out: -if (left_path) -ocfs2_free_path (left_path); +ocfs2_free_path (left_path);return ret; }
@@ -4431,11 +4429,8 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et, } out: -if (left_path) -ocfs2_free_path (left_path); -if (right_path) -ocfs2_free_path (right_path); - +ocfs2_free_path (left_path); +ocfs2_free_path (right_path);return ret; }
@@ -6996,9 +6991,7 @@ out_commit: out:if (data_ac)ocfs2_free_alloc_context (data_ac); -if (pages) -kfree (pages); - +kfree (pages);return ret; }
fs/ocfs2/slot_map.c +1 -1
@@ -452,7 +452,7 @@ int ocfs2_init_slot_info(struct ocfs2_super *osb) osb->slot_info = (struct ocfs2_slot_info *)si; bail: -if (status <0 && si) +if (status <0 )__ocfs2_free_slot_info (si);return status;
fs/ocfs2/stack_user.c +1 -1
@@ -1063,7 +1063,7 @@ static int user_cluster_connect(struct ocfs2_cluster_connection *conn) } out: -if (rc && lc) +if (rc)kfree (lc);return rc; }
Signature · 1 line
2.3.0
PATCH 2/7 ocfs2: Less function calls in ocfs2_convert_inline_data_to_extents() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 18:19:04 +0100
The kfree() function was called in a few cases by the ocfs2_convert_inline_data_to_extents() function during error handling even if the passed variable "pages" contained a null pointer.
* Return from this implementation directly after failure detection for the function call "kcalloc".
* Corresponding details could be improved by the introduction of another jump label.
--- fs/ocfs2/alloc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
fs/ocfs2/alloc.c +3 -2
@@ -6853,13 +6853,13 @@ int ocfs2_convert_inline_data_to_extents(struct inode *inode,if (pages =NULL ) { ret = -ENOMEM ;mlog_errno (ret); - goto out; +return ret; } ret =ocfs2_reserve_clusters (osb,1 , &data_ac);if (ret) {mlog_errno (ret); - goto out; + goto free_pages; } }
@@ -6991,6 +6991,7 @@ out_commit: out:if (data_ac)ocfs2_free_alloc_context (data_ac); +free_pages:kfree (pages);return ret; }
Signature · 1 line
2.3.0
PATCH 3/7 ocfs2: Less function calls in ocfs2_figure_merge_contig_type() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 18:54:25 +0100
The ocfs2_free_path() function was called in some cases by the ocfs2_figure_merge_contig_type() function during error handling even if the passed variables "left_path" and "right_path" contained still a null pointer.
Corresponding implementation details could be improved by adjustments for jump labels according to the current Linux coding style convention.
--- fs/ocfs2/alloc.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-)
fs/ocfs2/alloc.c +13 -11
@@ -4332,17 +4332,17 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et, }else if (path->p_tree_depth >0 ) { status =ocfs2_find_cpos_for_left_leaf (sb, path, &left_cpos);if (status) - goto out; + goto exit;if (left_cpos !=0 ) { left_path =ocfs2_new_path_from_path (path);if (!left_path) - goto out; + goto exit; status =ocfs2_find_path (et->et_ci, left_path, left_cpos);if (status) - goto out; + goto free_left_path; new_el =path_leaf_el (left_path);
@@ -4359,7 +4359,7 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et,le16_to_cpu (new_el->l_next_free_rec), le16_to_cpu(new_el->l_count)); status = -EINVAL ; - goto out; + goto free_left_path; } rec = &new_el->l_recs[le16_to_cpu (new_el->l_next_free_rec) -1 ];
@@ -4386,18 +4386,18 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et, path->p_tree_depth > 0) { status =ocfs2_find_cpos_for_right_leaf (sb, path, &right_cpos);if (status) - goto out; + goto free_left_path;if (right_cpos =0 ) - goto out; + goto free_left_path; right_path =ocfs2_new_path_from_path (path);if (!right_path) - goto out; + goto free_left_path; status =ocfs2_find_path (et->et_ci, right_path, right_cpos);if (status) - goto out; + goto free_right_path; new_el =path_leaf_el (right_path); rec = &new_el->l_recs[0 ];
@@ -4411,7 +4411,7 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et, (unsigned long long )le64_to_cpu (eb->h_blkno), le16_to_cpu(new_el->l_next_free_rec)); status = -EINVAL ; - goto out; + goto free_right_path; } rec = &new_el->l_recs[1 ]; }
@@ -4428,9 +4428,11 @@ ocfs2_figure_merge_contig_type(struct ocfs2_extent_tree *et, ret = contig_type; } -out: -ocfs2_free_path (left_path); +free_right_path:ocfs2_free_path (right_path); +free_left_path: +ocfs2_free_path (left_path); +exit:return ret; }
Signature · 1 line
2.3.0
PATCH 4/7 ocfs2: One function call less in ocfs2_merge_rec_left() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 19:16:33 +0100
The ocfs2_free_path() function was called by the ocfs2_merge_rec_left() function even if a call of the ocfs2_get_left_path() function failed.
Return from this implementation directly after corresponding exception handling.
--- fs/ocfs2/alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/alloc.c +1 -1
@@ -3535,7 +3535,7 @@ static int ocfs2_merge_rec_left(struct ocfs2_path *right_path, ret =ocfs2_get_left_path (et, right_path, &left_path);if (ret) {mlog_errno (ret); - goto out; +return ret; } left_el =path_leaf_el (left_path);
Signature · 1 line
2.3.0
PATCH 5/7 ocfs2: One function call less in ocfs2_merge_rec_right() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 19:23:55 +0100
The ocfs2_free_path() function was called by the ocfs2_merge_rec_right() function even if a call of the ocfs2_get_right_path() function failed.
Return from this implementation directly after corresponding exception handling.
--- fs/ocfs2/alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/alloc.c +1 -1
@@ -3370,7 +3370,7 @@ static int ocfs2_merge_rec_right(struct ocfs2_path *left_path, ret =ocfs2_get_right_path (et, left_path, &right_path);if (ret) {mlog_errno (ret); - goto out; +return ret; } right_el =path_leaf_el (right_path);
Signature · 1 line
2.3.0
PATCH 6/7 ocfs2: One function call less in ocfs2_init_slot_info() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 19:49:50 +0100
The __ocfs2_free_slot_info() function was called by the ocfs2_init_slot_info() function even if a call of the kzalloc() function failed.
Return from this implementation directly after corresponding exception handling.
--- fs/ocfs2/slot_map.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/slot_map.c +1 -1
@@ -427,7 +427,7 @@ int ocfs2_init_slot_info(struct ocfs2_super *osb)if (!si) { status = -ENOMEM ;mlog_errno (status); - goto bail; +return status; } si->si_extended =ocfs2_uses_extended_slot_map (osb);
Signature · 1 line
2.3.0
PATCH 7/7 ocfs2: One function call less in user_cluster_connect() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 21 Feb 2015 20:09:00 +0100
The kfree() function was called by the user_cluster_connect() function even if a previous call of the kzalloc() function failed.
Return from this implementation directly after failure detection.
--- fs/ocfs2/stack_user.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
fs/ocfs2/stack_user.c +2 -4
@@ -1004,10 +1004,8 @@ static int user_cluster_connect(struct ocfs2_cluster_connection *conn)BUG_ON (conn =NULL ); lc =kzalloc (sizeof (struct ocfs2_live_connection ),GFP_KERNEL ); -if (!lc) { - rc = -ENOMEM ; - goto out; - } +if (!lc) +return -ENOMEM ;init_waitqueue_head (&lc->oc_wait);init_completion (&lc->oc_sync_wait);
Signature · 1 line
2.3.0
cover ocfs2: Deletion of some unnecessary checks
In reply to Julia LawallFrom: Markus Elfring <[email protected]>
Further update suggestions were taken into account after two patches were applied from static source code analysis.
Markus Elfring (11):
Delete an unnecessary check before unregister_sysctl_table() Delete unnecessary checks before the function call "iput" Less checks in ocfs2_rename() after error detection
One check less in ocfs2_statfs()
Less error log repetition in ocfs2_begin_truncate_log_recovery() Two checks less in ocfs2_local_alloc_slide_window()
Less function calls in ocfs2_shutdown_local_alloc() after error detection Less checks in ocfs2_load_local_alloc()
One function call less in ocfs2_trylock_journal() after error detection Less function calls in ocfs2_replay_journal() after error detection One function call less in ocfs2_journal_shutdown() from input checks
fs/ocfs2/alloc.c | 24 +++++++-------- fs/ocfs2/ioctl.c | 4 +-- fs/ocfs2/journal.c | 62 +++++++++++++++---------------------- fs/ocfs2/localalloc.c | 84 +++++++++++++++++++++------------------------------ fs/ocfs2/namei.c | 17 +++++------ fs/ocfs2/slot_map.c | 3 +- fs/ocfs2/stackglue.c | 3 +- fs/ocfs2/super.c | 22 ++++++-------- 8 files changed, 90 insertions(+), 129 deletions(-)
Signature · 1 line
2.4.5
PATCH 1/11 ocfs2: Delete an unnecessary check before unregister_sysctl_table()
From: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 13:20:13 +0200
The unregister_sysctl_table() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/ocfs2/stackglue.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/ocfs2/stackglue.c +1 -2
@@ -737,8 +737,7 @@ static void __exit ocfs2_stack_glue_exit(void) locking_max_version.pv_major =0 ; locking_max_version.pv_minor =0 ;ocfs2_sysfs_exit (); -if (ocfs2_table_header) -unregister_sysctl_table (ocfs2_table_header); +unregister_sysctl_table (ocfs2_table_header); }MODULE_AUTHOR ("Oracle" );
Signature · 1 line
2.4.5
PATCH 2/11 ocfs2: Delete unnecessary checks before the function call "iput"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 13:40:07 +0200
The iput() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/ocfs2/alloc.c | 3 +-- fs/ocfs2/ioctl.c | 4 +--- fs/ocfs2/journal.c | 11 +++-------- fs/ocfs2/localalloc.c | 13 +++---------- fs/ocfs2/namei.c | 4 +--- fs/ocfs2/slot_map.c | 3 +-- fs/ocfs2/super.c | 3 +-- 7 files changed, 11 insertions(+), 30 deletions(-)
fs/ocfs2/alloc.c +1 -2
@@ -6197,8 +6197,7 @@ int ocfs2_begin_truncate_log_recovery(struct ocfs2_super *osb, } bail: -if (tl_inode) -iput (tl_inode); +iput (tl_inode);brelse (tl_bh);if (status <0 && (*tl_copy)) {
fs/ocfs2/ioctl.c +1 -3
@@ -606,9 +606,7 @@ bail:if (gb_inode)mutex_unlock (&gb_inode->i_mutex); -if (gb_inode) -iput (gb_inode); - +iput (gb_inode);brelse (bh);return status;
fs/ocfs2/journal.c +3 -8
@@ -1026,8 +1026,7 @@ void ocfs2_journal_shutdown(struct ocfs2_super *osb)// up_write(&journal->j_trans_barrier); done: -if (inode) -iput (inode); +iput (inode); } static void ocfs2_clear_journal_error(struct super_block *sb,
@@ -1671,9 +1670,7 @@ done:if (got_lock)ocfs2_inode_unlock (inode,1 ); -if (inode) -iput (inode); - +iput (inode);brelse (bh);return status;
@@ -1780,9 +1777,7 @@ static int ocfs2_trylock_journal(struct ocfs2_super *osb,ocfs2_inode_unlock (inode,1 ); bail: -if (inode) -iput (inode); - +iput (inode);return status; }
fs/ocfs2/localalloc.c +3 -10
@@ -358,9 +358,7 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb) bail:if (status <0 )brelse (alloc_bh); -if (inode) -iput (inode); - +iput (inode);trace_ocfs2_load_local_alloc (osb->local_alloc_bits);if (status)
@@ -473,9 +471,7 @@ out_mutex:iput (main_bm_inode); out: -if (local_alloc_inode) -iput (local_alloc_inode); - +iput (local_alloc_inode);kfree (alloc_copy); }
@@ -1326,10 +1322,7 @@ bail:ocfs2_commit_trans (osb, handle);brelse (main_bm_bh); - -if (main_bm_inode) -iput (main_bm_inode); - +iput (main_bm_inode);kfree (alloc_copy);if (ac)
fs/ocfs2/namei.c +1 -3
@@ -1655,9 +1655,7 @@ bail:if (new_inode)sync_mapping_buffers (old_inode->i_mapping); -if (new_inode) -iput (new_inode); - +iput (new_inode);ocfs2_free_dir_lookup_result (&target_lookup_res);ocfs2_free_dir_lookup_result (&old_entry_lookup);ocfs2_free_dir_lookup_result (&old_inode_dot_dot_res);
fs/ocfs2/slot_map.c +1 -2
@@ -322,8 +322,7 @@ static void __ocfs2_free_slot_info(struct ocfs2_slot_info *si)if (si =NULL )return ; -if (si->si_inode) -iput (si->si_inode); +iput (si->si_inode);if (si->si_bh) {for (i =0 ; i < si->si_blocks; i++) {if (si->si_bh[i]) {
fs/ocfs2/super.c +1 -2
@@ -1726,8 +1726,7 @@ static int ocfs2_statfs(struct dentry *dentry, struct kstatfs *buf)ocfs2_inode_unlock (inode,0 ); status =0 ; bail: -if (inode) -iput (inode); +iput (inode);if (status)mlog_errno (status);
Signature · 1 line
2.4.5
PATCH 3/11 ocfs2: Less checks in ocfs2_rename() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 15:30:18 +0200
Skip checks for a few variables in three error handling cases within the ocfs2_rename() function by adjustment of a few jump targets according to the Linux coding style convention.
--- fs/ocfs2/namei.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
fs/ocfs2/namei.c +7 -6
@@ -1255,7 +1255,7 @@ static int ocfs2_rename(struct inode *old_dir, status =ocfs2_rename_lock (osb);if (status <0 ) {mlog_errno (status); - goto bail; + goto basic_clean_up; } rename_lock =1 ;
@@ -1265,13 +1265,13 @@ static int ocfs2_rename(struct inode *old_dir, old_inode->i_ino);if (status <0 ) {mlog_errno (status); - goto bail; + goto rename_unlock; }else if (status =1 ) { status = -EPERM ;trace_ocfs2_rename_not_permitted ( (unsigned long long )old_inode->i_ino, (unsigned long long )new_dir->i_ino); - goto bail; + goto rename_unlock; } }
@@ -1630,9 +1630,10 @@ static int ocfs2_rename(struct inode *old_dir,ocfs2_dentry_move (old_dentry, new_dentry, old_dir, new_dir); status =0 ; bail: -if (rename_lock) +if (rename_lock) { +rename_unlock:ocfs2_rename_unlock (osb); - + }if (handle)ocfs2_commit_trans (osb, handle);
@@ -1651,7 +1652,7 @@ bail:mutex_unlock (&orphan_dir->i_mutex);iput (orphan_dir); } - +basic_clean_up:if (new_inode)sync_mapping_buffers (old_inode->i_mapping);
Signature · 1 line
2.4.5
Re: [PATCH 03/11] ocfs2: Less checks in ocfs2_rename() after error detection
Quoted 8 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 15:30:18 +0200Skip checks for a few variables in three error handling cases within the
ocfs2_rename()function by adjustment of a few jump targets according to the Linux coding style convention.Signed-off-by Markus Elfring <[email protected]>
I don't think this is an improvement.
regards,
dan carpenter
Re: [PATCH 03/11] ocfs2: Less checks in ocfs2_rename() after error detection
Quoted 10 lines
Quoted 8 lines
From: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 15:30:18 +0200Skip checks for a few variables in three error handling cases within the
ocfs2_rename()function by adjustment of a few jump targets according to the Linux coding style convention.Signed-off-by Markus Elfring <[email protected]>I don't think this is an improvement.
How do you think about the other update suggestions from this patch series?
Can the corresponding source code review be continued?
Regards,
Markus
Re: [PATCH 03/11] ocfs2: Less checks in ocfs2_rename() after error detection
In reply to Dan CarpenterQuoted 10 lines
Quoted 8 lines
From: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 15:30:18 +0200Skip checks for a few variables in three error handling cases within the
ocfs2_rename()function by adjustment of a few jump targets according to the Linux coding style convention.Signed-off-by Markus Elfring <[email protected]>I don't think this is an improvement.
How do you think about the other update suggestions from this patch series?
Would anybody like to contribute constructive comments so that further progress can eventually be achieved for a corresponding source code review?
Regards,
Markus
PATCH 4/11 ocfs2: One check less in ocfs2_statfs()
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 16:28:50 +0200
Delete a check for the variable "status" by adjustment of two jump targets according to the Linux coding style convention.
Separate the exception handling statements from the ordinary execution path.
--- fs/ocfs2/super.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
fs/ocfs2/super.c +8 -11
@@ -1692,14 +1692,12 @@ static int ocfs2_statfs(struct dentry *dentry, struct kstatfs *buf)if (!inode) {mlog (ML_ERROR ,"failed to get bitmap inode\n" ); status = -EIO ; - goto bail; + goto log_error; } status =ocfs2_inode_lock (inode, &bh,0 ); -if (status <0 ) { -mlog_errno (status); - goto bail; - } +if (status <0 ) + goto put_inode; bm_lock = (struct ocfs2_dinode *) bh->b_data;
@@ -1724,13 +1722,12 @@ static int ocfs2_statfs(struct dentry *dentry, struct kstatfs *buf)brelse (bh);ocfs2_inode_unlock (inode,0 ); - status =0 ; -bail:iput (inode); - -if (status) -mlog_errno (status); - +return 0 ; +put_inode: +iput (inode); +log_error: +mlog_errno (status);return status; }
Signature · 1 line
2.4.5
PATCH 5/11 ocfs2: Less error log repetition in ocfs2_begin_truncate_log_recovery()
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 17:23:08 +0200
Delete three direct calls of the mlog_errno() function within ocfs2_begin_truncate_log_recovery().
A single logging call can be sufficient.
Drop initialisation for the variables "tl_inode" and "tl_bh" then.
--- fs/ocfs2/alloc.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-)
fs/ocfs2/alloc.c +10 -11
@@ -6147,8 +6147,8 @@ int ocfs2_begin_truncate_log_recovery(struct ocfs2_super *osb, struct ocfs2_dinode **tl_copy) {int status; -struct inode *tl_inode =NULL ; -struct buffer_head *tl_bh =NULL ; +struct inode *tl_inode; +struct buffer_head *tl_bh;struct ocfs2_dinode *di;struct ocfs2_truncate_log *tl;
@@ -6157,10 +6157,8 @@ int ocfs2_begin_truncate_log_recovery(struct ocfs2_super *osb,trace_ocfs2_begin_truncate_log_recovery (slot_num); status =ocfs2_get_truncate_log_info (osb, slot_num, &tl_inode, &tl_bh); -if (status <0 ) { -mlog_errno (status); - goto bail; - } +if (status <0 ) + goto log_error; di = (struct ocfs2_dinode *) tl_bh->b_data;
@@ -6176,7 +6174,6 @@ int ocfs2_begin_truncate_log_recovery(struct ocfs2_super *osb, *tl_copy =kmalloc (tl_bh->b_size,GFP_KERNEL );if (!(*tl_copy)) { status = -ENOMEM ; -mlog_errno (status); goto bail; }
@@ -6191,7 +6188,6 @@ int ocfs2_begin_truncate_log_recovery(struct ocfs2_super *osb,ocfs2_compute_meta_ecc (osb->sb, tl_bh->b_data, &di->i_check); status =ocfs2_write_block (osb, tl_bh,INODE_CACHE (tl_inode));if (status <0 ) { -mlog_errno (status); goto bail; } }
@@ -6200,9 +6196,12 @@ bail:iput (tl_inode);brelse (tl_bh); -if (status <0 && (*tl_copy)) { -kfree (*tl_copy); - *tl_copy =NULL ; +if (status <0 ) { +if (*tl_copy) { +kfree (*tl_copy); + *tl_copy =NULL ; + } +log_error:mlog_errno (status); }
Signature · 1 line
2.4.5
PATCH 6/11 ocfs2: Two checks less in ocfs2_local_alloc_slide_window()
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 18:18:23 +0200
* Return directly from the ocfs2_local_alloc_slide_window() function if a call of the ocfs2_local_alloc_reserve_for_window() function failed at the beginning.
* Rename jump labels according to the Linux coding style convention.
* Drop an unnecessary initialisation for the variable "handle" then.
* Delete a call of the mlog_errno() function at the end.
--- fs/ocfs2/localalloc.c | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-)
fs/ocfs2/localalloc.c +10 -15
@@ -1248,7 +1248,7 @@ static int ocfs2_local_alloc_slide_window(struct ocfs2_super *osb,int status =0 ;struct buffer_head *main_bm_bh =NULL ;struct inode *main_bm_inode =NULL ; -handle_t *handle =NULL ; +handle_t *handle;struct ocfs2_dinode *alloc;struct ocfs2_dinode *alloc_copy =NULL ;struct ocfs2_alloc_context *ac =NULL ;
@@ -1263,15 +1263,14 @@ static int ocfs2_local_alloc_slide_window(struct ocfs2_super *osb,if (status <0 ) {if (status != -ENOSPC )mlog_errno (status); - goto bail; +return status; } handle =ocfs2_start_trans (osb,OCFS2_WINDOW_MOVE_CREDITS );if (IS_ERR (handle)) { status =PTR_ERR (handle); - handle =NULL ;mlog_errno (status); - goto bail; + goto clean_up_main; } alloc = (struct ocfs2_dinode *) osb->local_alloc_bh->b_data;
@@ -1285,7 +1284,7 @@ static int ocfs2_local_alloc_slide_window(struct ocfs2_super *osb,if (!alloc_copy) { status = -ENOMEM ;mlog_errno (status); - goto bail; + goto commit; }memcpy (alloc_copy, alloc, osb->local_alloc_bh->b_size);
@@ -1295,7 +1294,7 @@ static int ocfs2_local_alloc_slide_window(struct ocfs2_super *osb, OCFS2_JOURNAL_ACCESS_WRITE);if (status <0 ) {mlog_errno (status); - goto bail; + goto commit; }ocfs2_clear_local_alloc (alloc);
@@ -1305,31 +1304,27 @@ static int ocfs2_local_alloc_slide_window(struct ocfs2_super *osb, main_bm_inode, main_bm_bh);if (status <0 ) {mlog_errno (status); - goto bail; + goto commit; } status =ocfs2_local_alloc_new_window (osb, handle, ac);if (status <0 ) {if (status != -ENOSPC )mlog_errno (status); - goto bail; + goto commit; }atomic_inc (&osb->alloc_stats.moves); -bail: -if (handle) -ocfs2_commit_trans (osb, handle); - +commit: +ocfs2_commit_trans (osb, handle); +clean_up_main:brelse (main_bm_bh);iput (main_bm_inode);kfree (alloc_copy);if (ac)ocfs2_free_alloc_context (ac); - -if (status) -mlog_errno (status);return status; }
Signature · 1 line
2.4.5
PATCH 7/11 ocfs2: Less function calls in ocfs2_shutdown_local_alloc() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 21:02:05 +0200
The functions kfree() and iput() were called in a few cases by the ocfs2_shutdown_local_alloc() function during error handling even if the passed variables contained still a null pointer.
* Return directly if the local allocation feature is unused or if a call for the ocfs2_get_system_file_inode() function failed.
* Adjust jump targets.
* Drop unnecessary initialisations for the variables "alloc", "alloc_copy", "bh", "local_alloc_inode" and "main_bm_inode" then.
--- fs/ocfs2/localalloc.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-)
fs/ocfs2/localalloc.c +12 -15
@@ -377,18 +377,18 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *osb) {int status;handle_t *handle; -struct inode *local_alloc_inode =NULL ; -struct buffer_head *bh =NULL ; +struct inode *local_alloc_inode; +struct buffer_head *bh;struct buffer_head *main_bm_bh =NULL ; -struct inode *main_bm_inode =NULL ; -struct ocfs2_dinode *alloc_copy =NULL ; -struct ocfs2_dinode *alloc =NULL ; +struct inode *main_bm_inode; +struct ocfs2_dinode *alloc_copy; +struct ocfs2_dinode *alloc;cancel_delayed_work (&osb->la_enable_wq);flush_workqueue (ocfs2_wq);if (osb->local_alloc_state =OCFS2_LA_UNUSED ) - goto out; +return ; local_alloc_inode ocfs2_get_system_file_inode(osb,
@@ -397,7 +397,7 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *osb)if (!local_alloc_inode) { status = -ENOENT ;mlog_errno (status); - goto out; +return ; } osb->local_alloc_state =OCFS2_LA_DISABLED ;
@@ -410,7 +410,7 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *osb)if (!main_bm_inode) { status = -EINVAL ;mlog_errno (status); - goto out; + goto put_local_alloc_inode; }mutex_lock (&main_bm_inode->i_mutex);
@@ -443,7 +443,7 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *osb) bh, OCFS2_JOURNAL_ACCESS_WRITE);if (status <0 ) {mlog_errno (status); - goto out_commit; + goto free_copy; }ocfs2_clear_local_alloc (alloc);
@@ -458,21 +458,18 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *osb)if (status <0 )mlog_errno (status); +free_copy: +kfree (alloc_copy); out_commit:ocfs2_commit_trans (osb, handle); - out_unlock:brelse (main_bm_bh); -ocfs2_inode_unlock (main_bm_inode,1 ); - out_mutex:mutex_unlock (&main_bm_inode->i_mutex);iput (main_bm_inode); - -out: +put_local_alloc_inode:iput (local_alloc_inode); -kfree (alloc_copy); }/*
Signature · 1 line
2.4.5
PATCH 8/11 ocfs2: Less checks in ocfs2_load_local_alloc()
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 22:06:32 +0200
* Skip checks for the variable "status" in a few cases within the ocfs2_load_local_alloc() function by adjustment of two jump targets according to the Linux coding style convention.
* Drop unnecessary initialisations for the variables "alloc" and "inode" then.
--- fs/ocfs2/localalloc.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
fs/ocfs2/localalloc.c +10 -9
@@ -284,14 +284,14 @@ bail:int ocfs2_load_local_alloc (struct ocfs2_super *osb) {int status =0 ; -struct ocfs2_dinode *alloc =NULL ; +struct ocfs2_dinode *alloc;struct buffer_head *alloc_bh =NULL ;u32 num_used; -struct inode *inode =NULL ; +struct inode *inode;struct ocfs2_local_alloc *la; -if (osb->local_alloc_bits =0 ) - goto bail; +if (osb->local_alloc_bits) + goto trace_bits;if (osb->local_alloc_bits >= osb->bitmap_cpg) { mlog(ML_NOTICE, "Requested local alloc window %d is larger "
@@ -308,14 +308,14 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb)if (!inode) { status = -EINVAL ;mlog_errno (status); - goto bail; + goto trace_bits; } status =ocfs2_read_inode_block_full (inode, &alloc_bh,OCFS2_BH_IGNORE_CACHE );if (status <0 ) {mlog_errno (status); - goto bail; + goto put_inode; } alloc = (struct ocfs2_dinode *) alloc_bh->b_data;
@@ -326,6 +326,7 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb)mlog (ML_ERROR ,"Invalid local alloc inode, %llu\n" , (unsigned long long )OCFS2_I (inode)->ip_blkno); status = -EINVAL ; +mlog_errno (status); goto bail; }
@@ -334,6 +335,7 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb)mlog (ML_ERROR ,"Local alloc size is invalid (la_size = %u)\n" ,le16_to_cpu (la->la_size)); status = -EINVAL ; +mlog_errno (status); goto bail; }
@@ -358,11 +360,10 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb) bail:if (status <0 )brelse (alloc_bh); +put_inode:iput (inode); +trace_bits:trace_ocfs2_load_local_alloc (osb->local_alloc_bits); - -if (status) -mlog_errno (status);return status; }
Signature · 1 line
2.4.5
PATCH 9/11 ocfs2: One function call less in ocfs2_trylock_journal() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 22:34:43 +0200
The iput() function was called in one case by the ocfs2_trylock_journal() function during error handling even if the passed variable "inode" contained still a null pointer.
* Return directly if a call of the ocfs2_get_system_file_inode() function failed at the beginning.
* Rename a jump label according to the Linux coding style convention.
--- fs/ocfs2/journal.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-)
fs/ocfs2/journal.c +5 -8
@@ -1749,21 +1749,18 @@ static int ocfs2_trylock_journal(struct ocfs2_super *osb, int slot_num) {int status, flags; -struct inode *inode =NULL ; +struct inode *inode; inode =ocfs2_get_system_file_inode (osb,JOURNAL_SYSTEM_INODE , slot_num);if (inode =NULL ) {mlog (ML_ERROR ,"access error\n" ); - status = -EACCES ; - goto bail; +return -EACCES ; }if (is_bad_inode (inode)) {mlog (ML_ERROR ,"access error (bad inode)\n" ); -iput (inode); - inode =NULL ; status = -EACCES ; - goto bail; + goto put_inode; }SET_INODE_JOURNAL (inode);
@@ -1772,11 +1769,11 @@ static int ocfs2_trylock_journal(struct ocfs2_super *osb,if (status <0 ) {if (status != -EAGAIN )mlog_errno (status); - goto bail; + goto put_inode; }ocfs2_inode_unlock (inode,1 ); -bail: +put_inode:iput (inode);return status; }
Signature · 1 line
2.4.5
PATCH 10/11 ocfs2: Less function calls in ocfs2_replay_journal() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 5 Jul 2015 12:23:37 +0200
The functions brelse() and iput() were called in one case by the ocfs2_replay_journal() function during error handling even if the passed variables contained still a pointer which did not refer to valid data.
* Return directly if a call of the ocfs2_read_journal_inode() function failed at the beginning.
* Rename jump labels according to the Linux coding style convention.
* Delete the variable "got_lock" then.
--- fs/ocfs2/journal.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
fs/ocfs2/journal.c +10 -13
@@ -1544,7 +1544,6 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb, int slot_num) {int status; -int got_lock =0 ;unsigned int flags;struct inode *inode =NULL ;struct ocfs2_dinode *fe;
@@ -1555,7 +1554,7 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb, status =ocfs2_read_journal_inode (osb, slot_num, &bh, &inode);if (status) {mlog_errno (status); - goto done; +return status; } fe = (struct ocfs2_dinode *)bh->b_data;
@@ -1576,7 +1575,7 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb, osb->slot_recovery_generations[slot_num], slot_reco_gen); osb->slot_recovery_generations[slot_num] = slot_reco_gen; status = -EBUSY ; - goto done; + goto put_inode; }/* Continue with recovery as the journal has not yet been recovered */
@@ -1586,9 +1585,8 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb,trace_ocfs2_replay_journal_lock_err (status);if (status != -ERESTARTSYS )mlog (ML_ERROR ,"Could not lock journal!\n" ); - goto done; + goto put_inode; } - got_lock =1 ; fe = (struct ocfs2_dinode *) bh->b_data;
@@ -1599,7 +1597,7 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb,trace_ocfs2_replay_journal_skip (node_num);/* Refresh recovery generation for the slot */ osb->slot_recovery_generations[slot_num] = slot_reco_gen; - goto done; + goto unlock_inode; }/* we need to run complete recovery for offline orphan slots */
@@ -1614,14 +1612,14 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb, status =ocfs2_force_read_journal (inode);if (status <0 ) {mlog_errno (status); - goto done; + goto unlock_inode; } journal =jbd2_journal_init_inode (inode);if (journal =NULL ) {mlog (ML_ERROR ,"Linux journal layer error\n" ); status = -EIO ; - goto done; + goto unlock_inode; } status =jbd2_journal_load (journal);
@@ -1630,7 +1628,7 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb,if (!igrab (inode))BUG ();jbd2_journal_destroy (journal); - goto done; + goto unlock_inode; }ocfs2_clear_journal_error (osb->sb, journal, slot_num);
@@ -1665,11 +1663,10 @@ static int ocfs2_replay_journal(struct ocfs2_super *osb,printk (KERN_NOTICE "ocfs2: End replay journal (node %d, slot %d) on " \"device (%u,%u)\n" , node_num, slot_num,MAJOR (osb->sb->s_dev),MINOR (osb->sb->s_dev)); -done: +unlock_inode:/* drop the lock on this nodes journal */ -if (got_lock) -ocfs2_inode_unlock (inode,1 ); - +ocfs2_inode_unlock (inode,1 ); +put_inode:iput (inode);brelse (bh);
Signature · 1 line
2.4.5
PATCH 11/11 ocfs2: One function call less in ocfs2_journal_shutdown() from input checks
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 5 Jul 2015 14:54:33 +0200
The iput() function was called in one case by the ocfs2_journal_shutdown() function during input parameter validation even if the passed variable contained still a null pointer.
* Return directly if received values indicate that at the beginning.
* Delete the unnecessary jump label "done".
* Drop unnecessary initialisations for the variables "inode", "journal" and "num_running_trans" then.
--- fs/ocfs2/journal.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-)
fs/ocfs2/journal.c +6 -9
@@ -951,22 +951,20 @@ static int ocfs2_journal_toggle_dirty(struct ocfs2_super *osb,*/ void ocfs2_journal_shutdown (struct ocfs2_super *osb) { -struct ocfs2_journal *journal =NULL ; +struct ocfs2_journal *journal;int status =0 ; -struct inode *inode =NULL ; -int num_running_trans =0 ; +struct inode *inode; +int num_running_trans;BUG_ON (!osb); journal = osb->journal;if (!journal) - goto done; - - inode = journal->j_inode; - +return ;if (journal->j_state !=OCFS2_JOURNAL_LOADED ) - goto done; +return ; + inode = journal->j_inode;/* need to inc inode use count - jbd2_journal_destroy will iput. */ if (!igrab (inode))BUG ();
@@ -1025,7 +1023,6 @@ void ocfs2_journal_shutdown(struct ocfs2_super *osb) journal->j_state =OCFS2_JOURNAL_FREE ;// up_write(&journal->j_trans_barrier); -done:iput (inode); }
Signature · 1 line
2.4.5
PATCH 1/1 ceph: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringThe functions ceph_put_snap_context() and iput() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/ceph/caps.c | 3 +-- fs/ceph/mds_client.c | 6 ++---- fs/ceph/snap.c | 9 +++------ 3 files changed, 6 insertions(+), 12 deletions(-)
fs/ceph/caps.c +1 -2
@@ -3136,8 +3136,7 @@ flush_cap_releases: done:mutex_unlock (&session->s_mutex); done_unlocked: -if (inode) -iput (inode); +iput (inode);return ; bad:
fs/ceph/mds_client.c +2 -4
@@ -523,8 +523,7 @@ void ceph_mdsc_release_request(struct kref *kref) }if (req->r_locked_dir)ceph_put_cap_refs (ceph_inode (req->r_locked_dir),CEPH_CAP_PIN ); -if (req->r_target_inode) -iput (req->r_target_inode); +iput (req->r_target_inode);if (req->r_dentry)dput (req->r_dentry);if (req->r_old_dentry)
@@ -995,8 +994,7 @@ out: session->s_cap_iterator =NULL ;spin_unlock (&session->s_cap_lock); -if (last_inode) -iput (last_inode); +iput (last_inode);if (old_cap)ceph_put_cap (session->s_mdsc, old_cap);
fs/ceph/snap.c +1 -2
@@ -365,8 +365,7 @@ static int build_snap_context(struct ceph_snap_realm *realm) realm->ino, realm, snapc, snapc->seq, (unsigned int) snapc->num_snaps); -if (realm->cached_context) -ceph_put_snap_context (realm->cached_context); +ceph_put_snap_context (realm->cached_context); realm->cached_context = snapc;return 0 ;
@@ -590,15 +589,13 @@ static void queue_realm_cap_snaps(struct ceph_snap_realm
*realm)
if (!inode)
continue;
spin_unlock(&realm->inodes_with_caps_lock);
- if (lastinode)
- iput(lastinode);
+ iput(lastinode);
lastinode = inode; ceph_queue_cap_snap(ci); spin_lock(&realm->inodes_with_caps_lock);
} spin_unlock(&realm->inodes_with_caps_lock);
- if (lastinode)
- iput(lastinode);
+ iput(lastinode);
list_for_each_entry(child, &realm->children, child_item) {
dout("queue_realm_cap_snaps %p %llx queue child %p %llx\n",
Signature · 1 line
2.1.3
Ilya Dryomov
AppliedRe: [PATCH 1/1] ceph: Deletion of unnecessary checks before two function calls
Quoted 4 lines · SF Markus Elfring
The functions
ceph_put_snap_context()andiput()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
Quoted 8 lines
This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- fs/ceph/caps.c | 3 +-- fs/ceph/mds_client.c | 6 ++---- fs/ceph/snap.c | 9 +++------ 3 files changed, 6 insertions(+), 12 deletions(-)
[CC'ed Zheng]
Applied, but see below.
Quoted 20 lines
fs/ceph/caps.c +1
-2@@ -3136,8 +3136,7 @@ flush_cap_releases: done:mutex_unlock (&session->s_mutex); done_unlocked: -if (inode) -iput (inode); +iput (inode);return ; bad:fs/ceph/mds_client.c +0
-0
fs/ceph/mds_client.c void ceph_mdsc_release_request(struct kref *kref) · line 528
Quoted 8 lines
fs/ceph/mds_client.c +1
-2@@ -523,8 +523,7 @@ void ceph_mdsc_release_request(struct kref *kref) }if (req->r_locked_dir)ceph_put_cap_refs (ceph_inode (req->r_locked_dir),CEPH_CAP_PIN ); -if (req->r_target_inode) -iput (req->r_target_inode); +iput (req->r_target_inode);if (req->r_dentry)dput (req->r_dentry);
dput() also checks for NULL argument, but the check is wrapped into unlikely(), which is why I presume it wasn't picked up. It would be great if you could improve your coccinelle script to handle {un,}likely() as well.
Quoted 26 lines
fs/ceph/mds_client.c +1
-2if (req->r_old_dentry)@@ -995,8 +994,7 @@ out: session->s_cap_iterator =NULL ;spin_unlock (&session->s_cap_lock); -if (last_inode) -iput (last_inode); +iput (last_inode);if (old_cap)ceph_put_cap (session->s_mdsc, old_cap);fs/ceph/snap.c +1
-2@@ -365,8 +365,7 @@ static int build_snap_context(struct ceph_snap_realm *realm) realm->ino, realm, snapc, snapc->seq, (unsigned int) snapc->num_snaps); -if (realm->cached_context) -ceph_put_snap_context (realm->cached_context); +ceph_put_snap_context (realm->cached_context); realm->cached_context = snapc;return 0 ;
fs/ceph/snap.c static void queue_realm_cap_snaps(struct ceph_snap_realm · line 589
Quoted 1 line
fs/ceph/snap.c +0
-0@@ -590,15 +589,13 @@ static void queue_realm_cap_snaps(struct ceph_snap_realm *realm)
The patch was corrupted, that should have been a single line. I fixed it up but you may want to look into your email client settings.
Thanks,
Ilya
Re: ceph: Deletion of unnecessary checks before two function calls
Quoted 4 lines
dput()also checks for NULL argument, but the check is wrapped intounlikely(), which is why I presume it wasn't picked up. It would be great if you could improve your coccinelle script to handle {un,}likely() as well.
Thanks for your suggestion.
Should I consider any more fine-tuning for the affected script "list_input_parameter_validation1.cocci" in the near future?
https://lkml.org/lkml/2014/3/5/362
http://article.gmane.org/gmane.comp.version-control.coccinelle/3514
Quoted 5 lines
Review static void queue_realm_cap_snaps(struct ceph_snap_realm · line 589
Quoted 2 lines
(quoted diff) +0
-0@@ -590,15 +589,13 @@ static void queue_realm_cap_snaps(struct ceph_snap_realm *realm)The patch was corrupted, that should have been a single line. I fixed it up but you may want to look into your email client settings.
Thanks for your feedback.
Does this example show a conflict between long comments after patch ranges and line length limitation for email eventually?
Regards,
Markus
Re: ceph: Deletion of unnecessary checks before two function calls
Quoted 11 lines · SF Markus Elfring
Quoted 4 lines
dput()also checks for NULL argument, but the check is wrapped intounlikely(), which is why I presume it wasn't picked up. It would be great if you could improve your coccinelle script to handle {un,}likely() as well.Thanks for your suggestion.
Should I consider any more fine-tuning for the affected script "
list_input_parameter_validation1.cocci" in the near future?
https://lkml.org/lkml/2014/3/5/362
http://article.gmane.org/gmane.comp.version-control.coccinelle/3514
Make sure it at least catches stuff like:
{
if (input) {
}
}{
if (likely(input)) {
}
}{
if (!input)
return;
...
}{
if (unlikely(!input))
return;
...
}And of course each match then has to be validated manually.
Quoted 8 lines
Quoted 7 lines
Review static void queue_realm_cap_snaps(struct ceph_snap_realm · line 589
Quoted 4 lines
(quoted diff) +0
-0@@ -590,15 +589,13 @@ static void queue_realm_cap_snaps(struct ceph_snap_realm *realm)The patch was corrupted, that should have been a single line. I fixed it up but you may want to look into your email client settings.
Quoted 4 lines
Thanks for your feedback.
Does this example show a conflict between long comments after patch ranges and line length limitation for email eventually?
There is no line length limitation for email, at least one that would be relevant here. Patches should be sent verbatim, no line wrapping, expandtab, etc or they won't apply. I'd recommend git-send-email, but if you want to make thunderbird work for patches (which is what you seem to be using) have a look at the "Thunderbird (GUI)" section of Documentation/email-clients.txt in the kernel tree.
Thanks,
Ilya
PATCH 1/1 PCI: Deletion of unnecessary checks before three function calls
In reply to SF Markus ElfringThe functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/pci/pci-acpi.c | 3 +-- drivers/pci/probe.c | 3 +-- drivers/pci/search.c | 3 +-- drivers/pci/xen-pcifront.c | 3 +-- 4 files changed, 4 insertions(+), 8 deletions(-)
drivers/pci/pci-acpi.c +1 -2
@@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)pci_wakeup_event (pci_dev);pm_runtime_resume (&pci_dev->dev); -if (pci_dev->subordinate) -pci_pme_wakeup_bus (pci_dev->subordinate); +pci_pme_wakeup_bus (pci_dev->subordinate); }/**
drivers/pci/probe.c +1 -2
@@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev) {struct pci_bus *pci_bus =to_pci_bus (dev); -if (pci_bus->bridge) -put_device (pci_bus->bridge); +put_device (pci_bus->bridge);pci_bus_remove_resources (pci_bus);pci_release_bus_of_node (pci_bus);kfree (pci_bus);
drivers/pci/search.c +0 -0
@@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const struct
pci_device_id *id,
match_pci_dev_by_id);
if (dev)
pdev = to_pci_dev(dev);
- if (from)
- pci_dev_put(from);
+ pci_dev_put(from);
return pdev;
}
drivers/pci/xen-pcifront.c +1 -2
@@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd, pcidev =pci_get_bus_and_slot (bus, devfn);if (!pcidev || !pcidev->driver) {dev_err (&pdev->xdev->dev,"device or AER driver is NULL\n" ); -if (pcidev) -pci_dev_put (pcidev); +pci_dev_put (pcidev);return result; } pdrv = pcidev->driver;
Signature · 1 line
2.1.3
Re: [PATCH 1/1] PCI: Deletion of unnecessary checks before three function calls
Quoted 7 lines · SF Markus Elfring
The functions
pci_dev_put(),pci_pme_wakeup_bus()andput_device()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>
Applied to pci/misc for v3.19, thanks!
Quoted 68 lines
--- drivers/pci/pci-acpi.c | 3 +-- drivers/pci/probe.c | 3 +-- drivers/pci/search.c | 3 +-- drivers/pci/xen-pcifront.c | 3 +-- 4 files changed, 4 insertions(+), 8 deletions(-)drivers/pci/pci-acpi.c +1
-2@@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)pci_wakeup_event (pci_dev);pm_runtime_resume (&pci_dev->dev); -if (pci_dev->subordinate) -pci_pme_wakeup_bus (pci_dev->subordinate); +pci_pme_wakeup_bus (pci_dev->subordinate); }/** drivers/pci/probe.c +1
-2@@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev) {struct pci_bus *pci_bus =to_pci_bus (dev); -if (pci_bus->bridge) -put_device (pci_bus->bridge); +put_device (pci_bus->bridge);pci_bus_remove_resources (pci_bus);pci_release_bus_of_node (pci_bus);kfree (pci_bus);drivers/pci/search.c +1
-2@@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const structpci_device_id *id, match_pci_dev_by_id);if (dev) pdev =to_pci_dev (dev); -if (from) -pci_dev_put (from); +pci_dev_put (from);return pdev; }drivers/pci/xen-pcifront.c +1
-2@@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd, pcidev =pci_get_bus_and_slot (bus, devfn);if (!pcidev || !pcidev->driver) {dev_err (&pdev->xdev->dev,"device or AER driver is NULL\n" ); -if (pcidev) -pci_dev_put (pcidev); +pci_dev_put (pcidev);return result; } pdrv = pcidev->driver;Signature · 1 line
2.1.3
Re: [PATCH 1/1] PCI: Deletion of unnecessary checks before three function calls
In reply to SF Markus ElfringQuoted 7 lines · SF Markus Elfring
The functions
pci_dev_put(),pci_pme_wakeup_bus()andput_device()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>
Applied to pci/misc for v3.19, thanks!
Quoted 68 lines
--- drivers/pci/pci-acpi.c | 3 +-- drivers/pci/probe.c | 3 +-- drivers/pci/search.c | 3 +-- drivers/pci/xen-pcifront.c | 3 +-- 4 files changed, 4 insertions(+), 8 deletions(-)drivers/pci/pci-acpi.c +1
-2@@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)pci_wakeup_event (pci_dev);pm_runtime_resume (&pci_dev->dev); -if (pci_dev->subordinate) -pci_pme_wakeup_bus (pci_dev->subordinate); +pci_pme_wakeup_bus (pci_dev->subordinate); }/** drivers/pci/probe.c +1
-2@@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev) {struct pci_bus *pci_bus =to_pci_bus (dev); -if (pci_bus->bridge) -put_device (pci_bus->bridge); +put_device (pci_bus->bridge);pci_bus_remove_resources (pci_bus);pci_release_bus_of_node (pci_bus);kfree (pci_bus);drivers/pci/search.c +1
-2@@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const structpci_device_id *id, match_pci_dev_by_id);if (dev) pdev =to_pci_dev (dev); -if (from) -pci_dev_put (from); +pci_dev_put (from);return pdev; }drivers/pci/xen-pcifront.c +1
-2@@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd, pcidev =pci_get_bus_and_slot (bus, devfn);if (!pcidev || !pcidev->driver) {dev_err (&pdev->xdev->dev,"device or AER driver is NULL\n" ); -if (pcidev) -pci_dev_put (pcidev); +pci_dev_put (pcidev);return result; } pdrv = pcidev->driver;Signature · 1 line
2.1.3
PATCH 1/1 PCI: Deletion of unnecessary checks before three function calls
In reply to SF Markus ElfringThe functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- drivers/pci/pci-acpi.c | 3 +-- drivers/pci/probe.c | 3 +-- drivers/pci/search.c | 3 +-- drivers/pci/xen-pcifront.c | 3 +-- 4 files changed, 4 insertions(+), 8 deletions(-)
drivers/pci/pci-acpi.c +1 -2
@@ -60,8 +60,7 @@ static void pci_acpi_wake_dev(struct work_struct *work)pci_wakeup_event (pci_dev);pm_runtime_resume (&pci_dev->dev); -if (pci_dev->subordinate) -pci_pme_wakeup_bus (pci_dev->subordinate); +pci_pme_wakeup_bus (pci_dev->subordinate); }/**
drivers/pci/probe.c +1 -2
@@ -86,8 +86,7 @@ static void release_pcibus_dev(struct device *dev) {struct pci_bus *pci_bus =to_pci_bus (dev); -if (pci_bus->bridge) -put_device (pci_bus->bridge); +put_device (pci_bus->bridge);pci_bus_remove_resources (pci_bus);pci_release_bus_of_node (pci_bus);kfree (pci_bus);
drivers/pci/search.c +0 -0
@@ -305,8 +305,7 @@ static struct pci_dev *pci_get_dev_by_id(const struct
pci_device_id *id,
match_pci_dev_by_id);
if (dev)
pdev = to_pci_dev(dev);
- if (from)
- pci_dev_put(from);
+ pci_dev_put(from);
return pdev;
}
drivers/pci/xen-pcifront.c +1 -2
@@ -596,8 +596,7 @@ static pci_ers_result_t pcifront_common_process(int cmd, pcidev =pci_get_bus_and_slot (bus, devfn);if (!pcidev || !pcidev->driver) {dev_err (&pdev->xdev->dev,"device or AER driver is NULL\n" ); -if (pcidev) -pci_dev_put (pcidev); +pci_dev_put (pcidev);return result; } pdrv = pcidev->driver;
Signature · 1 line
2.1.3
PATCH 1/1 PCI: EMU10K1: Deletion of unnecessary checks before three function calls
In reply to SF Markus ElfringThe functions kfree(), release_firmware() and snd_util_memhdr_free() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- sound/pci/emu10k1/emu10k1_main.c | 9 +++------ sound/pci/emu10k1/emufx.c | 3 +-- 2 files changed, 4 insertions(+), 8 deletions(-)
sound/pci/emu10k1/emu10k1_main.c +3 -6
@@ -1289,10 +1289,8 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) }if (emu->emu1010.firmware_thread)kthread_stop (emu->emu1010.firmware_thread); -if (emu->firmware) -release_firmware (emu->firmware); -if (emu->dock_fw) -release_firmware (emu->dock_fw); +release_firmware (emu->firmware); +release_firmware (emu->dock_fw);if (emu->irq >=0 )free_irq (emu->irq, emu);/* remove reserved page */
@@ -1301,8 +1299,7 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) (struct snd_util_memblk *)emu->reserved_page); emu->reserved_page =NULL ; } -if (emu->memhdr) -snd_util_memhdr_free (emu->memhdr); +snd_util_memhdr_free (emu->memhdr);if (emu->silent_page.area)snd_dma_free_pages (&emu->silent_page);if (emu->ptb_pages.area)
sound/pci/emu10k1/emufx.c +0 -0
@@ -777,8 +777,7 @@ static void snd_emu10k1_ctl_private_free(struct snd_kcontrol
*kctl)
kctl->private_value = 0;
list_del(&ctl->list);
kfree(ctl);
- if (kctl->tlv.p)
- kfree(kctl->tlv.p);
+ kfree(kctl->tlv.p);
}
static int snd_emu10k1_add_controls(struct snd_emu10k1 *emu,
Signature · 1 line
2.1.3
Re: [PATCH 1/1] PCI: EMU10K1: Deletion of unnecessary checks before three function calls
At Sun, 02 Nov 2014 19:27:20 +0100,
Quoted 8 lines · SF Markus Elfring
The functions
kfree(),release_firmware()andsnd_util_memhdr_free()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>
Your patch can't be applied cleanly due to your MUA breaking the lines. Please fix your MUA setup, or use an attachment if it's impossible, and resend the patch.
Also, try to align the subject line with the relevant commits. See "git log sound/pci/emu10k1"
thanks,
Takashi
Quoted 51 lines
--- sound/pci/emu10k1/emu10k1_main.c | 9 +++------ sound/pci/emu10k1/emufx.c | 3 +-- 2 files changed, 4 insertions(+), 8 deletions(-)sound/pci/emu10k1/emu10k1_main.c +3
-6@@ -1289,10 +1289,8 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) }if (emu->emu1010.firmware_thread)kthread_stop (emu->emu1010.firmware_thread); -if (emu->firmware) -release_firmware (emu->firmware); -if (emu->dock_fw) -release_firmware (emu->dock_fw); +release_firmware (emu->firmware); +release_firmware (emu->dock_fw);if (emu->irq >=0 )free_irq (emu->irq, emu);/* remove reserved page */ @@ -1301,8 +1299,7 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) (struct snd_util_memblk *)emu->reserved_page); emu->reserved_page =NULL ; } -if (emu->memhdr) -snd_util_memhdr_free (emu->memhdr); +snd_util_memhdr_free (emu->memhdr);if (emu->silent_page.area)snd_dma_free_pages (&emu->silent_page);if (emu->ptb_pages.area)sound/pci/emu10k1/emufx.c +1
-2@@ -777,8 +777,7 @@ static void snd_emu10k1_ctl_private_free(struct snd_kcontrol *kctl) kctl->private_value =0 ;list_del (&ctl->list);kfree (ctl); -if (kctl->tlv.p) -kfree (kctl->tlv.p); +kfree (kctl->tlv.p); }static int snd_emu10k1_add_controls(struct
snd_emu10k1*emu,Signature · 1 line
2.1.3
Re: [PATCH resent] ALSA: emu10k1: Deletion of unnecessary checks before three function calls
Quoted 3 lines
Your patch can't be applied cleanly due to your MUA breaking the lines. Please fix your MUA setup, or use an attachment if it's impossible, and resend the patch.
Thanks for your feedback.
Does this example show a conflict between long comments like "snd_emu10k1_ctl_private_free( ... *kctl)" after patch ranges and line length limitation for email eventually?
Quoted 2 lines
Also, try to align the subject line with the relevant commits. See "git log
sound/pci/emu10k1"
I have attached my update suggestion with a slightly different commit title as before. Is this variant acceptable?
Regards,
Markus
Quoted 1 line
From
23bb7bd1325b7c9cc81761db3ebf3ea19f85338dMon Sep 17 00:00:00 2001
From: Markus Elfring <[email protected]>
Date: Mon, 3 Nov 2014 14:54:36 +0100
Subject: [PATCH] ALSA: emu10k1: Deletion of unnecessary checks before three
function calls
The functions kfree(), release_firmware() and snd_util_memhdr_free() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- sound/pci/emu10k1/emu10k1_main.c | 9 +++------ sound/pci/emu10k1/emufx.c | 3 +-- 2 files changed, 4 insertions(+), 8 deletions(-)
sound/pci/emu10k1/emu10k1_main.c +3 -6
@@ -1289,10 +1289,8 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) }if (emu->emu1010.firmware_thread)kthread_stop (emu->emu1010.firmware_thread); -if (emu->firmware) -release_firmware (emu->firmware); -if (emu->dock_fw) -release_firmware (emu->dock_fw); +release_firmware (emu->firmware); +release_firmware (emu->dock_fw);if (emu->irq >=0 )free_irq (emu->irq, emu);/* remove reserved page */
@@ -1301,8 +1299,7 @@ static int snd_emu10k1_free(struct snd_emu10k1 *emu) (struct snd_util_memblk *)emu->reserved_page); emu->reserved_page =NULL ; } -if (emu->memhdr) -snd_util_memhdr_free (emu->memhdr); +snd_util_memhdr_free (emu->memhdr);if (emu->silent_page.area)snd_dma_free_pages (&emu->silent_page);if (emu->ptb_pages.area)
sound/pci/emu10k1/emufx.c +1 -2
@@ -777,8 +777,7 @@ static void snd_emu10k1_ctl_private_free(struct snd_kcontrol *kctl) kctl->private_value =0 ;list_del (&ctl->list);kfree (ctl); -if (kctl->tlv.p) -kfree (kctl->tlv.p); +kfree (kctl->tlv.p); } static int snd_emu10k1_add_controls(struct snd_emu10k1 *emu,
Signature · 1 line
2.1.3
Re: [PATCH resent] ALSA: emu10k1: Deletion of unnecessary checks before three function calls
At Mon, 03 Nov 2014 15:10:40 +0100,
Quoted 10 lines · SF Markus Elfring
Quoted 4 lines
Your patch can't be applied cleanly due to your MUA breaking the lines. Please fix your MUA setup, or use an attachment if it's impossible, and resend the patch.
Thanks for your feedback.
Does this example show a conflict between long comments like "snd_emu10k1_ctl_private_free( ... *kctl)" after patch ranges and line length limitation for email eventually?
Conflict? It's your MUA that is broken.
Quoted 5 lines
Quoted 2 lines
Also, try to align the subject line with the relevant commits. See "git log
sound/pci/emu10k1"I have attached my update suggestion with a slightly different commit title as before. Is this variant acceptable?
So, you couldn't fix your MUA? That's bad for you. Many maintainers dislike attachments and won't accept such patches.
Couldn't you simply send a patch via git-send-email?
In anyway, I applied the patch now. Thanks.
Takashi
PATCH 1/1 kconfig: Deletion of unnecessary checks before the function call "sym_calc_value"
In reply to SF Markus ElfringThe sym_calc_value() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- scripts/kconfig/confdata.c | 6 ++---- scripts/kconfig/symbol.c | 3 +-- 2 files changed, 3 insertions(+), 6 deletions(-)
scripts/kconfig/confdata.c +2 -4
@@ -262,8 +262,7 @@ int conf_read_simple(const char *name, int def) goto load;sym_add_change_count (1 );if (!sym_defconfig_list) { -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 1 ; }
@@ -399,8 +398,7 @@ setsym:free (line);fclose (in); -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 0 ; }
scripts/kconfig/symbol.c +1 -2
@@ -447,8 +447,7 @@ void sym_clear_all_valid(void)for_all_symbols (i, sym) sym->flags &= ~SYMBOL_VALID;sym_add_change_count (1 ); -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym); }void sym_set_changed (struct symbol *sym)
Signature · 1 line
2.1.3
Re: [PATCH 1/1] kconfig: Deletion of unnecessary checks before the function call "sym_calc_value"
Since you use "SF Markus Elfring", this patch should start with:
From: Markus Elfring <[email protected]>
We don't care that you used a sourceforge.net address. Or has SF another meaning?
Quoted 4 lines · SF Markus Elfring
The
sym_calc_value()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Side note: I guess the coccinelle script you use just skips cases like
if (sym) {
sym_calc_value(sym);
do_foo_bar():
}Or did you filter those manually?
Quoted 35 lines
Signed-off-by Markus Elfring <[email protected]>--- scripts/kconfig/confdata.c | 6 ++---- scripts/kconfig/symbol.c | 3 +-- 2 files changed, 3 insertions(+), 6 deletions(-)scripts/kconfig/confdata.c +2
-4@@ -262,8 +262,7 @@ int conf_read_simple(const char *name, int def) goto load;sym_add_change_count (1 );if (!sym_defconfig_list) { -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 1 ; }@@ -399,8 +398,7 @@ setsym:free (line);fclose (in); -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 0 ; }scripts/kconfig/symbol.c +0
-0
scripts/kconfig/symbol.c void sym_clear_all_valid(void) · line 453
Quoted 9 lines
scripts/kconfig/symbol.c +1
-2@@ -447,8 +447,7 @@ void sym_clear_all_valid(void)for_all_symbols (i, sym) sym->flags &= ~SYMBOL_VALID;sym_add_change_count (1 ); -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym); }void sym_set_changed (struct symbol *sym)
Please resend with
added.
Paul Bolle
PATCH v2 1/1 kconfig: Deletion of unnecessary checks before the function call "sym_calc_value"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
The sym_calc_value() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- scripts/kconfig/confdata.c | 6 ++---- scripts/kconfig/symbol.c | 3 +-- 2 files changed, 3 insertions(+), 6 deletions(-)
scripts/kconfig/confdata.c +2 -4
@@ -262,8 +262,7 @@ int conf_read_simple(const char *name, int def) goto load;sym_add_change_count (1 );if (!sym_defconfig_list) { -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 1 ; }
@@ -399,8 +398,7 @@ setsym:free (line);fclose (in); -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 0 ; }
scripts/kconfig/symbol.c +1 -2
@@ -447,8 +447,7 @@ void sym_clear_all_valid(void)for_all_symbols (i, sym) sym->flags &= ~SYMBOL_VALID;sym_add_change_count (1 ); -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym); }void sym_set_changed (struct symbol *sym)
Signature · 1 line
2.1.3
PATCH v3 1/1 kconfig: Delete unnecessary checks before the function call "sym_calc_value"
From: Markus Elfring <[email protected]>
Date: Tue, 7 Jul 2015 21:48:23 +0200
The sym_calc_value() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- scripts/kconfig/confdata.c | 7 ++----- scripts/kconfig/symbol.c | 3 +-- 2 files changed, 3 insertions(+), 7 deletions(-)
scripts/kconfig/confdata.c +2 -5
@@ -268,8 +268,7 @@ int conf_read_simple(const char *name, int def) goto load;sym_add_change_count (1 );if (!sym_defconfig_list) { -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 1 ; }
@@ -404,9 +403,7 @@ setsym: }free (line);fclose (in); - -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym);return 0 ; }
scripts/kconfig/symbol.c +1 -2
@@ -467,8 +467,7 @@ void sym_clear_all_valid(void)for_all_symbols (i, sym) sym->flags &= ~SYMBOL_VALID;sym_add_change_count (1 ); -if (modules_sym) -sym_calc_value (modules_sym); +sym_calc_value (modules_sym); }bool sym_tristate_within_range (struct symbol *sym,tristate val)
Signature · 1 line
2.4.5
Re: [PATCH v3] kconfig: Delete unnecessary checks before the function call "sym_calc_value"
Quoted 7 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Tue, 7 Jul 2015 21:48:23 +0200The
sym_calc_value()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Applied to kbuild.git#kconfig.
Michal
PATCH 1/1 fs-ext4: Deletion of an unnecessary check before the function call "iput"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 19:04:06 +0100
The iput() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/ext4/mballoc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/ext4/mballoc.c +1 -2
@@ -2712,8 +2712,7 @@ int ext4_mb_release(struct super_block *sb) }kfree (sbi->s_mb_offsets);kfree (sbi->s_mb_maxs); -if (sbi->s_buddy_cache) -iput (sbi->s_buddy_cache); +iput (sbi->s_buddy_cache);if (sbi->s_mb_stats) { ext4_msg(sb, KERN_INFO, "mballoc: %u blocks %u reqs (%u success)",
Signature · 1 line
2.1.3
Re: [1/1] fs-ext4: Deletion of an unnecessary check before the function call "iput"
Quoted 9 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 19:04:06 +0100The
iput()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>
Thanks, applied.
- Ted
PATCH 1/1 ntfs: Deletion of unnecessary checks before the function call "iput"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 19:35:05 +0100
The iput() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/ntfs/super.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-)
fs/ntfs/super.c +7 -14
@@ -2204,17 +2204,12 @@ get_ctx_vol_failed:return true;#ifdef NTFS_RW iput_usnjrnl_err_out: -if (vol->usnjrnl_j_ino) -iput (vol->usnjrnl_j_ino); -if (vol->usnjrnl_max_ino) -iput (vol->usnjrnl_max_ino); -if (vol->usnjrnl_ino) -iput (vol->usnjrnl_ino); +iput (vol->usnjrnl_j_ino); +iput (vol->usnjrnl_max_ino); +iput (vol->usnjrnl_ino); iput_quota_err_out: -if (vol->quota_q_ino) -iput (vol->quota_q_ino); -if (vol->quota_ino) -iput (vol->quota_ino); +iput (vol->quota_q_ino); +iput (vol->quota_ino);iput (vol->extend_ino);#endif /* NTFS_RW */ iput_sec_err_out:
@@ -2223,8 +2218,7 @@ iput_root_err_out:iput (vol->root_ino); iput_logfile_err_out:#ifdef NTFS_RW -if (vol->logfile_ino) -iput (vol->logfile_ino); +iput (vol->logfile_ino); iput_vol_err_out:#endif /* NTFS_RW */ iput (vol->vol_ino);
@@ -2254,8 +2248,7 @@ iput_mftbmp_err_out:iput (vol->mftbmp_ino); iput_mirr_err_out:#ifdef NTFS_RW -if (vol->mftmirr_ino) -iput (vol->mftmirr_ino); +iput (vol->mftmirr_ino);#endif /* NTFS_RW */ return false; }
Signature · 1 line
2.1.3
Re: [Cocci] [PATCH 1/1] ntfs: Deletion of unnecessary checks before the function call "iput"
Quoted 18 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 19:35:05 +0100The
iput()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- fs/ntfs/super.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-)fs/ntfs/super.c +0
-0
fs/ntfs/super.c get_ctx_vol_failed: · line 2206
Quoted 3 lines
fs/ntfs/super.c +0
-0@@ -2204,17 +2204,12 @@ get_ctx_vol_failed:return true;#ifdef NTFS_RW iput_usnjrnl_err_out:
I don't have time to look at the code now, but since there is an exit label here, have you checked whether you could improve the gotos in these cases?
julia
Quoted 48 lines
fs/ntfs/super.c +7
-14-if (vol->usnjrnl_j_ino) -iput (vol->usnjrnl_j_ino); -if (vol->usnjrnl_max_ino) -iput (vol->usnjrnl_max_ino); -if (vol->usnjrnl_ino) -iput (vol->usnjrnl_ino); +iput (vol->usnjrnl_j_ino); +iput (vol->usnjrnl_max_ino); +iput (vol->usnjrnl_ino); iput_quota_err_out: -if (vol->quota_q_ino) -iput (vol->quota_q_ino); -if (vol->quota_ino) -iput (vol->quota_ino); +iput (vol->quota_q_ino); +iput (vol->quota_ino);iput (vol->extend_ino);#endif /* NTFS_RW */ iput_sec_err_out:@@ -2223,8 +2218,7 @@ iput_root_err_out:iput (vol->root_ino); iput_logfile_err_out:#ifdef NTFS_RW -if (vol->logfile_ino) -iput (vol->logfile_ino); +iput (vol->logfile_ino); iput_vol_err_out:#endif /* NTFS_RW */ iput (vol->vol_ino);@@ -2254,8 +2248,7 @@ iput_mftbmp_err_out:iput (vol->mftbmp_ino); iput_mirr_err_out:#ifdef NTFS_RW -if (vol->mftmirr_ino) -iput (vol->mftmirr_ino); +iput (vol->mftmirr_ino);#endif /* NTFS_RW */ return false; }Signature · 7 lines
2.1.3 _______________________________________________ Cocci mailing list Cocci at systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [PATCH] ntfs: Deletion of unnecessary checks before the function call "iput"
In reply to SF Markus ElfringQuoted 52 lines
From: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 19:35:05 +0100The
iput()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- fs/ntfs/super.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-)fs/ntfs/super.c +6
-12@@ -2204,17 +2204,12 @@ get_ctx_vol_failed:return true;#ifdef NTFS_RW iput_usnjrnl_err_out: -if (vol->usnjrnl_j_ino) -iput (vol->usnjrnl_j_ino); -if (vol->usnjrnl_max_ino) -iput (vol->usnjrnl_max_ino); -if (vol->usnjrnl_ino) -iput (vol->usnjrnl_ino); +iput (vol->usnjrnl_j_ino); +iput (vol->usnjrnl_max_ino); +iput (vol->usnjrnl_ino); iput_quota_err_out: -if (vol->quota_q_ino) -iput (vol->quota_q_ino); -if (vol->quota_ino) -iput (vol->quota_ino); +iput (vol->quota_q_ino); +iput (vol->quota_ino);iput (vol->extend_ino);#endif /* NTFS_RW */ iput_sec_err_out:@@ -2223,8 +2218,7 @@ iput_root_err_out:iput (vol->root_ino); iput_logfile_err_out:#ifdef NTFS_RW -if (vol->logfile_ino) -iput (vol->logfile_ino); +iput (vol->logfile_ino); iput_vol_err_out:#endif /* NTFS_RW */ iput (vol->vol_ino);
fs/ntfs/super.c iput_mftbmp_err_out: · line 2254
Quoted 9 lines
fs/ntfs/super.c +1
-2@@ -2254,8 +2248,7 @@ iput_mftbmp_err_out:iput (vol->mftbmp_ino); iput_mirr_err_out:#ifdef NTFS_RW -if (vol->mftmirr_ino) -iput (vol->mftmirr_ino); +iput (vol->mftmirr_ino);#endif /* NTFS_RW */ return false; }
Would you like to integrate this update suggestion into another source code repository?
Regards,
Markus
Anton Altaparmakov
Reviewed-byRe: [PATCH] ntfs: Deletion of unnecessary checks before the function call "iput"
Hi Andrew,
Can you please take up this trivial patch and merge it upstream?
Thanks a lot in advance!
Best regards,
Anton
Quoted 69 lines · SF Markus Elfring
Quoted 58 lines
From: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 19:35:05 +0100The
iput()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>---
fs/ntfs/super.c| 21 +++++++--------------1 file changed, 7 insertions(+), 14 deletions(-)fs/ntfs/super.c +0
-0@@ -2204,17 +2204,12 @@ get_ctx_vol_failed:return true;#ifdef NTFS_RW
iput_usnjrnl_err_out:fs/ntfs/super.c +3
-6-if (vol->usnjrnl_j_ino) -iput (vol->usnjrnl_j_ino); -if (vol->usnjrnl_max_ino) -iput (vol->usnjrnl_max_ino); -if (vol->usnjrnl_ino) -iput (vol->usnjrnl_ino); +iput (vol->usnjrnl_j_ino); +iput (vol->usnjrnl_max_ino); +iput (vol->usnjrnl_ino);
iput_quota_err_out:fs/ntfs/super.c +2
-4-if (vol->quota_q_ino) -iput (vol->quota_q_ino); -if (vol->quota_ino) -iput (vol->quota_ino); +iput (vol->quota_q_ino); +iput (vol->quota_ino);iput(vol->extend_ino);#endif /*
NTFS_RW*/iput_sec_err_out:fs/ntfs/super.c +0
-0@@ -2223,8 +2218,7 @@ iput_root_err_out:iput (vol->root_ino);
iput_logfile_err_out:
#ifdefNTFS_RWfs/ntfs/super.c +1
-2-if (vol->logfile_ino) -iput (vol->logfile_ino); +iput (vol->logfile_ino);
iput_vol_err_out:#endif /* NTFS_RW */ iput(vol->vol_ino);fs/ntfs/super.c +0
-0@@ -2254,8 +2248,7 @@ iput_mftbmp_err_out:iput (vol->mftbmp_ino);
iput_mirr_err_out:
#ifdefNTFS_RWfs/ntfs/super.c +1
-2-if (vol->mftmirr_ino) -iput (vol->mftmirr_ino); +iput (vol->mftmirr_ino);Quoted 4 lines
#endif /* NTFS_RW */ return false; }Would you like to integrate this update suggestion into another source code repository?
Regards,
Markus
Signature · 3 lines
Anton Altaparmakov <anton at tuxera.com> (replace at with @) Lead in File System Development, Tuxera Inc., http://www.tuxera.com/ Linux NTFS maintainer
Andrew Morton
maintainerRe: [PATCH] ntfs: Deletion of unnecessary checks before the function call "iput"
Quoted 6 lines · On Sat, 4 Jul 2015 10:36:57 +0000 Anton Altaparmakov <[email protected]> wrote:
Hi Andrew,
Can you please take up this trivial patch and merge it upstream?
Reviewed-by Anton Altaparmakov <[email protected]>
Nobody responded to Julia's review comment: "I don't have time to look at the code now, but since there is an exit label here, have you checked whether you could improve the gotos in these cases?"
She has a good point. We can either change those gotos to go to the correct place (current code is rather bizarre) or we can simply do
fs/ntfs/super.c renamed from fs/ntfs/super.c~a +3 -14
@@ -2202,36 +2202,26 @@ get_ctx_vol_failed: }#endif /* NTFS_RW */ return true; +out:#ifdef NTFS_RW -iput_usnjrnl_err_out:iput (vol->usnjrnl_j_ino);iput (vol->usnjrnl_max_ino);iput (vol->usnjrnl_ino); -iput_quota_err_out:iput (vol->quota_q_ino);iput (vol->quota_ino);iput (vol->extend_ino);#endif /* NTFS_RW */ -iput_sec_err_out:iput (vol->secure_ino); -iput_root_err_out:iput (vol->root_ino); -iput_logfile_err_out:#ifdef NTFS_RW iput (vol->logfile_ino); -iput_vol_err_out:#endif /* NTFS_RW */ iput (vol->vol_ino); -iput_lcnbmp_err_out:iput (vol->lcnbmp_ino); -iput_attrdef_err_out: vol->attrdef_size =0 ; - if (vol->attrdef) { - ntfs_free(vol->attrdef); - vol->attrdef = NULL; - } +ntfs_free (vol->attrdef); + vol->attrdef =NULL ;#ifdef NTFS_RW -iput_upcase_err_out:#endif /* NTFS_RW */ vol->upcase_len =0 ;mutex_lock (&ntfs_lock);
@@ -2246,7 +2236,6 @@ iput_upcase_err_out: } iput_mftbmp_err_out:iput (vol->mftbmp_ino); -iput_mirr_err_out:#ifdef NTFS_RW iput (vol->mftmirr_ino);#endif /* NTFS_RW */
(note that ntfs_free(NULL) is OK)
then change all the appropriate gotos to good old "goto out;".
Or we can not bother ;)
PATCH 1/1 fs-fat: Less function calls in fat_fill_super() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 20:55:23 +0100
The iput() function was called in an inefficient way by the implementation of the fat_fill_super() function in case of an allocation failure. The corresponding source code was improved by deletion of two unnecessary null pointer checks and a few adjustments for jump labels.
--- fs/fat/inode.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
fs/fat/inode.c +10 -8
@@ -1716,20 +1716,20 @@ int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat, fsinfo_inode =new_inode (sb);if (!fsinfo_inode) - goto out_fail; + goto fsinfo_inode_failure; fsinfo_inode->i_ino =MSDOS_FSINFO_INO ; sbi->fsinfo_inode = fsinfo_inode;insert_inode_hash (fsinfo_inode); root_inode =new_inode (sb);if (!root_inode) - goto out_fail; + goto other_failure; root_inode->i_ino =MSDOS_ROOT_INO ; root_inode->i_version =1 ; error =fat_read_root (root_inode);if (error <0 ) {iput (root_inode); - goto out_fail; + goto other_failure; } error = -ENOMEM ;insert_inode_hash (root_inode);
@@ -1737,7 +1737,7 @@ int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat, sb->s_root =d_make_root (root_inode);if (!sb->s_root) {fat_msg (sb,KERN_ERR ,"get root inode failed" ); - goto out_fail; + goto other_failure; }if (sbi->options.discard) {
@@ -1756,11 +1756,13 @@ out_invalid:if (!silent)fat_msg (sb,KERN_INFO ,"Can't find a valid FAT filesystem" ); +other_failure: +iput (fsinfo_inode); + +fsinfo_inode_failure: +iput (fat_inode); + out_fail: -if (fsinfo_inode) -iput (fsinfo_inode); -if (fat_inode) -iput (fat_inode);unload_nls (sbi->nls_io);unload_nls (sbi->nls_disk);if (sbi->options.iocharset != fat_default_iocharset)
Signature · 1 line
2.1.3
Re: [PATCH 1/1] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 21 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 20:55:23 +0100The
iput()function was called in an inefficient way by the implementation of thefat_fill_super()function in case of an allocation failure. The corresponding source code was improved by deletion of two unnecessary null pointer checks and a few adjustments for jump labels.Signed-off-by Markus Elfring <[email protected]>--- fs/fat/inode.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)fs/fat/inode.c +0
-0@@ -1716,20 +1716,20 @@ int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat, fsinfo_inode =new_inode (sb);if (!fsinfo_inode)
fs/fat/inode.c int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat, · line 1726
Quoted 10 lines
fs/fat/inode.c +2
-2- goto out_fail; + goto fsinfo_inode_failure; fsinfo_inode->i_ino =MSDOS_FSINFO_INO ; sbi->fsinfo_inode = fsinfo_inode;insert_inode_hash (fsinfo_inode); root_inode =new_inode (sb);if (!root_inode) - goto out_fail; + goto other_failure;
Other_failure is not such a good name. The one above is better.
julia
Quoted 46 lines
fs/fat/inode.c +8
-6root_inode->i_ino =MSDOS_ROOT_INO ; root_inode->i_version =1 ; error =fat_read_root (root_inode);if (error <0 ) {iput (root_inode); - goto out_fail; + goto other_failure; } error = -ENOMEM ;insert_inode_hash (root_inode);@@ -1737,7 +1737,7 @@ int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat, sb->s_root =d_make_root (root_inode);if (!sb->s_root) {fat_msg (sb,KERN_ERR ,"get root inode failed" ); - goto out_fail; + goto other_failure; }if (sbi->options.discard) {@@ -1756,11 +1756,13 @@ out_invalid:if (!silent)fat_msg (sb,KERN_INFO ,"Can't find a valid FAT filesystem" ); +other_failure: +iput (fsinfo_inode); + +fsinfo_inode_failure: +iput (fat_inode); + out_fail: -if (fsinfo_inode) -iput (fsinfo_inode); -if (fat_inode) -iput (fat_inode);unload_nls (sbi->nls_io);unload_nls (sbi->nls_disk);if (sbi->options.iocharset != fat_default_iocharset)Signature · 7 lines
2.1.3 -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v2 1/1 fs-fat: Less function calls in fat_fill_super() after error detection
From: Markus Elfring <[email protected]>
Date: Sat, 29 Nov 2014 07:37:34 +0100
The iput() function was called in an inefficient way by the implementation of the fat_fill_super() function in case of an allocation failure. The corresponding source code was improved by deletion of two unnecessary null pointer checks and a few adjustments for jump labels.
--- fs/fat/inode.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
fs/fat/inode.c +10 -8
@@ -1716,20 +1716,20 @@ int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat, fsinfo_inode =new_inode (sb);if (!fsinfo_inode) - goto out_fail; + goto fsinfo_inode_failure; fsinfo_inode->i_ino =MSDOS_FSINFO_INO ; sbi->fsinfo_inode = fsinfo_inode;insert_inode_hash (fsinfo_inode); root_inode =new_inode (sb);if (!root_inode) - goto out_fail; + goto failure_exit; root_inode->i_ino =MSDOS_ROOT_INO ; root_inode->i_version =1 ; error =fat_read_root (root_inode);if (error <0 ) {iput (root_inode); - goto out_fail; + goto failure_exit; } error = -ENOMEM ;insert_inode_hash (root_inode);
@@ -1737,7 +1737,7 @@ int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat, sb->s_root =d_make_root (root_inode);if (!sb->s_root) {fat_msg (sb,KERN_ERR ,"get root inode failed" ); - goto out_fail; + goto failure_exit; }if (sbi->options.discard) {
@@ -1756,11 +1756,13 @@ out_invalid:if (!silent)fat_msg (sb,KERN_INFO ,"Can't find a valid FAT filesystem" ); +failure_exit: +iput (fsinfo_inode); + +fsinfo_inode_failure: +iput (fat_inode); + out_fail: -if (fsinfo_inode) -iput (fsinfo_inode); -if (fat_inode) -iput (fat_inode);unload_nls (sbi->nls_io);unload_nls (sbi->nls_disk);if (sbi->options.iocharset != fat_default_iocharset)
Signature · 1 line
2.1.3
OGAWA Hirofumi
maintainerRe: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 7 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sat, 29 Nov 2014 07:37:34 +0100The
iput()function was called in an inefficient way by the implementation of thefat_fill_super()function in case of an allocation failure. The corresponding source code was improved by deletion of two unnecessary null pointer checks and a few adjustments for jump labels.
iput() checks NULL of inode. What is wrong just remove NULL check, instead of adding new jump labels?
Thanks.
Signature · 1 line
OGAWA Hirofumi <[email protected]>
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 5 lines · OGAWA Hirofumi
Quoted 3 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sat, 29 Nov 2014 07:37:34 +0100
Quoted 7 lines
Quoted 4 lines
The
iput()function was called in an inefficient way by the implementation of thefat_fill_super()function in case of an allocation failure. The corresponding source code was improved by deletion of two unnecessary null pointer checks and a few adjustments for jump labels.
iput()checks NULL of inode. What is wrong just remove NULL check, instead of adding new jump labels?
Personally, I prefer that code that can be statically determined not to need to be executed not to be executed. It can make the code easier to understand, because each function is only called when doing so is useful, and it can be helpful to static analysis.
julia
OGAWA Hirofumi
maintainerRe: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 7 lines · Julia Lawall
Quoted 2 lines
iput()checks NULL of inode. What is wrong just remove NULL check, instead of adding new jump labels?Personally, I prefer that code that can be statically determined not to need to be executed not to be executed. It can make the code easier to understand, because each function is only called when doing so is useful, and it can be helpful to static analysis.
Hm, first of all, we want to prevent the bugs. More labels are more chances of bug (and we don't care micro optimize on this error path), isn't it? Increasing the chance of bugs and bothers developers for analyzer sounds like strange.
(And we are initializing those for avoiding to be bothered by choosing correct label. If we really care micro optimize, initialization of those should not be required and should not be touched on other paths, and gcc can warn its usage.)
Thanks.
Signature · 1 line
OGAWA Hirofumi <[email protected]>
Re: fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 2 lines
More labels are more chances of bug (and we don't care micro optimize on this error path), isn't it?
I would prefer that a few jump targets can be redirected so that unnecessary function calls (and corresponding checks) can be avoided.
Quoted 2 lines
Increasing the chance of bugs and bothers developers for analyzer sounds like strange.
There are different opinions around source code clarity.
Quoted 2 lines
(And we are initializing those for avoiding to be bothered by choosing correct label.
Pointer initialisation is convenient and safe in some use cases, isn't it?
Quoted 3 lines
If we really care micro optimize, initialization of those should not be required and should not be touched on other paths, and gcc can warn its usage.)
I imagine that a software optimiser can eventually perform better job if unneeded statements could be omitted, couldn't it?
Regards,
Markus
Re: fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 5 lines · SF Markus Elfring
Quoted 2 lines
More labels are more chances of bug (and we don't care micro optimize on this error path), isn't it?
I would prefer that a few jump targets can be redirected so that unnecessary function calls (and corresponding checks) can be avoided.
It is from real bugs in my experience, it saw several times those (mine and other guys, in linux and others). And I think it doesn't have value to maintain labels for micro optimization in *this error path* though.
So, if you or analyzer can check bugs by the patches affect to those label usage in future,
Signature · 1 line
OGAWA Hirofumi <[email protected]>
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
In reply to OGAWA HirofumiQuoted 10 lines · OGAWA Hirofumi
Quoted 7 lines · Julia Lawall
Quoted 2 lines
iput()checks NULL of inode. What is wrong just remove NULL check, instead of adding new jump labels?Personally, I prefer that code that can be statically determined not to need to be executed not to be executed. It can make the code easier to understand, because each function is only called when doing so is useful, and it can be helpful to static analysis.
Quoted 4 lines
Hm, first of all, we want to prevent the bugs. More labels are more chances of bug (and we don't care micro optimize on this error path), isn't it? Increasing the chance of bugs and bothers developers for analyzer sounds like strange.
Oh wow! Absolutely not. "One Err Bugs" are one of the most common kinds of bugs we have in the kernel. This is where you have just one error label and the bugs look like this:
err:
kfree(foo->bar); kfree(foo);
but foo is NULL. Mixing the error paths together it always creates confusion. I fix so many of these bugs... We get a few new ones every week.
Meanwhile Markus's error labels are absolutely useless. They give no indication of what going to the label does.
regards,
dan carpenter
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 20 lines · Dan Carpenter
Quoted 10 lines · OGAWA Hirofumi
Quoted 7 lines · Julia Lawall
Quoted 2 lines
iput()checks NULL of inode. What is wrong just remove NULL check, instead of adding new jump labels?Personally, I prefer that code that can be statically determined not to need to be executed not to be executed. It can make the code easier to understand, because each function is only called when doing so is useful, and it can be helpful to static analysis.
Quoted 4 lines
Hm, first of all, we want to prevent the bugs. More labels are more chances of bug (and we don't care micro optimize on this error path), isn't it? Increasing the chance of bugs and bothers developers for analyzer sounds like strange.
Oh wow! Absolutely not. "One Err Bugs" are one of the most common kinds of bugs we have in the kernel. This is where you have just one error label and the bugs look like this:
Quoted 7 lines
err:
kfree(foo->bar); kfree(foo);but foo is NULL. Mixing the error paths together it always creates confusion. I fix so many of these bugs... We get a few new ones every week.
Just for concreteness, from drivers/clk/st/clkgen-mux.c (- indicates lines of interest, not lines to remove):
@@ -722,7 +722,6 @@ void __init st_of_clkgen_vcc_setup(struc
return;
clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
- if (!clk_data)
goto err;
clk_data->clk_num = VCC_MAX_CHANNELS;
@@ -808,7 +807,6 @@ void __init st_of_clkgen_vcc_setup(struc
return;err:
- for (i = 0; i < clk_data->clk_num; i++) {
struct clk_composite *composite;
if (!clk_data->clks[i])julia
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
In reply to Dan CarpenterQuoted 2 lines
Mixing the error paths together it always creates confusion. I fix so many of these bugs... We get a few new ones every week.
Would you like to get help here from any other automatic semantic patch approaches?
Quoted 2 lines
Meanwhile Markus's error labels are absolutely useless. They give no indication of what going to the label does.
Which names would be better acceptable for you?
Regards,
Markus
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 4 lines · SF Markus Elfring
Quoted 2 lines
Meanwhile Markus's error labels are absolutely useless. They give no indication of what going to the label does.
Which names would be better acceptable for you?
You named it after the goto location but the label name should be based on the label location to say what the goto does. Something like "err_put_fsinfo", "err_put_fat", and "err_unload" or like that.
regards,
dan carpenter
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 4 lines
Quoted 1 line
Which names would be better acceptable for you?
You named it after the goto location but the label name should be based on the label location to say what the goto does.
I find it easier occasionally to name a label similarly to the jump target. It seems that there are a few variations used for the affected identifiers.
Quoted 1 line
Something like "
err_put_fsinfo", "err_put_fat", and "err_unload" or like that.
How do you think about to provide a patch with your preferred names if my chances are lower to suggest the pleasing ones directly in my first tries?
Regards,
Markus
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 6 lines · SF Markus Elfring
Quoted 4 lines
Quoted 1 line
Which names would be better acceptable for you?
You named it after the goto location but the label name should be based on the label location to say what the goto does.
I find it easier occasionally to name a label similarly to the jump target.
That is a useless thing to do.
Quoted 1 line
It seems that there are a few variations used for the affected identifiers.
There is a lot of crap code in the kernel, yes.
regards,
dan carpenter
Re: [PATCH v2] fs-fat: Less function calls in fat_fill_super() after error detection
Quoted 6 lines · Dan Carpenter
Quoted 5 lines · SF Markus Elfring
Quoted 4 lines
Quoted 1 line
Which names would be better acceptable for you?
You named it after the goto location but the label name should be based on the label location to say what the goto does.
Quoted 7 lines
Quoted 1 line
I find it easier occasionally to name a label similarly to the jump target.
That is a useless thing to do.
Quoted 1 line
It seems that there are a few variations used for the affected identifiers.
There is a lot of crap code in the kernel, yes.
Does the label naming strategy appear in the conding style documentation anywhere? There are so many variants that just from looking at the code, it is hard to guess what is the best strategy. For example, out1, out2, etc are pretty uninformative, but they are concise and easy to spell correctly.
julia
PATCH 1/1 CodingStyle: add some more error handling guidelines
I added a paragraph on choosing label names, and updated the example code to use a better label name. I also cleaned up the example code to more modern style by moving the allocation out of the initializer and changing the NULL check.
Perhaps the most common type of error handling bug in the kernel is "one err bugs". CodingStyle already says that we should "avoid nesting" by using error labels and one err style error handling tends to have multiple indent levels, so this was already bad style. But I've added a new paragraph explaining how to avoid one err bugs by using multiple error labels which is, hopefully, more clear.
Documentation/CodingStyle +22 -5
@@ -392,7 +392,12 @@ The goto statement comes in handy when a function exits from multiple locations and some common work such as cleanup has to be done. If there is no cleanup needed then just return directly. -The rationale is: +Choose label names which say what the goto does or why the goto exists. An +example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid +using GW-BASIC names like "err1:" and "err2:". Also don't name them after the +goto location like "err_kmalloc_failed:" + +The rationale for using gotos is: - unconditional statements are easier to understand and follow - nesting is reduced
@@ -403,9 +408,10 @@ The rationale is: int fun(int a) { int result = 0; - char *buffer = kmalloc(SIZE); + char *buffer; - if (buffer == NULL) + buffer = kmalloc(SIZE); + if (!buffer) return -ENOMEM; if (condition1) {
@@ -413,14 +419,25 @@ int fun(int a) ... } result = 1; - goto out; + goto out_buffer; } ... -out: +out_buffer: kfree(buffer); return result; } +A common type of bug to be aware of it "one err bugs" which look like this: + +err: + kfree(foo->bar); + kfree(foo); + return ret; + +The bug in this code is that on some exit paths "foo" is NULL. Normally the +fix for this is to split it up into two error labels "err_bar:" and "err_foo:". + + Chapter 8: Commenting Comments are good, but there is also a danger of over-commenting. NEVER
Re: [patch] CodingStyle: add some more error handling guidelines
Documentation/CodingStyle The rationale is: · line 413
Quoted 9 lines
Documentation/CodingStyle +2
-2@@ -403,9 +408,10 @@ The rationale is: int fun(int a) { int result = 0; - char *buffer = kmalloc(SIZE); + char *buffer; - if (buffer == NULL) + buffer = kmalloc(SIZE);
kmalloc actually takes two arguments. Perhaps it would be better to show something that looks like a valid call.
Otherwise,
julia
Quoted 37 lines
Documentation/CodingStyle +14
-3+ if (!buffer) return -ENOMEM; if (condition1) {@@ -413,14 +419,25 @@ int fun(int a) } result = 1; - goto out; + goto out_buffer; } -out: +out_buffer: kfree(buffer); return result; } +A common type of bug to be aware of it "one err bugs" which look like this: + +err: + kfree(foo->bar); + kfree(foo); + return ret; + +The bug in this code is that on some exit paths "foo" is NULL. Normally the +fix for this is to split it up into two error labels "err_bar:" and "err_foo:". + + Chapter 8: Commenting Comments are good, but there is also a danger of over-commenting. NEVER --To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jonathan Corbet
maintainerRe: [patch] CodingStyle: add some more error handling guidelines
Quoted 2 lines · On Tue, 2 Dec 2014 10:09:02 +0100 (CET) Julia Lawall <[email protected]>…
kmalloc actually takes two arguments. Perhaps it would be better to show something that looks like a valid call.
Agreed; I took the liberty of sticking in a GFP_KERNEL as I applied the patch with Julia's ack.
Thanks,
jon
Re: [patch] CodingStyle: add some more error handling guidelines
In reply to Dan CarpenterDocumentation/CodingStyle The goto statement comes in handy when a function exits from multiple · line 398
Quoted 13 lines
Documentation/CodingStyle +4
-1@@ -392,7 +392,12 @@ The goto statement comes in handy when a function exits from multiple locations and some common work such as cleanup has to be done. If there is no cleanup needed then just return directly. -The rationale is: +Choose label names which say what the goto does or why the goto exists. An +[...] Avoid +using GW-BASIC names like "err1:" and "err2:". Also don't name them after the +goto location like "err_kmalloc_failed:"
I find this documentation approach not safe and clear enough so far.
* How should the reference to an other programming language help in the understanding of the recommended naming convention for jump labels?
* To which source code place should the word "location" refer to?
- jump source
- jump target
Regards,
Markus
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 16 lines · SF Markus Elfring
Documentation/CodingStyle The goto statement comes in handy when a function exits from multiple · line 398
Quoted 13 lines
Documentation/CodingStyle +4
-1@@ -392,7 +392,12 @@ The goto statement comes in handy when a function exits from multiple locations and some common work such as cleanup has to be done. If there is no cleanup needed then just return directly. -The rationale is: +Choose label names which say what the goto does or why the goto exists. An +[...] Avoid +using GW-BASIC names like "err1:" and "err2:". Also don't name them after the +goto location like "err_kmalloc_failed:"I find this documentation approach not safe and clear enough so far.
Quoted 6 lines
* How should the reference to an other programming language help in the understanding of the recommended naming convention for jump labels?
* To which source code place should the word "location" refer to?
- jump source
- jump target
I think you digested the paragraph in too small bits. The term "goto location" looks synonymous to "jump source" to me.
Regards,
Arend
Quoted 6 lines
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 5 lines
Quoted 3 lines
* To which source code place should the word "location" refer to?
- jump source
- jump targetI think you digested the paragraph in too small bits.
I would prefer to reduce the probability for misunderstandings of the proposed wording a bit more.
Quoted 1 line
The term "goto location" looks synonymous to "jump source" to me.
I would interpret it differently because of the specific placement of this key word before an other term.
Regards,
Markus
Re: [patch] CodingStyle: add some more error handling guidelines
In reply to SF Markus ElfringQuoted 4 lines · SF Markus Elfring
* To which source code place should the word "location" refer to?
- jump source
- jump target
jump target.
regards,
dan carpenter
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 7 lines · Dan Carpenter
Quoted 4 lines · SF Markus Elfring
* To which source code place should the word "location" refer to?
- jump source
- jump targetjump target.
I think you mean source? Or it really is ambiguous. The example was err_kmalloc_failed, which seems source-related.
julia
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 4 lines · Julia Lawall
Quoted 2 lines · Dan Carpenter
Quoted 1 line · SF Markus Elfring
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
* To which source code place should the word "location" refer to?
- jump source
- jump targetjump target.
I think you mean source? Or it really is ambiguous. The example was
err_kmalloc_failed, which seems source-related.
Yeah. You're right. I misread Markus's email. The goto location is where the goto is. The label location is where the label is.
regards,
dan carpenter
[Cocci] while compiling coccci 1.0.0-rc22
In reply to Julia LawallHi,
Anyone got this?
/home/berenger/.opam/4.01.0/bin/ocamlopt.opt -unsafe -I /home/berenger/.opam/4.01.0/lib/menhirLib -I /home/berenger/.opam/4.01.0/lib/ocaml -I /home/berenger/.opam/4.01.0/lib/pcre -I /home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml/ -I commons -I commons/ocamlextra -I ctl -I engine -I extra -I globals -I ocaml -Iparsing_c -I parsing_cocci -I popl09 -I python -cclib -lpycaml_stubs
-cclib -lpython2.7 -ccopt -lpcre -cclib -lpcre_stubs -o spatch.opt str.cmxa unix.cmxa bigarray.cmxa nums.cmxa /home/berenger/.opam/4.01.0/lib/ocaml/dynlink.cmxa /home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml//pycaml.cmxa /home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxa commons/commons.cmxa globals/globals.cmxa ctl/ctl.cmxa parsing_cocci/cocci_parser.cmxa parsing_c/parsing_c.cmxa engine/cocciengine.cmxa popl09/popl.cmxa extra/extra.cmxa python/coccipython.cmxa ocaml/cocciocaml.cmxa flag_cocci.cmx cocci.cmx testing.cmx test.cmx main.cmx
File "_none_", line 1:
Error: No implementations provided for the following modules:
Bytes referenced from
/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxa(Pcre)
Regards,
F.
[Cocci] while compiling coccci 1.0.0-rc22
There is exactly the same problem with 1.0.0-rc21. So the coccinelle opam package just got broken recently.
The only change I could see is that the package pcre-ocaml was renamed to pcre.
I will dig a little ...
Quoted 31 lines · Francois Berenger
Hi,
Anyone got this?
/home/berenger/.opam/4.01.0/bin/ocamlopt.opt-unsafe -I/home/berenger/.opam/4.01.0/lib/menhirLib-I/home/berenger/.opam/4.01.0/lib/ocaml-I/home/berenger/.opam/4.01.0/lib/pcre-I/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml/-I commons -I commons/ocamlextra -I ctl -I engine -I extra -I globals -I ocaml -Iparsing_c-Iparsing_cocci-I popl09 -I python -cclib -lpycaml_stubs
-cclib -lpython2.7 -ccopt -lpcre -cclib -lpcre_stubs -o spatch.opt str.cmxa unix.cmxa bigarray.cmxa nums.cmxa/home/berenger/.opam/4.01.0/lib/ocaml/dynlink.cmxa/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml//pycaml.cmxa/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxacommons/commons.cmxa globals/globals.cmxa ctl/ctl.cmxa parsing_cocci/cocci_parser.cmxa parsing_c/parsing_c.cmxa engine/cocciengine.cmxa popl09/popl.cmxa extra/extra.cmxa python/coccipython.cmxa ocaml/cocciocaml.cmxa flag_cocci.cmx cocci.cmx testing.cmx test.cmx main.cmx
File "_none_", line 1:
Error: No implementations provided for the following modules:
Bytes referenced from
/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxa(Pcre)Regards,
F.
_______________________________________________
Cocci mailing list
Cocci at systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Signature · 2 lines
Regards, Francois.
[Cocci] while compiling coccci 1.0.0-rc22
Quoted 5 lines · Francois Berenger
There is exactly the same problem with 1.0.0-rc21. So the coccinelle opam package just got broken recently.
The only change I could see is that the package pcre-ocaml was renamed to pcre.
OK, on my computer, pcre has to be downgraded from 7.1.3 to 7.1.1 in order for cocci rc21 and rc22 to compile.
I think I will send in the opam repository a request to fix dependency version of pcre to 7.1.1 for coccinelle.
If anybody doesn't agree with that, please shout now. :)
Quoted 35 lines
I will dig a little ...
Quoted 31 lines · Francois Berenger
Hi,
Anyone got this?
/home/berenger/.opam/4.01.0/bin/ocamlopt.opt-unsafe -I/home/berenger/.opam/4.01.0/lib/menhirLib-I/home/berenger/.opam/4.01.0/lib/ocaml-I/home/berenger/.opam/4.01.0/lib/pcre-I/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml/-I commons -I commons/ocamlextra -I ctl -I engine -I extra -I globals -I ocaml -Iparsing_c-Iparsing_cocci-I popl09 -I python -cclib -lpycaml_stubs
-cclib -lpython2.7 -ccopt -lpcre -cclib -lpcre_stubs -o spatch.opt str.cmxa unix.cmxa bigarray.cmxa nums.cmxa/home/berenger/.opam/4.01.0/lib/ocaml/dynlink.cmxa/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml//pycaml.cmxa/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxacommons/commons.cmxa globals/globals.cmxa ctl/ctl.cmxa parsing_cocci/cocci_parser.cmxa parsing_c/parsing_c.cmxa engine/cocciengine.cmxa popl09/popl.cmxa extra/extra.cmxa python/coccipython.cmxa ocaml/cocciocaml.cmxa flag_cocci.cmx cocci.cmx testing.cmx test.cmx main.cmx
File "_none_", line 1:
Error: No implementations provided for the following modules:
Bytes referenced from
/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxa(Pcre)Regards,
F.
_______________________________________________
Cocci mailing list
Cocci at systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Signature · 2 lines
Regards, Francois.
[Cocci] while compiling coccci 1.0.0-rc22
Quoted 7 lines · Francois Berenger
Quoted 5 lines · Francois Berenger
There is exactly the same problem with 1.0.0-rc21. So the coccinelle opam package just got broken recently.
The only change I could see is that the package pcre-ocaml was renamed to pcre.
Quoted 7 lines
OK, on my computer, pcre has to be downgraded from 7.1.3 to 7.1.1 in order for cocci rc21 and rc22 to compile.
I think I will send in the opam repository a request to fix dependency version of pcre to 7.1.1 for coccinelle.
If anybody doesn't agree with that, please shout now. :)
Since no one shouted yet, plus the fix I propose allows to compile cocci with ocaml 4.00.0 and 4.01.0 (instead of just with ocaml 4.02.0, the current status with OPAM).
I will send my pull request shortly into the OPAM repository.
Quoted 36 lines
Quoted 35 lines
I will dig a little ...
Quoted 31 lines · Francois Berenger
Hi,
Anyone got this?
/home/berenger/.opam/4.01.0/bin/ocamlopt.opt-unsafe -I/home/berenger/.opam/4.01.0/lib/menhirLib-I/home/berenger/.opam/4.01.0/lib/ocaml-I/home/berenger/.opam/4.01.0/lib/pcre-I/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml/-I commons -I commons/ocamlextra -I ctl -I engine -I extra -I globals -I ocaml -Iparsing_c-Iparsing_cocci-I popl09 -I python -cclib -lpycaml_stubs
-cclib -lpython2.7 -ccopt -lpcre -cclib -lpcre_stubs -o spatch.opt str.cmxa unix.cmxa bigarray.cmxa nums.cmxa/home/berenger/.opam/4.01.0/lib/ocaml/dynlink.cmxa/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml//pycaml.cmxa/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxacommons/commons.cmxa globals/globals.cmxa ctl/ctl.cmxa parsing_cocci/cocci_parser.cmxa parsing_c/parsing_c.cmxa engine/cocciengine.cmxa popl09/popl.cmxa extra/extra.cmxa python/coccipython.cmxa ocaml/cocciocaml.cmxa flag_cocci.cmx cocci.cmx testing.cmx test.cmx main.cmx
File "_none_", line 1:
Error: No implementations provided for the following modules:
Bytes referenced from
/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxa(Pcre)Regards,
F.
_______________________________________________
Cocci mailing list
Cocci at systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Signature · 2 lines
Regards, Francois.
[Cocci] while compiling coccci 1.0.0-rc22
In reply to Francois BerengerQuoted 14 lines · Francois Berenger
Hi,
Anyone got this?
/home/berenger/.opam/4.01.0/bin/ocamlopt.opt-unsafe -I/home/berenger/.opam/4.01.0/lib/menhirLib-I/home/berenger/.opam/4.01.0/lib/ocaml-I/home/berenger/.opam/4.01.0/lib/pcre-I/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml/-I commons -I commons/ocamlextra -I ctl -I engine -I extra -I globals -I ocaml -Iparsing_c(quoted diff) +0
-2-I parsing_cocci -I popl09 -I python -cclib -lpycaml_stubs -cclib -lpython2.7 -ccopt -lpcre -cclib -lpcre_stubs -o spatch.opt str.cmxa unix.cmxabigarray.cmxa nums.cmxa
/home/berenger/.opam/4.01.0/lib/ocaml/dynlink.cmxa/home/berenger/src/coccinelle-1.0.0-rc22/bundles/pycaml//pycaml.cmxa/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxacommons/commons.cmxa
Quoted 8 lines
globals/globals.cmxa ctl/ctl.cmxa parsing_cocci/cocci_parser.cmxa parsing_c/parsing_c.cmxa engine/cocciengine.cmxa popl09/popl.cmxa extra/extra.cmxa python/coccipython.cmxa ocaml/cocciocaml.cmxa flag_cocci.cmx cocci.cmx testing.cmx test.cmx main.cmx
File "_none_", line 1:
Error: No implementations provided for the following modules:
Bytes referenced from
/home/berenger/.opam/4.01.0/lib/pcre/pcre.cmxa(Pcre)
My OCaml is not so up to date...
julia
Re: [patch] CodingStyle: add some more error handling guidelines
In reply to Dan CarpenterQuoted 5 lines
Quoted 3 lines
* To which source code place should the word "location" refer to?
- jump source
- jump targetjump target.
Thanks for the clarification of your intention.
I wonder then why I got the feedback "That is a useless thing to do." from you yesterday.
I hope that we can still clarify our different opinions about specific implementation details in constructive ways.
Regards,
Markus
Re: [patch] CodingStyle: add some more error handling guidelines
Sorry. I misread your email. If the code looks like this:
foo = kmalloc(); if (!foo) goto kmalloc_failed;
The "kmalloc_failed" doesn't add any information. We can see that kmalloc failed from the context.
regards,
dan carpenter
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 7 lines
Sorry. I misread your email. If the code looks like this:
foo = kmalloc(); if (!foo) goto kmalloc_failed;The "
kmalloc_failed" doesn't add any information.
I find that this such a name approach would fit to your expectation of a source-oriented labeling of these identifiers.
Quoted 1 line
We can see that kmalloc failed from the context.
Which name pattern do you find more appropriate in such an use case?
Regards,
Markus
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 8 lines · SF Markus Elfring
Quoted 7 lines
Sorry. I misread your email. If the code looks like this:
foo = kmalloc(); if (!foo) goto kmalloc_failed;The "
kmalloc_failed" doesn't add any information.
Quoted 8 lines
I find that this such a name approach would fit to your expectation of a source-oriented labeling of these identifiers.
Quoted 1 line
We can see that kmalloc failed from the context.
Which name pattern do you find more appropriate in such an use case?
I think Dan wants the label to be descriptive about the tasks needed in the exception handling itself. This makes sense as the exception handling steps may be reused for different failures in the code.
void foo(void)
{
if (check_a())
goto do_bar;
sub_foo1();
if (checck_b())
goto do_bar;
sub_foo2();
return;do_bar:
bar(); }
Regards,
Arend
Quoted 6 lines
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 5 lines
Quoted 2 lines
Which name pattern do you find more appropriate in such an use case?
I think Dan wants the label to be descriptive about the tasks needed in the exception handling itself.
I would usually prefer also such a target-oriented labelling for the affected identifiers.
How are the chances to express an expectation in this direction unambiguously for the proposed coding style update?
Quoted 2 lines
This makes sense as the exception handling steps may be reused for different failures in the code.
I would stress a different reason from my point of view.
Regards,
Markus
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 12 lines · SF Markus Elfring
Quoted 5 lines
Quoted 2 lines
Which name pattern do you find more appropriate in such an use case?
I think Dan wants the label to be descriptive about the tasks needed in the exception handling itself.
I would usually prefer also such a target-oriented labelling for the affected identifiers.
How are the chances to express an expectation in this direction unambiguously for the proposed coding style update?
Quoted 4 lines
Quoted 2 lines
This makes sense as the exception handling steps may be reused for different failures in the code.
I would stress a different reason from my point of view.
I meant as apposed to using a goto-/source-oriented labelling. Please provide your point of view. That way the explanations given in this email exchange might be incorporated in the next round of the proposed update or at least be used as input.
Regards,
Arend
Re: [patch] CodingStyle: add some more error handling guidelines
Quoted 1 line
Please provide your point of view.
I would like to interpret the key word "goto" from the C programming language a bit more here so that a better common understanding can eventually be achieved.
Strong opinions might be floating around for the consistent naming of jump labels. My reasoning works like the following.
This key word could also be interpreted as two items "go" and "to", couldn't it?
How much does this variation stress its meaning in a specific direction?
Some software developers would like to express the reason about an unexpected event at the jump source. But I guess that this approach increases the risk for a popular story like "goto fail;", doesn't it? I would prefer not to specify "go to failure".
So I find that there are more variants possible to stress the jump target. Examples:
* Failure_exit
* out_memory_release
* unregister_item
Regards,
Markus
PATCH 1/1 lib/mpi: Deletion of unnecessary checks before the function call "mpi_free_limb_space"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sat, 15 Nov 2014 21:33:26 +0100
The mpi_free_limb_space() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- lib/mpi/mpi-pow.c | 15 +++++---------- lib/mpi/mpih-mul.c | 21 +++++++-------------- 2 files changed, 12 insertions(+), 24 deletions(-)
lib/mpi/mpi-pow.c +5 -10
@@ -308,16 +308,11 @@ leave: enomem:if (assign_rp)mpi_assign_limb_space (res, rp, size); -if (mp_marker) -mpi_free_limb_space (mp_marker); -if (bp_marker) -mpi_free_limb_space (bp_marker); -if (ep_marker) -mpi_free_limb_space (ep_marker); -if (xp_marker) -mpi_free_limb_space (xp_marker); -if (tspace) -mpi_free_limb_space (tspace); +mpi_free_limb_space (mp_marker); +mpi_free_limb_space (bp_marker); +mpi_free_limb_space (ep_marker); +mpi_free_limb_space (xp_marker); +mpi_free_limb_space (tspace);return rc; }EXPORT_SYMBOL_GPL (mpi_powm);
lib/mpi/mpih-mul.c +7 -14
@@ -339,8 +339,7 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,mpi_limb_t cy;if (!ctx->tspace || ctx->tspace_size < vsize) { -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tspace); ctx->tspace =mpi_alloc_limb_space (2 * vsize);if (!ctx->tspace)return -ENOMEM ;
@@ -354,12 +353,10 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp, usize -= vsize;if (usize >= vsize) {if (!ctx->tp || ctx->tp_size < vsize) { -if (ctx->tp) -mpi_free_limb_space (ctx->tp); +mpi_free_limb_space (ctx->tp); ctx->tp =mpi_alloc_limb_space (2 * vsize);if (!ctx->tp) { -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tspace); ctx->tspace =NULL ;return -ENOMEM ; }
@@ -407,16 +404,12 @@ void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx) {struct karatsuba_ctx *ctx2; -if (ctx->tp) -mpi_free_limb_space (ctx->tp); -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tp); +mpi_free_limb_space (ctx->tspace);for (ctx = ctx->next; ctx; ctx = ctx2) { ctx2 = ctx->next; -if (ctx->tp) -mpi_free_limb_space (ctx->tp); -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tp); +mpi_free_limb_space (ctx->tspace);kfree (ctx); } }
Signature · 1 line
2.1.3
PATCH 1/1 lib/mpi: Delete unnecessary checks before the function call "mpi_free_limb_space"
From: Markus Elfring <[email protected]>
Date: Fri, 26 Jun 2015 10:11:19 +0200
The mpi_free_limb_space() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- lib/mpi/mpi-pow.c | 15 +++++---------- lib/mpi/mpih-mul.c | 21 +++++++-------------- 2 files changed, 12 insertions(+), 24 deletions(-)
lib/mpi/mpi-pow.c +5 -10
@@ -308,16 +308,11 @@ leave: enomem:if (assign_rp)mpi_assign_limb_space (res, rp, size); -if (mp_marker) -mpi_free_limb_space (mp_marker); -if (bp_marker) -mpi_free_limb_space (bp_marker); -if (ep_marker) -mpi_free_limb_space (ep_marker); -if (xp_marker) -mpi_free_limb_space (xp_marker); -if (tspace) -mpi_free_limb_space (tspace); +mpi_free_limb_space (mp_marker); +mpi_free_limb_space (bp_marker); +mpi_free_limb_space (ep_marker); +mpi_free_limb_space (xp_marker); +mpi_free_limb_space (tspace);return rc; }EXPORT_SYMBOL_GPL (mpi_powm);
lib/mpi/mpih-mul.c +7 -14
@@ -339,8 +339,7 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp,mpi_limb_t cy;if (!ctx->tspace || ctx->tspace_size < vsize) { -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tspace); ctx->tspace =mpi_alloc_limb_space (2 * vsize);if (!ctx->tspace)return -ENOMEM ;
@@ -354,12 +353,10 @@ mpihelp_mul_karatsuba_case(mpi_ptr_t prodp, usize -= vsize;if (usize >= vsize) {if (!ctx->tp || ctx->tp_size < vsize) { -if (ctx->tp) -mpi_free_limb_space (ctx->tp); +mpi_free_limb_space (ctx->tp); ctx->tp =mpi_alloc_limb_space (2 * vsize);if (!ctx->tp) { -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tspace); ctx->tspace =NULL ;return -ENOMEM ; }
@@ -407,16 +404,12 @@ void mpihelp_release_karatsuba_ctx(struct karatsuba_ctx *ctx) {struct karatsuba_ctx *ctx2; -if (ctx->tp) -mpi_free_limb_space (ctx->tp); -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tp); +mpi_free_limb_space (ctx->tspace);for (ctx = ctx->next; ctx; ctx = ctx2) { ctx2 = ctx->next; -if (ctx->tp) -mpi_free_limb_space (ctx->tp); -if (ctx->tspace) -mpi_free_limb_space (ctx->tspace); +mpi_free_limb_space (ctx->tp); +mpi_free_limb_space (ctx->tspace);kfree (ctx); } }
Signature · 1 line
2.4.4
PATCH 1/1 kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 11:27:43 +0100
The audit_log_end() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- kernel/auditsc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/auditsc.c +1 -2
@@ -1470,8 +1470,7 @@ static void audit_log_exit(struct audit_context *context, struct task_struct *ts/* Send end of event record to help user space know we are finished */ ab =audit_log_start (context,GFP_KERNEL ,AUDIT_EOE ); -if (ab) -audit_log_end (ab); +audit_log_end (ab);if (call_panic)audit_panic ("error converting sid to string" ); }
Signature · 1 line
2.1.3
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Please don't send these to trivial, because they can introduce bugs.
The make the code less clear and they are a layering violation. If the other maintainers want to take them that's fine, but don't send it to trivial.
regards,
dan carpenter
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Quoted 1 line · Dan Carpenter
Please don't send these to trivial, because they can introduce bugs.
An example of a bug introduced is here:
https://lkml.org/lkml/2014/11/3/505
regards,
dan carpenter
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Quoted 3 lines
An example of a bug introduced is here:
It seems that we try to clarify a different interpretation of "bugs", don't we?
It is an usual software development challenge to decide on the best source code places where to put input parameter validation (and when it can be omitted), isn't it?
Regards,
Markus
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Quoted 6 lines · SF Markus Elfring
Quoted 3 lines
An example of a bug introduced is here:
It seems that we try to clarify a different interpretation of "bugs", don't we?
You removed the statement from "if (foo) kfree_fsm(foo);" so now it prints a warning.
drivers/s390/net/fsm.c
71 void
72 kfree_fsm(fsm_instance *this)
73 {
74 if (this) {
75 if (this->f) {
76 kfree(this->f->jumpmatrix);
77 kfree(this->f);
78 }
79 kfree(this);
80 } else
81 printk(KERN_WARNING
82 "fsm: kfree_fsm called with NULL argument\n");
83 }Quoted 2 lines
It is an usual software development challenge to decide on the best source code places where to put input parameter validation (and when it can be omitted), isn't it?
No, it's not. You should just try to write the most readable software you can instead of removing if statements because you can.
But that's not my point. My point is that these patches are not always welcome so we should not merge them through the trivial tree.
regards,
dan carpenter
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Quoted 4 lines
You removed the statement from "if (foo)
kfree_fsm(foo);" so now it prints a warning.
drivers/s390/net/fsm.c
Would it be better to continue the clarification of affected implementation details under the discussion topic "s390/net: Deletion of unnecessary checks before two function calls"?
Quoted 5 lines
Quoted 2 lines
It is an usual software development challenge to decide on the best source code places where to put input parameter validation (and when it can be omitted), isn't it?
No, it's not. You should just try to write the most readable software you can instead of removing if statements because you can.
Additional safety checks have also got an effect on source code readability, haven't they?
Regards,
Markus
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Quoted 8 lines · SF Markus Elfring
Quoted 4 lines
You removed the statement from "if (foo)
kfree_fsm(foo);" so now it prints a warning.
drivers/s390/net/fsm.cWould it be better to continue the clarification of affected implementation details under the discussion topic "s390/net: Deletion of unnecessary checks before two function calls"?
What do you want me to clarify? Do you still not see the bug?
regards,
dan carpenter
Re: s390/net: Deletion of unnecessary checks before two function calls
Quoted 1 line
What do you want me to clarify? Do you still not see the bug?
Would you like to point out that you notice the warning message "fsm: kfree_fsm called with NULL argument" after my update suggestion?
How do you think about to share a bit more information about the corresponding function call graph from your test system?
Regards,
Markus
Re: [Cocci] [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
In reply to SF Markus ElfringQuoted 4 lines
Quoted 2 lines
No, it's not. You should just try to write the most readable software you can instead of removing if statements because you can.
Additional safety checks have also got an effect on source code readability, haven't they?
Normally, tests only hurt readability if they cannot be false or cannot be true. Making a choice apparent when there really is a choice would seem to aid understanding. Program analysis tools can also potentially exploit this information, which you are so systmatically removing.
julia
Re: kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Quoted 3 lines
Normally, tests only hurt readability if they cannot be false or cannot be true. Making a choice apparent when there really is a choice would seem to aid understanding.
I agree also to such facts.
Quoted 1 line
Program analysis tools can also potentially exploit this information,
The published semantic patch scripts correspond to this desire.
Quoted 1 line
which you are so systmatically removing.
I try to delete redundant checks in various function implementations as much as possible.
Regards,
Markus
Re: kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
Quoted 4 lines · SF Markus Elfring
Quoted 1 line
Program analysis tools can also potentially exploit this information,
The published semantic patch scripts correspond to this desire.
Sorry for that.
I have deleted the Smatch check for this so it no longer warns about:
if (foo) kfree(foo);
regards,
dan carpenter
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end"
In reply to SF Markus ElfringQuoted 5 lines · SF Markus Elfring
kernel/auditsc.c +0
-0
kernel/auditsc.c static void audit_log_exit(struct audit_context *context, struct task_struct *ts · line 1476
Quoted 9 lines
kernel/auditsc.c +1
-2@@ -1470,8 +1470,7 @@ static void audit_log_exit(struct audit_context *context, struct task_struct *ts/* Send end of event record to help user space know we are finished */ ab =audit_log_start (context,GFP_KERNEL ,AUDIT_EOE ); -if (ab) -audit_log_end (ab); +audit_log_end (ab);if (call_panic)audit_panic ("error converting sid to string" ); }
I should have tried to explain this in my earlier message...
The original code is very clear, the new code works exactly the same but it's not clear if the author forgot about handling errors from audit_log_start(). So now someone will come along later and add:
if (!ab) return;
We get a lot of mindless "add error handling" patches like that. Even if no one adds that patch who ever is reading the code will think that the error handling is missing by mistake and have to read the git log to determine the original intention.
Instead of hiding the readable code in the git log, let's just leave it in the source file.
regards,
dan carpenter
Re: [PATCH 1/1] kernel-audit: Deletion of an unnecessary check before the function call "audit_log_end" (or improve error handling?)
Quoted 3 lines
The original code is very clear, the new code works exactly the same but it's not clear if the author forgot about handling errors from
audit_log_start().
We have got different expectations on source code clarity here.
Quoted 5 lines
So now someone will come along later and add:
if (!ab) return;We get a lot of mindless "add error handling" patches like that.
This is an interesting background information.
Do you eventually prefer to improve the affected error detection and corresponding exception handling?
Will a condition check become absolutely necessary there?
Regards,
Markus
PATCH 1/1 kprobes: Deletion of an unnecessary check before the function call "module_put"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 12:20:31 +0100
The module_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- kernel/kprobes.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/kprobes.c +1 -2
@@ -1527,8 +1527,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex); -if (probed_mod) -module_put (probed_mod); +module_put (probed_mod);return ret; }
Signature · 1 line
2.1.3
Re: [Cocci] [PATCH 1/1] kprobes: Deletion of an unnecessary check before the function call "module_put"
Quoted 18 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 12:20:31 +0100The
module_put()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- kernel/kprobes.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)kernel/kprobes.c +0
-0
kernel/kprobes.c int register_kprobe(struct kprobe *p) · line 1530
Quoted 6 lines
kernel/kprobes.c +1
-2@@ -1527,8 +1527,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex); -if (probed_mod) -module_put (probed_mod); +module_put (probed_mod);
There is an out label, so please check whether the labels could not be better positioned to avoid calling module_put when it is not needed.
julia
Quoted 12 lines
kernel/kprobes.c +0
-1return ret; } --2.1.3
_______________________________________________
Cocci mailing list
Cocci at systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [PATCH 1/1] kprobes: Deletion of an unnecessary check before the function call "module_put"
Quoted 8 lines
Quoted 8 lines
kernel/kprobes.c +0
-0@@ -1527,8 +1527,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex);
Quoted 6 lines
kernel/kprobes.c int register_kprobe(struct kprobe *p) · line 1530
Quoted 3 lines
kernel/kprobes.c +1
-2-if (probed_mod) -module_put (probed_mod); +module_put (probed_mod);There is an out label, so please check whether the labels could not be better positioned to avoid calling
module_putwhen it is not needed.
I do not see refactoring opportunities around jump labels in this use case for the implementation of the register_kprobe() function so far because the mutex_unlock() function must be called.
Would you like to suggest any other source code fine-tuning?
Regards,
Markus
Re: [Cocci] [PATCH 1/1] kprobes: Deletion of an unnecessary check before the function call "module_put"
Quoted 15 lines · SF Markus Elfring
Quoted 8 lines
Quoted 8 lines
kernel/kprobes.c +0
-0@@ -1527,8 +1527,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex);Quoted 6 lines
kernel/kprobes.c int register_kprobe(struct kprobe *p) · line 1530
Quoted 3 lines
kernel/kprobes.c +1
-2-if (probed_mod) -module_put (probed_mod); +module_put (probed_mod);There is an out label, so please check whether the labels could not be better positioned to avoid calling
module_putwhen it is not needed.
Quoted 4 lines
I do not see refactoring opportunities around jump labels in this use case for the implementation of the
register_kprobe()function so far because themutex_unlock()function must be called.
Would you like to suggest any other source code fine-tuning?
OK. I don't think that removing the if is a good choice in this case. The code ret = check_kprobe_address_safe(p, &probed_mod); is unusual, in that it can fail to do anything in two ways. One is by setting ret, on detecting an error, and the other is by returning 0 but still putting a NULL value in probed_mod when there is nothing to do. Thus, in the successful execution of the rest of the function, a probed module might or might not exist. The if around the module_put is helpful to the reader to understand that this possibility exists.
julia
Re: [Cocci] [PATCH 1/1] kprobes: Deletion of an unnecessary check before the function call "module_put"
Quoted 2 lines
The if around the
module_putis helpful to the reader to understand that this possibility exists.
I have got a different opinion. I would still prefer a small code clean-up there.
Regards,
Markus
Re: [PATCH 1/1] kprobes: Deletion of an unnecessary check before the function call "module_put"
In reply to SF Markus ElfringQuoted 18 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 12:20:31 +0100The
module_put()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- kernel/kprobes.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)kernel/kprobes.c +0
-0
kernel/kprobes.c int register_kprobe(struct kprobe *p) · line 1530
Quoted 6 lines
kernel/kprobes.c +1
-2@@ -1527,8 +1527,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex); -if (probed_mod) -module_put (probed_mod); +module_put (probed_mod);
This is OK, but I you request a comment line over there so that code reader can understand it is safe to pass a NULL pointer to module_put().
# and of course don't touch jump label around that :)
Thank you,
Quoted 4 lines
kernel/kprobes.c +0
-0return ret; }
Signature · 4 lines
Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: [email protected]
Re: [PATCH 1/1] kprobes: Deletion of an unnecessary check before the function call "module_put"
Quoted 7 lines
Quoted 7 lines
index 3995f54..f1e7d45 100644
kernel/kprobes.c +0
-0@@ -1527,8 +1527,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex);
Quoted 7 lines
kernel/kprobes.c int register_kprobe(struct kprobe *p) · line 1530
Quoted 3 lines
kernel/kprobes.c +1
-2-if (probed_mod) -module_put (probed_mod); +module_put (probed_mod);This is OK, but I you request a comment line over there so that code reader can understand it is safe to pass a NULL pointer to
module_put().
Do you want that I replace the shown null pointer check by a short comment which repeats an expectation for the affected function call?
Regards,
Markus
Re: [PATCH 1/1] kprobes: Deletion of an unnecessary check before the function call "module_put"
Quoted 15 lines · SF Markus Elfring
Quoted 7 lines
Quoted 7 lines
index 3995f54..f1e7d45 100644
kernel/kprobes.c +0
-0@@ -1527,8 +1527,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex);Quoted 7 lines
kernel/kprobes.c int register_kprobe(struct kprobe *p) · line 1530
Quoted 3 lines
kernel/kprobes.c +1
-2-if (probed_mod) -module_put (probed_mod); +module_put (probed_mod);This is OK, but I you request a comment line over there so that code reader can understand it is safe to pass a NULL pointer to
module_put().
Quoted 2 lines
Do you want that I replace the shown null pointer check by a short comment which repeats an expectation for the affected function call?
No, not "want". IMHO, if try_module_get(mod) is done only when mod!=NULL, we shouldn't call module_put(mod) when mod=NULL (even if it is possible), because those get/put method must be used as a pair, for the better understandings.
Thank you,
Signature · 4 lines
Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: [email protected]
PATCH 1/1 kprobes: Delete an unnecessary check before the function call "module_put"
From: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 10:00:26 +0200
The module_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- kernel/kprobes.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
kernel/kprobes.c +1 -4
@@ -1531,10 +1531,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex); - -if (probed_mod) -module_put (probed_mod); - +module_put (probed_mod);return ret; }EXPORT_SYMBOL_GPL (register_kprobe);
Signature · 1 line
2.4.5
Re: [PATCH] kprobes: Delete an unnecessary check before the function call "module_put"
Quoted 8 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sat, 4 Jul 2015 10:00:26 +0200The
module_put()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
OK, looks good to me.
Quoted 22 lines
Signed-off-by Markus Elfring <[email protected]>--- kernel/kprobes.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)kernel/kprobes.c +1
-4@@ -1531,10 +1531,7 @@ int register_kprobe(struct kprobe *p) out:mutex_unlock (&kprobe_mutex); - -if (probed_mod) -module_put (probed_mod); - +module_put (probed_mod);return ret; }EXPORT_SYMBOL_GPL (register_kprobe);
Signature · 5 lines
Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: [email protected]
PATCH 1/1 kernel-power: Deletion of an unnecessary check before the function call "vfree"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 14:18:28 +0100
The vfree() function performs also input parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- kernel/power/swap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/power/swap.c +1 -1
@@ -1374,7 +1374,7 @@ out_clean:kthread_stop (data[thr].thr);vfree (data); } -if (page)vfree (page); +vfree (page);return ret; }
Signature · 1 line
2.1.3
Rafael J. Wysocki
AppliedRe: [PATCH 1/1] kernel-power: Deletion of an unnecessary check before the function call "vfree"
Quoted 9 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 14:18:28 +0100The
vfree()function performs also input parameter validation. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>
Queued up for 3.19-rc1, thanks!
Quoted 18 lines
--- kernel/power/swap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)kernel/power/swap.c +1
-1@@ -1374,7 +1374,7 @@ out_clean:kthread_stop (data[thr].thr);vfree (data); } -if (page)vfree (page); +vfree (page);return ret; }
Signature · 2 lines
I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
PATCH 1/1 kernel-trace: Deletion of an unnecessary check before the function call "iput"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 14:46:28 +0100
The iput() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- kernel/trace/trace_uprobe.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/trace/trace_uprobe.c +1 -2
@@ -552,8 +552,7 @@ error:return ret; fail_address_parse: -if (inode) -iput (inode); +iput (inode);pr_info ("Failed to parse address or file.\n" );
Signature · 1 line
2.1.3
Re: [PATCH 1/1] kernel-trace: Deletion of an unnecessary check before the function call "iput"
Quoted 18 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 14:46:28 +0100The
iput()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- kernel/trace/trace_uprobe.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)kernel/trace/trace_uprobe.c +0
-0
kernel/trace/trace_uprobe.c error: · line 555
Quoted 6 lines
kernel/trace/trace_uprobe.c +1
-2@@ -552,8 +552,7 @@ error:return ret; fail_address_parse: -if (inode) -iput (inode); +iput (inode);
There are jumps to fail_address_parse where the value of inode can only be NULL.
julia
Quoted 12 lines
kernel/trace/trace_uprobe.c +0
-1pr_info ("Failed to parse address or file.\n" ); --2.1.3
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
v2 cover kernel-trace: Fixes around the jump label "fail_address_parse"
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 19:56:15 +0100
Another update suggestion was taken into account after a patch was applied from static source code analysis.
Markus Elfring (2):
kernel-trace: Deletion of an unnecessary check before the function
call "iput"
kernel-trace: Less calls for iput() in create_trace_uprobe() after
error detection
kernel/trace/trace_uprobe.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
Signature · 1 line
2.1.3
PATCH v2 1/2 kernel-trace: Deletion of an unnecessary check before the function call "iput"
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 14:46:28 +0100
The iput() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- kernel/trace/trace_uprobe.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/trace/trace_uprobe.c +1 -2
@@ -552,8 +552,7 @@ error:return ret; fail_address_parse: -if (inode) -iput (inode); +iput (inode);pr_info ("Failed to parse address or file.\n" );
Signature · 1 line
2.1.3
PATCH v2 2/2 kernel-trace: Less calls for iput() in create_trace_uprobe() after error detection
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 19:49:39 +0100
The iput() function was called in three cases by the create_trace_uprobe() function during error handling even if the passed variable contained still a null pointer. This implementation detail could be improved by the introduction of another jump label.
--- kernel/trace/trace_uprobe.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
kernel/trace/trace_uprobe.c +9 -3
@@ -434,19 +434,24 @@ static int create_trace_uprobe(int argc, char **argv) arg =strchr (argv[1 ],':' );if (!arg) { ret = -EINVAL ; - goto fail_address_parse; + goto fail_address_parse2; } *arg++ ='\0' ; filename = argv[1 ]; ret =kern_path (filename,LOOKUP_FOLLOW , &path);if (ret) - goto fail_address_parse; + goto fail_address_parse2; inode =igrab (path.dentry->d_inode);path_put (&path); -if (!inode || !S_ISREG (inode->i_mode)) { +if (!inode) { + ret = -EINVAL ; + goto fail_address_parse2; + } + +if (!S_ISREG (inode->i_mode)) { ret = -EINVAL ; goto fail_address_parse; }
@@ -554,6 +559,7 @@ error: fail_address_parse:iput (inode); +fail_address_parse2:pr_info ("Failed to parse address or file.\n" );return ret;
Signature · 1 line
2.1.3
Steven Rostedt
maintainerRe: [PATCH v2 2/2] kernel-trace: Less calls for iput() in create_trace_uprobe() after error detection
Quoted 7 lines · On Sun, 16 Nov 2014 20:22:22 +0100 SF Markus Elfring…
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 19:49:39 +0100The
iput()function was called in three cases by thecreate_trace_uprobe()function during error handling even if the passed variable contained still a null pointer. This implementation detail could be improved by the introduction of another jump label.
The first patch is fine, and the only reason is to save the few bytes that the branch check might take. It's in a path that is unlikely to be hit so it is not a performance issue at all.
This patch is useless. I rather not apply any patch than to create another jump that skips over the freeing of iput() just because we know inode is null. That's why we had the if (inode) in the first place.
So Nack on this patch and I'll contemplate applying the first one. I probably will as it seems rather harmless.
Thanks,
-- Steve
Quoted 47 lines
Suggested-by Julia Lawall <[email protected]>Signed-off-by Markus Elfring <[email protected]>--- kernel/trace/trace_uprobe.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)kernel/trace/trace_uprobe.c +9
-3@@ -434,19 +434,24 @@ static int create_trace_uprobe(int argc, char **argv) arg =strchr (argv[1 ],':' );if (!arg) { ret = -EINVAL ; - goto fail_address_parse; + goto fail_address_parse2; } *arg++ ='\0' ; filename = argv[1 ]; ret =kern_path (filename,LOOKUP_FOLLOW , &path);if (ret) - goto fail_address_parse; + goto fail_address_parse2; inode =igrab (path.dentry->d_inode);path_put (&path); -if (!inode || !S_ISREG (inode->i_mode)) { +if (!inode) { + ret = -EINVAL ; + goto fail_address_parse2; + } + +if (!S_ISREG (inode->i_mode)) { ret = -EINVAL ; goto fail_address_parse; }@@ -554,6 +559,7 @@ error: fail_address_parse:iput (inode); +fail_address_parse2:pr_info ("Failed to parse address or file.\n" );return ret;
Re: [PATCH v2 2/2] kernel-trace: Less calls for iput() in create_trace_uprobe() after error detection
Quoted 15 lines · Steven Rostedt
Quoted 7 lines · On Sun, 16 Nov 2014 20:22:22 +0100 SF Markus Elfring…
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 19:49:39 +0100The
iput()function was called in three cases by thecreate_trace_uprobe()function during error handling even if the passed variable contained still a null pointer. This implementation detail could be improved by the introduction of another jump label.The first patch is fine, and the only reason is to save the few bytes that the branch check might take. It's in a path that is unlikely to be hit so it is not a performance issue at all.
Quoted 6 lines
This patch is useless. I rather not apply any patch than to create another jump that skips over the freeing of
iput()just because we know inode is null. That's why we had the if (inode) in the first place.So Nack on this patch and I'll contemplate applying the first one. I probably will as it seems rather harmless.
I wuold have thought that one could have just returned, like in the cases above... But maybe the printed message is useful.
julia
Steven Rostedt
maintainerRe: [PATCH v2 2/2] kernel-trace: Less calls for iput() in create_trace_uprobe() after error detection
Quoted 2 lines · On Sun, 16 Nov 2014 20:34:59 +0100 (CET) Julia Lawall <[email protected]>…
I wuold have thought that one could have just returned, like in the cases above... But maybe the printed message is useful.
Yes, it lets us know that the format string failed to parse.
-- Steve
PATCH 1/1 fs-jbd: Deletion of an unnecessary check before the function call "iput"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 23:23:19 +0100
The iput() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- fs/jbd/journal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/jbd/journal.c +1 -2
@@ -1373,8 +1373,7 @@ int journal_destroy(journal_t *journal) }mutex_unlock (&journal->j_checkpoint_mutex); -if (journal->j_inode) -iput (journal->j_inode); +iput (journal->j_inode);if (journal->j_revoke)journal_destroy_revoke (journal);kfree (journal->j_wbuf);
Signature · 1 line
2.1.3
Jan Kara
maintainerRe: [PATCH 1/1] fs-jbd: Deletion of an unnecessary check before the function call "iput"
Quoted 6 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Sun, 16 Nov 2014 23:23:19 +0100The
iput()function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
Quoted 6 lines
This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>--- fs/jbd/journal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Thanks. Merged into my tree.
Honza
Quoted 19 lines
fs/jbd/journal.c +1
-2@@ -1373,8 +1373,7 @@ int journal_destroy(journal_t *journal) }mutex_unlock (&journal->j_checkpoint_mutex); -if (journal->j_inode) -iput (journal->j_inode); +iput (journal->j_inode);if (journal->j_revoke)journal_destroy_revoke (journal);kfree (journal->j_wbuf);Signature · 1 line
2.1.3
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
PATCH 1/1 ALSA: hda: Deletion of unnecessary checks before two function calls
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Mon, 17 Nov 2014 10:44:33 +0100
The functions kfree() and release_firmware() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- sound/pci/hda/hda_codec.c | 3 +-- sound/pci/hda/hda_intel.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
sound/pci/hda/hda_codec.c +1 -2
@@ -827,8 +827,7 @@ static void snd_hda_bus_free(struct hda_bus *bus)WARN_ON (!list_empty (&bus->codec_list));if (bus->workq)flush_workqueue (bus->workq); -if (bus->unsol) -kfree (bus->unsol); +kfree (bus->unsol);if (bus->ops.private_free) bus->ops.private_free (bus);if (bus->workq)
sound/pci/hda/hda_intel.c +1 -2
@@ -1129,8 +1129,7 @@ static int azx_free(struct azx *chip)pci_disable_device (chip->pci);kfree (chip->azx_dev);#ifdef CONFIG_SND_HDA_PATCH_LOADER -if (chip->fw) -release_firmware (chip->fw); +release_firmware (chip->fw);#endif if (chip->driver_caps &AZX_DCAPS_I915_POWERWELL ) {hda_display_power (false);
Signature · 1 line
2.1.3
Takashi Iwai
AppliedRe: [PATCH 1/1] ALSA: hda: Deletion of unnecessary checks before two function calls
At Mon, 17 Nov 2014 11:07:04 +0100,
Quoted 11 lines · SF Markus Elfring
From: Markus Elfring <[email protected]>
Date: Mon, 17 Nov 2014 10:44:33 +0100The functions
kfree()andrelease_firmware()test whether their argument is NULL and then return immediately. Thus the test around the call is not needed.This issue was detected by using the Coccinelle software.
Signed-off-by Markus Elfring <[email protected]>
Applied, thanks.
Takashi
Quoted 37 lines
--- sound/pci/hda/hda_codec.c | 3 +-- sound/pci/hda/hda_intel.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)sound/pci/hda/hda_codec.c +1
-2@@ -827,8 +827,7 @@ static void snd_hda_bus_free(struct hda_bus *bus)WARN_ON (!list_empty (&bus->codec_list));if (bus->workq)flush_workqueue (bus->workq); -if (bus->unsol) -kfree (bus->unsol); +kfree (bus->unsol);if (bus->ops.private_free) bus->ops.private_free (bus);if (bus->workq)sound/pci/hda/hda_intel.c +1
-2@@ -1129,8 +1129,7 @@ static int azx_free(struct azx *chip)pci_disable_device (chip->pci);kfree (chip->azx_dev);#ifdef CONFIG_SND_HDA_PATCH_LOADER -if (chip->fw) -release_firmware (chip->fw); +release_firmware (chip->fw);#endif if (chip->driver_caps &AZX_DCAPS_I915_POWERWELL ) {hda_display_power (false);Signature · 1 line
2.1.3
PATCH 1/1 ALSA: ice17xx: Deletion of unnecessary checks before the function call "snd_ac97_resume"
In reply to SF Markus ElfringFrom: Markus Elfring <[email protected]>
Date: Mon, 17 Nov 2014 11:28:02 +0100
The snd_ac97_resume() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
--- sound/pci/ice1712/ice1712.c | 3 +-- sound/pci/ice1712/ice1724.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
sound/pci/ice1712/ice1712.c +1 -2
@@ -2905,8 +2905,7 @@ static int snd_ice1712_resume(struct device *dev)outw (ice->pm_saved_spdif_ctrl,ICEMT (ice,ROUTE_SPDOUT ));outw (ice->pm_saved_route,ICEMT (ice,ROUTE_PSDOUT03 )); -if (ice->ac97) -snd_ac97_resume (ice->ac97); +snd_ac97_resume (ice->ac97);snd_power_change_state (card,SNDRV_CTL_POWER_D0 );return 0 ;
sound/pci/ice1712/ice1724.c +1 -2
@@ -2884,8 +2884,7 @@ static int snd_vt1724_resume(struct device *dev)outb (ice->pm_saved_spdif_cfg,ICEREG1724 (ice,SPDIF_CFG ));outl (ice->pm_saved_route,ICEMT1724 (ice,ROUTE_PLAYBACK )); -if (ice->ac97) -snd_ac97_resume (ice->ac97); +snd_ac97_resume (ice->ac97);snd_power_change_state (card,SNDRV_CTL_POWER_D0 );return 0 ;
Signature · 1 line
2.1.3