From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226WBxrLUjznzgqJOY0hISygFj9sBtZcE40Q2pemxdZfCNev0Oz2jdjtXSRgSl+IFTnWWg+N ARC-Seal: i=1; a=rsa-sha256; t=1517368346; cv=none; d=google.com; s=arc-20160816; b=GvzQ1eL5MNknhK8bEkEr3UPYGpSAl4VcWx/tltGxmwXUw6Xg6NCmL6crc1AMbiLkvb Cj8gMzpk7FBlDCgetSQakel8AS5oEhtbIcszSqe2CS+yVASxoZQ3EafrQe8AT5ala/Dk G4rwXOw22KT7g3vpVvUd/MhdYATw2hGnO/JFN7SqF2Yiq5su/D0OeYeuzS26fzXZI9zZ jKZWceBkbF0Qb/3Lu4BsuTluJyioUauJXUx6NOnZEh9w8DNzIeYDf6QFwsmnZn5VGbQ3 CgAPfvg6LVuZepvqHVqhJ9jF2IZgZ8zz14vhEJjD2pzqMhkJp4mTHpu5zJw2hV0ucTyX ewZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=nSdMYfdm/99LfcR6UKJvFfDLAtSmgE6lkEwmvZWO1Fg=; b=0GaQ07SUH17AuJl8ivcR77aUGVfIqKXc7MOnFSYVg9tokIenbd6G6WnMFiGsLuvFUD 5yhUPD8UB9QnTgWX6BsTv0ZUfd0sWLLASECHYyAa7WXZJc55oSQgXATGXtGy9dqtB691 wVsGoOkCXav5PvmNBeP5HDCCEL11fPR+4qRTfQQIJ/AzycQv8CYif4yIAoVvgOSGssDs foGWX+pUB1FEibseUzy+1jhaTE+rf88CgmoQkykBr1+QYJcoaYOcVfQgRL6QWMJojN/U iysyuk/s24TnCmo7U9gjCjhfsPaQQhF/8apy8GPf4BYjrlwEPj7nT5G8+yUtQElJ0tp0 OVZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jpoimboe@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jpoimboe@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of jpoimboe@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jpoimboe@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Date: Tue, 30 Jan 2018 21:12:21 -0600 From: Josh Poimboeuf To: Peter Zijlstra Cc: David Woodhouse , Thomas Gleixner , linux-kernel@vger.kernel.org, Dave Hansen , Ashok Raj , Tim Chen , Andy Lutomirski , Linus Torvalds , Greg KH , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , Dan Williams , Paolo Bonzini , Jun Nakajima , Asit Mallick , Jason Baron Subject: Re: [PATCH 20/24] objtool: Another static block fail Message-ID: <20180131031221.7k2igskvrpsphc2u@treble> References: <20180123152539.374360046@infradead.org> <20180123152639.170696914@infradead.org> <20180129225252.bi2etgk3eqprcv3x@treble> <20180130095653.GZ2269@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180130095653.GZ2269@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590397857832042088?= X-GMAIL-MSGID: =?utf-8?q?1591076031455480195?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, Jan 30, 2018 at 10:56:53AM +0100, Peter Zijlstra wrote: > On Mon, Jan 29, 2018 at 04:52:53PM -0600, Josh Poimboeuf wrote: > > On Tue, Jan 23, 2018 at 04:25:59PM +0100, Peter Zijlstra wrote: > > > I've observed GCC generate: > > > > > > sym: > > > NOP/JMP 1f (static_branch) > > > JMP 2f > > > 1: /* crud */ > > > JMP 3f > > > 2: /* other crud */ > > > > > > 3: RETQ > > > > > > > > > This means we need to follow unconditional jumps; be conservative and > > > only follow if its a unique jump. > > > > > > (I've not yet figured out which CONFIG option is responsible for this, > > > a normal defconfig build does not generate crap like this) > > > > > > Signed-off-by: Peter Zijlstra (Intel) > > > > Any chance we can just add a compiler barrier to the assertion macro and > > avoid all this grow_static_blocks() mess? It seems a bit... fragile. > > It is all rather unfortunate yes.. :/ I've tried to keep the grow stuff > as conservative as possible while still covering all the weirdness I > found. And while it was great fun, I do agree it would be much better to > not have to do this. The more I look at this patch, and the previous one, the less sure I am about this idea. (This isn't a comment about the code, just some general uneasiness about the unpredictable GCC behavior we're trying to constrain, and whether it's worth the pain.) Covering all the corner cases is complicated, and it might get even more complicated with future compiler optimizations. What if we *only* use the assertions in places that really need them, like the IBRS checks? Would that allow us to simplify and drop these last two (or three) patches? Or, maybe we should just forget the whole thing and just stick with the dynamic IBRS checks with lfence. Yes, it's less ideal for the kernel, but adding these acrobatics to objtool also has a cost. -- Josh