Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1155240imm; Fri, 11 May 2018 11:54:50 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpFsfHZOvU7P3SPRmEPq8/9RhNN91jcIk92lGC6Ya1gYNtN+RH7apKFS60oyvCByqMAANeD X-Received: by 2002:a62:d751:: with SMTP id v17-v6mr6628570pfl.39.1526064890301; Fri, 11 May 2018 11:54:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526064890; cv=none; d=google.com; s=arc-20160816; b=lAxXwuiSqsDrXIbr+OAgRTurzshFChjMeiVJzIKbYFSt9DTBOAw5kc9OekYpjt0T8d RQT0ylgTh9hrSHxy/cPXTRoOEHozMXSlmN3Nhib7Xt+0eiI2KBgYRpD0OL+q1G8j7+Lx +oQGHmUsqWZwengnWwSItHQ5rriAs3BKIGOdx2D1Cv19Epc2xPEKKFfJod0pTLasshcS hSKpJ4uIv4R1/XVOAD65wRAaERReYkcZO0u4R0eEgH0+IYXHUY5IvF5uWgeOiMincQN9 K4pdsCTTKYGJfZ/lyyS5PBaZSDikVNa/olcWbxg/G3uZtQwIG65sTPbX0eO4MVDVKga0 ONXw== 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:arc-authentication-results; bh=HtPN37lBoiAKiDsy0SzuVzkmgGhcxIaSiUUO4yKEh38=; b=cgGyCOCBstf/cW8TePL4ZLnkgUdioEFgMbMRE+jGd49p18KUAv37pLBi6+t8858J+l rh3gL2d6zk4k6/xemlSSlE9siCIZ7nl3G/7TuB/MvEflnA/VdqChkMBhcnp2uk86JtKz 0Bfn4qXhNU3VLu+Gkesd4KOr+h4YvryNu+flgcuGhIHGgljctzJUoFgVYQHm+k1meDd1 VWldVmOK3Z523bHlnTpwIk8IP24ePBT5nD7dWj0UhH32f9iOzrozqC1szf3ejvk0qTaZ nmSmRM6jfTofIZx0EQBNTvtTz8wpYWIrMfXuaG/cuv8F1NZILxpRv9IUVSqs+mJZAXoB f1hA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z21-v6si3713882pfn.31.2018.05.11.11.54.35; Fri, 11 May 2018 11:54:50 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751739AbeEKSyS (ORCPT + 99 others); Fri, 11 May 2018 14:54:18 -0400 Received: from terminus.zytor.com ([198.137.202.136]:43217 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751373AbeEKSyQ (ORCPT ); Fri, 11 May 2018 14:54:16 -0400 Received: from hanvin-mobl2.amr.corp.intel.com ([192.55.54.40]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id w4BIrjet3867040 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 11 May 2018 11:53:45 -0700 Subject: Re: [PATCH] x86: pad assembly functions with INT3 To: David Laight , "'Alexey Dobriyan'" , "tglx@linutronix.de" , "mingo@redhat.com" Cc: "linux-kernel@vger.kernel.org" , "x86@kernel.org" References: <20180507213755.GA32406@avx2> <20fb84fd5eef4c45b2d38d0290235d5d@AcuMS.aculab.com> From: "H. Peter Anvin" Message-ID: <5c6762fe-5cbe-42ed-ac4e-a7144b8ef7ad@zytor.com> Date: Fri, 11 May 2018 11:53:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20fb84fd5eef4c45b2d38d0290235d5d@AcuMS.aculab.com> Content-Type: text/plain; charset=utf-8 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 05/10/18 09:39, David Laight wrote: > From: Alexey Dobriyan >> Sent: 07 May 2018 22:38 >> >> Use INT3 instead of NOP. All that padding between functions is >> an illegal area, no legitimate code should jump into it. >> >> I've checked x86_64 allyesconfig disassembly, all changes looks sane: >> INT3 is only used after RET or unconditional JMP. > > I thought there was a performance penalty (on at least some cpu) > depending on the number of and the actual instructions used for padding. > > I believe that is why gcc generates a small number of very long 'nop' > instructions when padding code. > There is a performance penalty for using NOP instructions *in the fallthrough case.* In the case where the padding is never supposed to be executed, which is what we're talking about here, it is irrelevant. I thought I had filed a gcc enhancement request, but I can't find it now, so I just filed this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85751 -hpa