From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752926AbdGXIpu (ORCPT ); Mon, 24 Jul 2017 04:45:50 -0400 Received: from merlin.infradead.org ([205.233.59.134]:45150 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751637AbdGXIpn (ORCPT ); Mon, 24 Jul 2017 04:45:43 -0400 Date: Mon, 24 Jul 2017 10:44:55 +0200 From: Peter Zijlstra To: Michael Ellerman Cc: Kees Cook , Andrew Morton , Ingo Molnar , Josh Poimboeuf , Christoph Hellwig , "Eric W. Biederman" , Jann Horn , Eric Biggers , Elena Reshetova , Hans Liljestrand , Greg KH , Alexey Dobriyan , "Serge E. Hallyn" , arozansk@redhat.com, Davidlohr Bueso , Manfred Spraul , "axboe@kernel.dk" , James Bottomley , "x86@kernel.org" , Arnd Bergmann , "David S. Miller" , Rik van Riel , LKML , linux-arch , "kernel-hardening@lists.openwall.com" Subject: Re: [PATCH v6 0/2] x86: Implement fast refcount overflow protection Message-ID: <20170724084455.o5asa55fckgyjri2@hirez.programming.kicks-ass.net> References: <1500422614-94821-1-git-send-email-keescook@chromium.org> <20170720091106.kigtr6zy7pjgk2s6@gmail.com> <20170721142255.586224f0db9cf0714e654859@linux-foundation.org> <87zibujq5t.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zibujq5t.fsf@concordia.ellerman.id.au> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 24, 2017 at 04:38:06PM +1000, Michael Ellerman wrote: > What I'm not entirely clear on is what the best trade off is in terms of > overhead vs checks. The summary of behaviour between the fast and full > versions you promised Ingo will help there I think. That's something that's probably completely different for PPC than it is for x86. Both because your primitive is LL/SC and thus the saturation semantics we need a cmpxchg loop for are more natural in your case anyway, and the fact that your LL/SC is horrendously slow in any case. Also, I still haven't seen an actual benchmark where our cmpxchg loop actually regresses anything, just a lot of yelling about potential regressions :/