On Tue, Jun 06, 2017 at 12:21:25AM +0900, Taehee Yoo wrote: > Some functions are called by nf_hook() and these > functions hold rcu_read_lock() But nf_hook() already holds > rcu_read_lock() therefore callee's rcu_read_lock() are useless. > Below messages are calltrace. Another comestic change, regarding commit log. Instead of this large commit log, with all these call traces, I would like to see a more comprehensive explanation per file, eg. [...] > 16. destroy_conntrack > -nf_ct_destroy > --nf_conntrack_destroy destroy_destroy() is called from rcu protected callback function, so rcu read side lock is already guaranteed. [...] > 17. __ctnetlink_glue_build Another example: Called from packet path, netfilter hooks run under rcu read lock side, so all packet path code is under rcu read side lock. If possible... No problem if you're non-native English speaker, most of us are not, so some hints to understand why rcu_read_lock() is not required in natural languages seems like a good fit for the git repository IMO. Don't get me wrong, the calltraces are fine for review, but I would like we don't land such a loooong commit message in the netfilter tree. Thanks! -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
