All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jann Horn <jannh@google.com>, Eric Biggers <ebiggers3@gmail.com>,
	Hans Liljestrand <ishkamiel@gmail.com>,
	David Windsor <dwindsor@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"arozansk@redhat.com" <arozansk@redhat.com>,
	Manfred Spraul <manfred@colorfullife.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	James Bottomley <James.Bottomley@han>
Subject: Re: [PATCH v2] refcount: Create unchecked atomic_t implementation
Date: Thu, 8 Jun 2017 13:09:31 -0700	[thread overview]
Message-ID: <20170608200931.GC2464@linux-80c1.suse> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B6FF0E5C7@IRSMSX102.ger.corp.intel.com>

On Thu, 08 Jun 2017, Reshetova, Elena wrote:

>> On Wed, Jun 07, 2017 at 07:58:31PM -0700, Kees Cook wrote:
>> > Many subsystems will not use refcount_t unless there is a way to build the
>> > kernel so that there is no regression in speed compared to atomic_t. This
>> > adds CONFIG_REFCOUNT_FULL to enable the full refcount_t implementation
>> > which has the validation but is slightly slower. When not enabled,
>> > refcount_t uses the basic unchecked atomic_t routines, which results in
>> > no code changes compared to just using atomic_t directly.
>> >
>> > Signed-off-by: Kees Cook <keescook@chromium.org>
>> > ---
>> > This is v2 of this patch, which I've split from the arch-specific
>> > alternative implementation for x86. Getting this patch in will unblock
>> > atomic_t -> refcount_t conversion, and the x86 alternative implementation
>> > can be developed in parallel. Changes from v1: use better atomic ops,
>> > thanks to Elena and Peter.
>>
>> Yeah, can we get this in ASAP?  Without having to always incur the over
>> this will allow us to convert subsystems to refcount_t broadly.
>
>+1. If this gets in, I can refresh the rest of the patches in net, mm, ipc, block, etc. and send them for review again.

Yes, this would be a prerequisite for ipc; which I initially thought didn't
take a performance hit.

Thanks,
Davidlohr

WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jann Horn <jannh@google.com>, Eric Biggers <ebiggers3@gmail.com>,
	Hans Liljestrand <ishkamiel@gmail.com>,
	David Windsor <dwindsor@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"arozansk@redhat.com" <arozansk@redhat.com>,
	Manfred Spraul <manfred@colorfullife.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	"x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"David S. Miller" <davem@davemloft.net>,
	Rik van Riel <riel@redhat.com>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v2] refcount: Create unchecked atomic_t implementation
Date: Thu, 8 Jun 2017 13:09:31 -0700	[thread overview]
Message-ID: <20170608200931.GC2464@linux-80c1.suse> (raw)
Message-ID: <20170608200931.MR0tuH9qeQFWeifsU-_pK9n2XoOC5pB2foQolKI-gi8@z> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B6FF0E5C7@IRSMSX102.ger.corp.intel.com>

On Thu, 08 Jun 2017, Reshetova, Elena wrote:

>> On Wed, Jun 07, 2017 at 07:58:31PM -0700, Kees Cook wrote:
>> > Many subsystems will not use refcount_t unless there is a way to build the
>> > kernel so that there is no regression in speed compared to atomic_t. This
>> > adds CONFIG_REFCOUNT_FULL to enable the full refcount_t implementation
>> > which has the validation but is slightly slower. When not enabled,
>> > refcount_t uses the basic unchecked atomic_t routines, which results in
>> > no code changes compared to just using atomic_t directly.
>> >
>> > Signed-off-by: Kees Cook <keescook@chromium.org>
>> > ---
>> > This is v2 of this patch, which I've split from the arch-specific
>> > alternative implementation for x86. Getting this patch in will unblock
>> > atomic_t -> refcount_t conversion, and the x86 alternative implementation
>> > can be developed in parallel. Changes from v1: use better atomic ops,
>> > thanks to Elena and Peter.
>>
>> Yeah, can we get this in ASAP?  Without having to always incur the over
>> this will allow us to convert subsystems to refcount_t broadly.
>
>+1. If this gets in, I can refresh the rest of the patches in net, mm, ipc, block, etc. and send them for review again.

Yes, this would be a prerequisite for ipc; which I initially thought didn't
take a performance hit.

Thanks,
Davidlohr

  reply	other threads:[~2017-06-08 20:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08  2:58 [PATCH v2] refcount: Create unchecked atomic_t implementation Kees Cook
2017-06-08  2:58 ` Kees Cook
2017-06-08  5:56 ` Greg KH
2017-06-08  5:56   ` Greg KH
2017-06-20  4:47   ` Kees Cook
2017-06-20  4:47     ` Kees Cook
2017-06-08  6:58 ` Christoph Hellwig
2017-06-08  6:58   ` Christoph Hellwig
2017-06-08  7:53   ` Reshetova, Elena
2017-06-08  7:53     ` Reshetova, Elena
2017-06-08 20:09     ` Davidlohr Bueso [this message]
2017-06-08 20:09       ` Davidlohr Bueso
2017-06-09  4:24       ` Manfred Spraul
2017-06-09  4:24         ` Manfred Spraul
2017-06-09  7:20         ` Peter Zijlstra
2017-06-09  7:20           ` Peter Zijlstra
2017-06-21  9:57 ` Ingo Molnar
2017-06-21  9:57   ` Ingo Molnar

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=20170608200931.GC2464@linux-80c1.suse \
    --to=dave@stgolabs.net \
    --cc=James.Bottomley@han \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arozansk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dwindsor@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=ebiggers3@gmail.com \
    --cc=elena.reshetova@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=ishkamiel@gmail.com \
    --cc=jannh@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=serge@hallyn.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.