openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity

percpu_ref: Update doc to dissuade users from depending on internal RCU grace periods 

percpu_ref internally uses sched-RCU to implement the percpu -> atomic
mode switching and the documentation suggested that this could be
depended upon.  This doesn't seem like a good idea.

* percpu_ref uses sched-RCU which has different grace periods regular
  RCU.  Users may combine percpu_ref with regular RCU usage and
  incorrectly believe that regular RCU grace periods are performed by
  percpu_ref.  This can lead to, for example, use-after-free due to
  premature freeing.

* percpu_ref has a grace period when switching from percpu to atomic
  mode.  It doesn't have one between the last put and release.  This
  distinction is subtle and can lead to surprising bugs.

* percpu_ref allows starting in and switching to atomic mode manually
  for debugging and other purposes.  This means that there may not be
  any grace periods from kill to release.

This patch makes it clear that the grace periods are percpu_ref's
internal implementation detail and can't be depended upon by the
users.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
Tejun Heo 2018-03-14 12:45:12 -07:00
parent f52ba1fef7
commit b3a5d11199
2 changed files with 14 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
include/linux/percpu-refcount.h
View File

@ -30,10 +30,14 @@
* calls io_destroy() or the process exits. * calls io_destroy() or the process exits.
* *
* In the aio code, kill_ioctx() is called when we wish to destroy a kioctx; it * In the aio code, kill_ioctx() is called when we wish to destroy a kioctx; it
* calls percpu_ref_kill(), then hlist_del_rcu() and synchronize_rcu() to remove * removes the kioctx from the proccess's table of kioctxs and kills percpu_ref.
* the kioctx from the proccess's list of kioctxs - after that, there can't be * After that, there can't be any new users of the kioctx (from lookup_ioctx())
* any new users of the kioctx (from lookup_ioctx()) and it's then safe to drop * and it's then safe to drop the initial ref with percpu_ref_put().
* the initial ref with percpu_ref_put(). *
* Note that the free path, free_ioctx(), needs to go through explicit call_rcu()
* to synchronize with RCU protected lookup_ioctx(). percpu_ref operations don't
* imply RCU grace periods of any kind and if a user wants to combine percpu_ref
* with RCU protection, it must be done explicitly.
* *
* Code that does a two stage shutdown like this often needs some kind of * Code that does a two stage shutdown like this often needs some kind of
* explicit synchronization to ensure the initial refcount can only be dropped * explicit synchronization to ensure the initial refcount can only be dropped
@ -113,8 +117,10 @@ void percpu_ref_reinit(struct percpu_ref *ref);
* Must be used to drop the initial ref on a percpu refcount; must be called * Must be used to drop the initial ref on a percpu refcount; must be called
* precisely once before shutdown. * precisely once before shutdown.
* *
* Puts @ref in non percpu mode, then does a call_rcu() before gathering up the * Switches @ref into atomic mode before gathering up the percpu counters
* percpu counters and dropping the initial ref. * and dropping the initial ref.
*
* There are no implied RCU grace periods between kill and release.
*/ */
static inline void percpu_ref_kill(struct percpu_ref *ref) static inline void percpu_ref_kill(struct percpu_ref *ref)
{ {

2
lib/percpu-refcount.c
View File

@ -322,6 +322,8 @@ EXPORT_SYMBOL_GPL(percpu_ref_switch_to_percpu);
* This function normally doesn't block and can be called from any context * This function normally doesn't block and can be called from any context
* but it may block if @confirm_kill is specified and @ref is in the * but it may block if @confirm_kill is specified and @ref is in the
* process of switching to atomic mode by percpu_ref_switch_to_atomic(). * process of switching to atomic mode by percpu_ref_switch_to_atomic().
*
* There are no implied RCU grace periods between kill and release.
*/ */
void percpu_ref_kill_and_confirm(struct percpu_ref *ref, void percpu_ref_kill_and_confirm(struct percpu_ref *ref,
percpu_ref_func_t *confirm_kill) percpu_ref_func_t *confirm_kill)