Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1599315yba; Thu, 4 Apr 2019 14:09:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJWKhCRRV9s2tGyYsAFOf2JgYObI3QV1wA106Woi3WkachyVPGg+yFdNTOimY4sy+LMLKa X-Received: by 2002:a62:1b03:: with SMTP id b3mr8387159pfb.150.1554412189531; Thu, 04 Apr 2019 14:09:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554412189; cv=none; d=google.com; s=arc-20160816; b=i5x/h7jycGCQxTF4h6gGqoD4HXHseaZ5lQ81l8eLoZFUeW326HbSuVqJYk1rhsQ+XY UyF4Ba4LR8NuyeJNrKYrcNa1RmBloIHQl1OxagshRW1M+DiTfrp7j1tHiiCPyABsTh6V chCk+9Uzxie7mjEbEQ3ommV/zvNGx9ORa2g3aO+dp0LkOE4o2n34SGha3GUNwjSpiGn5 LZp+MC1wO12tPvsDnwSz9pdeC9SrXGW3xcg2w+M1H4/PFMbhkEkx28ZEY7bZWGd98Yl3 w+jJZ3i9iWfZHUv1Zl2eggMcVpj7+n7T7mpey/gCbwUqpiBZIt0QNu7fSYYPqNF5L9aX +h/A== 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; bh=o1wJwNYRnXpup2bxqQH9bKI+mZDLraoSrDs4UAHrt/E=; b=UUFNPKuaYcIZCBOZYM85rqRelweOCoAHBreB4D8fmz7UC0bqALTSAkf4QXU1lfSuBb IF/8y473c3mC9gae3BmQre/49aoJAlXDtaU4LqKnqterm2B4eh/bhirFeCWD10TUFtIf jIShjqP0uraW/6HMZqaoAv0+X/G3wVKNYWP1zMk5bPQtAseY8iN0ykeW/sJ2gTjupb06 3LjNk8Inw1QdxKIjFJOhKZlksT9NaJFzIJHLXxaTiRuZWhL1kjfh17MH/vFiGS6BNSZD gdofoEVVOYVXkpWTgKBtGJ0FBi9LS5FYJA37yhv4WuC7EkkYIBQ0wY3ORjDLGM5ZPuJB UW0g== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p2si1933680pgi.372.2019.04.04.14.09.33; Thu, 04 Apr 2019 14:09:49 -0700 (PDT) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730725AbfDDUP7 (ORCPT + 99 others); Thu, 4 Apr 2019 16:15:59 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:39027 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730709AbfDDUP7 (ORCPT ); Thu, 4 Apr 2019 16:15:59 -0400 Received: by mail-qk1-f196.google.com with SMTP id c189so2492358qke.6 for ; Thu, 04 Apr 2019 13:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=o1wJwNYRnXpup2bxqQH9bKI+mZDLraoSrDs4UAHrt/E=; b=Hq7lJXf4tjECrbu0mOQWq7p2eTz1WBr9DL1BZdfoQSnI1co/34EXWk7IDba0f2I4cr Q8DkRbTlLjLcgJB4tPQpaYl3FcLvq2z7ShNOcoXZZEn8viYYU5fxG0SZgKRgwWZsmmSA QppIV0fhCQ1Tesv1tYtQ9b/OTu5+3fCss5lkujwbLrBM6aS7uQcpZP1/4L7yVeGkcUyO fTZY6vq7aEP521u26pLSh/tsuyfO9CmtqO+2BkeGI14I5FmZhRf1iNq/Bd3tX1NglsTm tWqON6+vAjdj9diNhEzFqw92tCVwkHFg6C85GgcP+ZajvcPfpMRSt5DQK6DsrzPdBf+A ExqA== X-Gm-Message-State: APjAAAVV+VYiYVq2nKNf+/9/4bFrTnuhgSoBJ81Jbd8ARwMk5FT7ci8v YjRa9UpZAXRDNMti61feCmcJLA== X-Received: by 2002:ae9:c310:: with SMTP id n16mr7060466qkg.8.1554408958536; Thu, 04 Apr 2019 13:15:58 -0700 (PDT) Received: from [10.150.73.190] (214.sub-174-240-132.myvzw.com. [174.240.132.214]) by smtp.gmail.com with ESMTPSA id r31sm12388496qtj.17.2019.04.04.13.15.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 13:15:57 -0700 (PDT) Subject: Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) To: Michael Ellerman , Mathieu Desnoyers , Paul Burton , Will Deacon , Boqun Feng , Heiko Carstens , Vasily Gorbik , Martin Schwidefsky , Russell King , Benjamin Herrenschmidt , Paul Mackerras Cc: carlos , Florian Weimer , Joseph Myers , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api References: <20190212194253.1951-1-mathieu.desnoyers@efficios.com> <20190212194253.1951-2-mathieu.desnoyers@efficios.com> <5166fbe9-cfe0-8554-abc7-4fc844cf2765@redhat.com> <1965431879.7576.1553529272844.JavaMail.zimbra@efficios.com> <87lg0tosfz.fsf@concordia.ellerman.id.au> From: Carlos O'Donell Message-ID: <7412087f-5ef4-0670-503e-f8de6ca3b0bb@redhat.com> Date: Thu, 4 Apr 2019 16:15:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <87lg0tosfz.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/2/19 2:02 AM, Michael Ellerman wrote: > Mathieu Desnoyers writes: >> Hi Carlos, >> >> ----- On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codonell@redhat.com wrote: > ... >> >> [...] >>>> +++ b/sysdeps/unix/sysv/linux/powerpc/bits/rseq.h >> [...] >>>> +/* Signature required before each abort handler code. */ >>>> +#define RSEQ_SIG 0x53053053 >>> >>> Why isn't this an opcode specific to power? >> >> On powerpc 32/64, the abort is placed in a __rseq_failure executable section: >> >> #define RSEQ_ASM_DEFINE_ABORT(label, abort_label) \ >> ".pushsection __rseq_failure, \"ax\"\n\t" \ >> ".long " __rseq_str(RSEQ_SIG) "\n\t" \ >> __rseq_str(label) ":\n\t" \ >> "b %l[" __rseq_str(abort_label) "]\n\t" \ >> ".popsection\n\t" >> >> That section only contains snippets of those trampolines. Arguably, it would be >> good if disassemblers could find valid instructions there. Boqun Feng could perhaps >> shed some light on this signature choice ? Now would be a good time to decide >> once and for all whether a valid instruction would be a better choice. > > I'm a bit vague on what we're trying to do here. > > But it seems like you want some sort of "eye catcher" prior to the branch? > > That value is a valid instruction on current CPUs (rlwimi. > r5,r24,6,1,9), and even if it wasn't it could become one in future. > > If you change it to 0x8053530 that is both a valid instruction and is a > nop (conditional trap immediate but with no conditions set). The s390 IBM team needs to respond to this and I want to make sure they ACK the NOP being used here because it impacts them directly. I'd like to see Martin's opinion on this. -- Cheers, Carlos.