linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Will Deacon <will@kernel.org>, Kees Cook <keescook@chromium.org>,
	Ingo Molnar <mingo@kernel.org>,
	Elena Reshetova <elena.reshetova@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Jan Glauber <jglauber@marvell.com>
Subject: [PATCH 0/6] Rework REFCOUNT_FULL using atomic_fetch_* operations
Date: Fri,  2 Aug 2019 11:09:54 +0100	[thread overview]
Message-ID: <20190802101000.12958-1-will@kernel.org> (raw)

Hi all,

This patch series reworks the generic REFCOUNT_FULL implementation using
atomic_fetch_* operations so that the performance impact of the cmpxchg()
loops is mitigated for common refcount operations. The algorithm was
heavily inspired by Ard's assembly implementation for arm64:

  http://lkml.kernel.org/r/20190619105431.2630-1-ard.biesheuvel@linaro.org

but I figured we could achieve something similar using atomics in generic
code.

Although the revised implementation passes all of the lkdtm REFCOUNT
tests, there is a race condition introduced by the deferred saturation
whereby if INT_MIN + 2 tasks take a reference on a refcount at
REFCOUNT_MAX and are each preempted between detecting overflow and
writing the saturated value without being rescheduled, then another task
may end up erroneously freeing the object when it drops the refcount and
sees zero. It doesn't feel like a particularly realistic case to me, but
I thought I should mention it in case somebody else knows better.

Will

Cc: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Jan Glauber <jglauber@marvell.com>

--->8

Will Deacon (6):
  lib/refcount: Define constants for saturation and max refcount values
  lib/refcount: Ensure integer operands are treated as signed
  lib/refcount: Remove unused refcount_*_checked() variants
  lib/refcount: Move bulk of REFCOUNT_FULL implementation into header
  lib/refcount: Improve performance of generic REFCOUNT_FULL code
  lib/refcount: Consolidate REFCOUNT_{MAX,SATURATED} definitions

 drivers/misc/lkdtm/refcount.c |   8 --
 include/linux/refcount.h      | 236 +++++++++++++++++++++++++++++++++++++----
 lib/refcount.c                | 238 +-----------------------------------------
 3 files changed, 219 insertions(+), 263 deletions(-)

-- 
2.11.0


             reply	other threads:[~2019-08-02 10:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02 10:09 Will Deacon [this message]
2019-08-02 10:09 ` [PATCH 1/6] lib/refcount: Define constants for saturation and max refcount values Will Deacon
2019-08-02 10:09 ` [PATCH 2/6] lib/refcount: Ensure integer operands are treated as signed Will Deacon
2019-08-02 10:09 ` [PATCH 3/6] lib/refcount: Remove unused refcount_*_checked() variants Will Deacon
2019-08-02 10:09 ` [PATCH 4/6] lib/refcount: Move bulk of REFCOUNT_FULL implementation into header Will Deacon
2019-08-02 18:52   ` Peter Zijlstra
2019-08-03  2:23     ` Kees Cook
2019-08-09 16:04       ` Will Deacon
2019-08-12 18:08         ` Kees Cook
2019-08-02 10:09 ` [PATCH 5/6] lib/refcount: Improve performance of generic REFCOUNT_FULL code Will Deacon
2019-08-02 18:55   ` Peter Zijlstra
2019-08-09 15:38     ` Will Deacon
2019-08-02 10:10 ` [PATCH 6/6] lib/refcount: Consolidate REFCOUNT_{MAX,SATURATED} definitions Will Deacon
2019-08-02 18:49 ` [PATCH 0/6] Rework REFCOUNT_FULL using atomic_fetch_* operations Peter Zijlstra
2019-08-09 15:34   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190802101000.12958-1-will@kernel.org \
    --to=will@kernel.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=elena.reshetova@intel.com \
    --cc=guohanjun@huawei.com \
    --cc=jglauber@marvell.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).