diff options
author | Roman Pen <roman.penyaev@profitbricks.com> | 2016-08-11 19:27:09 +0200 |
---|---|---|
committer | Tejun Heo <tj@kernel.org> | 2016-08-11 13:52:23 -0400 |
commit | a67823c1ed1092160da94c31e6da5aeb35dca81c (patch) | |
tree | 7c0a2544991fddf233fc05158b61d2d9bd2927b2 /drivers/reset | |
parent | 33e465ce7cb30b71c113a26f36d293b545a28e12 (diff) | |
download | linux-a67823c1ed1092160da94c31e6da5aeb35dca81c.tar.gz linux-a67823c1ed1092160da94c31e6da5aeb35dca81c.tar.bz2 linux-a67823c1ed1092160da94c31e6da5aeb35dca81c.zip |
percpu-refcount: init ->confirm_switch member properly
This patch targets two things which are related to ->confirm_switch:
1. Init ->confirm_switch pointer with NULL on percpu_ref_init() or
kernel frightfully complains with WARN_ON_ONCE(ref->confirm_switch)
at __percpu_ref_switch_to_atomic if memory chunk was not properly
zeroed.
2. Warn if RCU callback is still in progress on percpu_ref_exit().
The race still exists, because percpu_ref_call_confirm_rcu()
drops ->confirm_switch to NULL early, but that is only a warning
and still the caller is responsible that ref is no longer in
active use. Hopefully that can help to catch incorrect usage
of percpu-refcount.
Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'drivers/reset')
0 files changed, 0 insertions, 0 deletions