Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7496689ybl; Tue, 24 Dec 2019 03:43:09 -0800 (PST) X-Google-Smtp-Source: APXvYqwFT5ScbfEc5OCjaf2fvISfgsI7M7QfWVi+dlzagPheShVIGJ7zTOWreMvppgipsQswZjkn X-Received: by 2002:a05:6830:124b:: with SMTP id s11mr37449645otp.333.1577187789135; Tue, 24 Dec 2019 03:43:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577187789; cv=none; d=google.com; s=arc-20160816; b=H+Rxsxop/BOPxwzskvMcG0H5R3aal6wpS0/CUDRHp7B0RLnd+h0s+wskOhdg91LiSU SzvwiJJhYM8rkDOuulMfjao9EsfHodVjGQ194IYRB+/tIiYlb8zktZjbqLKjWOBdnowt qT015Bf1KopIGHW2bUP3d07ePUBRB8yMPfv2l/nrO1Jk11c5ATB/q2tF0ZQ4pFtU9aZg fzN05u0E1N/Qi9ySStknBa2lCqWNmsfRs4ET84tzLRhPxrF97og61M2DH6LL9rOStjrk +uQ1Kgz0VGwKTweyKOoYAnm8oAabY7NST+oF/o2LAvUXtVON2PDYHNEvTTJJvfnjtFcG mIcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=zVvs2ouna/B/Vb/2RfZVUK0x0665UncRbgfLeAdSnnY=; b=byJgGoJqC8DJ7HX53EWcM6x2RH9adn7PCz3kAj+ABJnhZJXsuYqInKkL/BalsIHSuf QQgJkXQXU/L2ueJffy+NBT+u8nz4WcxX8/TQXOC9Y3nMmbgYV5JnU2DUykewwCjbYuum kGd60Ue9XNK/Se2qc9OEatkbRaNbVsRIJlxgXy3Z9d+6qTXV7v+ea/Ca3XFOBOYjI1xM Gh1o6QPDEJhOqOBMDXip+2Y9xNApRhvVoecKrOdzdSS8pdhFuAkiG02aqokVphfnvzon 2XhNcRRVGgAm80Zk0dqzlT1EkpWKbCBFRhbHkc6kmNU0QgHW7DejP9CoAYjffhyNgWIp b+Fw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b=lYmJlwXj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m24si11705582otn.67.2019.12.24.03.42.57; Tue, 24 Dec 2019 03:43:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b=lYmJlwXj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727150AbfLXLlr (ORCPT + 99 others); Tue, 24 Dec 2019 06:41:47 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:51551 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726183AbfLXLlq (ORCPT ); Tue, 24 Dec 2019 06:41:46 -0500 Received: from localhost (mailhub1-ext [192.168.12.233]) by localhost (Postfix) with ESMTP id 47hvSk5rlxz9tvqq; Tue, 24 Dec 2019 12:41:42 +0100 (CET) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=lYmJlwXj; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id WeNRdbd7lgXn; Tue, 24 Dec 2019 12:41:42 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 47hvSk41pRz9tvqp; Tue, 24 Dec 2019 12:41:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1577187702; bh=zVvs2ouna/B/Vb/2RfZVUK0x0665UncRbgfLeAdSnnY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lYmJlwXjs+sVC+Oy+w8vyY3OjRXZBsUlCFzkOcAtGzQv8VGRTjvaBltJ8BvY0yncd kvWtk3/4+I6R+C35vHzjesQG3ZepSfG0mV/VjcD+JMGNw5tKirhTpTWaYsm2DosM1j 4yvJ9P1cylNo9xPKKIo9g95EUbXTD0fvHykyHi40= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id C1F0C8B783; Tue, 24 Dec 2019 12:41:43 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EbbqCE6Lvv3b; Tue, 24 Dec 2019 12:41:43 +0100 (CET) Received: from [192.168.232.53] (unknown [192.168.232.53]) by messagerie.si.c-s.fr (Postfix) with ESMTP id ACB038B782; Tue, 24 Dec 2019 12:41:42 +0100 (CET) Subject: Re: [RFC PATCH v2 02/10] lib: vdso: move call to fallback out of common code. To: Andy Lutomirski Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Arnd Bergmann , Thomas Gleixner , Vincenzo Frascino , LKML , linuxppc-dev , linux-arm-kernel , "open list:MIPS" , X86 ML References: From: christophe leroy Message-ID: <36f1ce73-d8bc-9c46-8a2a-b6514d4a1ba0@c-s.fr> Date: Tue, 24 Dec 2019 12:41:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-Antivirus: Avast (VPS 191223-0, 23/12/2019), Outbound message X-Antivirus-Status: Not-Tested Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 24/12/2019 à 03:24, Andy Lutomirski a écrit : > On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy > wrote: >> >> On powerpc, VDSO functions and syscalls cannot be implemented in C >> because the Linux kernel ABI requires that CR[SO] bit is set in case >> of error and cleared when no error. >> >> As this cannot be done in C, C VDSO functions and syscall'based >> fallback need a trampoline in ASM. >> >> By moving the fallback calls out of the common code, arches like >> powerpc can implement both the call to C VDSO and the fallback call >> in a single trampoline function. > > Maybe the issue is that I'm not a powerpc person, but I don't > understand this. The common vDSO code is in C. Presumably this means > that you need an asm trampoline no matter what to call the C code. Is > the improvement that, with this change, you can have the asm > trampoline do a single branch, so it's logically: > > ret = [call the C code]; > if (ret == 0) { > set success bit; > } else { > ret = fallback; > if (ret == 0) > set success bit; > else > set failure bit; > } More simple than above, in fact it is: ret = [call the C code]; if (ret == 0) { set success bit; } else { ret = fallback [ which sets the success/failure bit]; } return ret > > return ret; > > instead of: > > ret = [call the C code, which includes the fallback]; C code cannot handle the success/failure bit so we need to do something which does: int assembly_to_fallback() { ret = [syscall the fallback] if (success bit set) return ret; else return -ret; } Also means going back and forth between the success bit and negative return. > if (ret == 0) > set success bit; > else > set failure bit; > > It's not obvious to me that the former ought to be faster. > >> >> The two advantages are: >> - No need play back and forth with CR[SO] and negative return value. >> - No stack frame is required in VDSO C functions for the fallbacks. > > How is no stack frame required? Do you mean that the presence of the > fallback causes worse code generation? Can you improve the fallback > instead? > When function F1 calls function F2 (with BL insn), the link register (LR) is set with the return address in F1, so that at the end of F2, F2 branches to LR (with BLR insn), that's how you return from functions. When F2 calls function F3, the same happens, LR is set to the return of F3 into F2. It means that F2 has to save LR in order to be able to return to F1, otherwise the return address from F2 into F1 is lost. But ... thinking about it once more, indeed fallback means doing a syscall, and in fact I realise that syscalls won't clobber LR, so it should be possible to do something. Let me try it. Christophe