[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170301073816.GA24100@gmail.com>
Date: Wed, 1 Mar 2017 08:38:16 +0100
From: Ingo Molnar <mingo@...nel.org>
To: David Windsor <dwindsor@...il.com>
Cc: peterz@...radead.org, elena.reshetova@...el.com,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] refcount: add refcount_t API kernel-doc comments
* David Windsor <dwindsor@...il.com> wrote:
> This adds kernel-doc comments for the new refcount_t API.
>
> Signed-off-by: David Windsor <dwindsor@...il.com>
> ---
> include/linux/refcount.h | 19 ++++++++++
> lib/refcount.c | 95 +++++++++++++++++++++++++++++++++++++++++++-----
> 2 files changed, 105 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/refcount.h b/include/linux/refcount.h
> index 0023fee..3c02135 100644
> --- a/include/linux/refcount.h
> +++ b/include/linux/refcount.h
> @@ -6,17 +6,36 @@
> #include <linux/spinlock.h>
> #include <linux/kernel.h>
>
> +/**
> + * refcount_t - variant of atomic_t specialized for reference counts
> + * @refs: atomic_t counter field
> + *
> + * The counter saturates at UINT_MAX and will not move once
> + * there. This avoids wrapping the counter and causing 'spurious'
> + * use-after-free issues.
Let's not beat around the bush:
s/issues/bugs
> +/**
> + * refcount_add - add a value to a refcount
> + * @i: the value to add to the refcount
> + * @r: the refcount
> + *
> + * Similar to atomic_add(), will saturate at UINT_MAX and WARN.
I realize you picked it up from the existing comments, but if we push this into
docbook I'd phrase it this way:
* Similar to atomic_add(), but will saturate at UINT_MAX and WARN.
(The 'but' contasts the main difference to atomic_add().)
> + */
> void refcount_add(unsigned int i, refcount_t *r)
> {
> WARN(!refcount_add_not_zero(i, r), "refcount_t: addition on 0; use-after-free.\n");
> }
> EXPORT_SYMBOL_GPL(refcount_add);
>
> -/*
> +/**
> + * refcount_inc_not_zero - increment a refcount unless it is 0
> + * @r: the refcount to increment
So this is slightly different from the phrasing earlier on:
+/**
+ * refcount_add_not_zero - add a value to a refcount unless the refcount is 0
+ * @i: the value to add to the refcount
+ * @r: the refcount
+ *
Please harmonize it: either use 'a refcount unless it is 0' or 'a refcount unless
the refcount is 0' - but not a mixture of the two.
Same goes for similar occurances further below.
> + *
> * Similar to atomic_inc_not_zero(), will saturate at UINT_MAX and WARN.
This should be updated similarly as above.
> *
> * Provides no memory ordering, it is assumed the caller has guaranteed the
> * object memory to be stable (RCU, etc.). It does provide a control dependency
> * and thereby orders future stores. See the comment on top.
> + *
> + * Return: false if the refcount is 0, true otherwise
> */
> bool refcount_inc_not_zero(refcount_t *r)
> {
> @@ -103,11 +124,16 @@ bool refcount_inc_not_zero(refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_inc_not_zero);
>
> -/*
> +/**
> + * refcount_inc - increment a refcount
> + * @r: the refcount to increment
> + *
> * Similar to atomic_inc(), will saturate at UINT_MAX and WARN.
> *
> * Provides no memory ordering, it is assumed the caller already has a
> * reference on the object, will WARN when this is not so.
> + *
> + * Will WARN if refcount is 0.
s/if refcount/if the refcount
> */
> void refcount_inc(refcount_t *r)
> {
> @@ -115,6 +141,22 @@ void refcount_inc(refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_inc);
>
> +/**
> + * refcount_sub_and_test - subtract from a refcount and test if it is 0
> + * @i: amount to subtract from the refcount
> + * @r: the refcount
> + *
> + * Similar to atomic_dec_and_test(), it will WARN on underflow and fail to
> + * decrement when saturated at UINT_MAX.
I'd insert the 'but' here too to highlight differences to the atomic APIs.
> +/**
> + * refcount_dec_and_mutex_lock - return holding mutex if able to decrement
> + * refcount to 0
> + * @r: the refcount
> + * @lock: the mutex to be locked
> + *
> * Similar to atomic_dec_and_mutex_lock(), it will WARN on underflow and fail
> * to decrement when saturated at UINT_MAX.
> *
> * Provides release memory ordering, such that prior loads and stores are done
> * before, and provides a control dependency such that free() must come after.
> * See the comment on top.
> + *
> + * Return: true and hold lock if able to decrement refcount to 0, false
> + * otherwise
If we refer to a function parameter then it should be quoted as 'lock', but what
mean here is that we'll hold the mutex:
s/lock/mutex
> */
> bool refcount_dec_and_mutex_lock(refcount_t *r, struct mutex *lock)
> {
> @@ -242,13 +311,21 @@ bool refcount_dec_and_mutex_lock(refcount_t *r, struct mutex *lock)
> }
> EXPORT_SYMBOL_GPL(refcount_dec_and_mutex_lock);
>
> -/*
> +/**
> + * refcount_dec_and_lock - return holding spinlock if able to decrement
> + * refcount to 0
> + * @r: the refcount
> + * @lock: the spinlock to be locked
> + *
> * Similar to atomic_dec_and_lock(), it will WARN on underflow and fail to
> * decrement when saturated at UINT_MAX.
> *
> * Provides release memory ordering, such that prior loads and stores are done
> * before, and provides a control dependency such that free() must come after.
> * See the comment on top.
> + *
> + * Return: true and hold lock if able to decrement refcount to 0, false
> + * otherwise
s/lock/spinlock
Looks good otherwise and thanks for the documentation update!
Thanks,
Ingo
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
