From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBoukeDHYJbWigjWcdvsf+XY5jeBt7EnF5cXIKX/isBR6Nu7YlwWxL9Ztls3BuZfBvgsntsKK ARC-Seal: i=1; a=rsa-sha256; t=1516206620; cv=none; d=google.com; s=arc-20160816; b=jcaeFPI24V8Spn9Zt+55SxfU7V7pKyp1qi7xuLf4WXE4HECDh03YbcVxrTGpHuuNpQ I2nzN/dat4ShT3QNUmgt3l+0GOaBcjQoRY+/MIQIQ0i0mI8LET0sOP7vYq0EkQsx5fX+ aI8OFlBkOv7Fw352h5Keir+L/XANWABa8scFA9k9K5jBGPj9eiMiQxHNHujTh2zFrgbt m52ldkua/EBy2hxwNd2yn/VZsHK8vBomUgp8LdH4D49XnjErU34zGYmtJEnJ3b79KhoQ wf0fvHB/+IScHtNKfXbr1GlrAYSOeHnLrIhYzAc4AUP60IqwNgrkbyhTjkwlSJJb1DsV wPmg== 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:dkim-signature :arc-authentication-results; bh=KXwGHpBBLa1UGg8YX5kEy2dsIy4Lnn/W4JCtiIhzTZc=; b=UvoQq8hhb/Y4wcjTp9+gQdQlWiIDLphOiVPChsshUvp3y1/j1rwbd5m7Yq6a2YgS9f DfdhJVFs/uQvADZvVy2N5K4OIQvdbYZQuIuYdmXC128Qumb6vtPIE9NycYC6OYOo/3We l7M6oha8Or0l49MDqSM+x2dCYlnlQArjCXScVIYKROoU4dSWLnXEMp3LAyd4WG/LT4Fw cZGIeFZy9FIy0TPxf2Vl+L059bJgqZ+xrwYqTP4/bq1G9RvEPbCP/ocGYwaWoCOmaiH4 H0dwamG0CVMX92MRHHU9rbQFvBffgVZZLht0KBe/NisdATT7HkwNLhKqm/89m7Yvte8A 6oLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20170209 header.b=NZdZzgJd; spf=pass (google.com: best guess record for domain of peterz@infradead.org designates 65.50.211.133 as permitted sender) smtp.mailfrom=peterz@infradead.org Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20170209 header.b=NZdZzgJd; spf=pass (google.com: best guess record for domain of peterz@infradead.org designates 65.50.211.133 as permitted sender) smtp.mailfrom=peterz@infradead.org Date: Wed, 17 Jan 2018 17:30:07 +0100 From: Peter Zijlstra To: Josh Poimboeuf Cc: David Woodhouse , linux-kernel@vger.kernel.org, Dave Hansen , Ashok Raj , Thomas Gleixner , Tim Chen , Andy Lutomirski , Linus Torvalds , Greg KH , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , Dan Williams , Paolo Bonzini , Jun Nakajima , Asit Mallick , Borislav Petkov Subject: Re: [PATCH v2 06/10] objtool: Implement jump_assert for _static_cpu_has() Message-ID: <20180117163007.GA2249@hirez.programming.kicks-ass.net> References: <20180116142825.376986833@infradead.org> <20180116143241.236771093@infradead.org> <20180116230256.7uhpc3bzfj7vivmr@treble> <20180117091945.GL2228@hirez.programming.kicks-ass.net> <20180117142759.d2su6tqw2eegd7y6@treble> <20180117143021.5dowoedunbjovldw@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180117143021.5dowoedunbjovldw@treble> User-Agent: Mutt/1.9.2 (2017-12-15) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589760001477548621?= X-GMAIL-MSGID: =?utf-8?q?1589857872996670273?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Wed, Jan 17, 2018 at 08:30:21AM -0600, Josh Poimboeuf wrote: > On Wed, Jan 17, 2018 at 08:27:59AM -0600, Josh Poimboeuf wrote: > > > > > + if (insn->jump_dest == fake_jump) { > > > > > + WARN_FUNC("jump inside alternative for _static_cpu_has()", > > > > > + insn->sec, insn->offset); > > > > > + } > > > > > > > > The error message doesn't seem to match the condition, so I'm not sure > > > > which one you're trying to check, or why. > > > > > > > > IIRC, 'insn->jump_dest == fake_jump' means we reached the end of the > > > > alternative code block without hitting a jump. > > > > > > > > But based on the loop exit condition, I don't think it's ever possible > > > > for insn->jump_dest to ever point to the fake_jump at the end. > > > > > > Oof, now what was I thinking again.. So that fake_jump is inserted at > > > the end of the alternative and jumps to the code after where the > > > alternative will be patched in to simulate the code flow. > > > > > > If there is a jump inside the alternative that jumps to the end, it's > > > destination will be set to the fake jump, we have this clause for that: > > > > > > dest_off = insn->offset + insn->len + insn->immediate; > > > if (dest_off == special_alt->new_off + special_alt->new_len) > > > insn->jump_dest = fake_jump; > > > > > > if that happens for static_cpu_has(), bad things happened. > > > > > > So the only way for a jump to have fake_jump as destination is if the > > > jump is inside the alternative (but to the end) and we must assert this > > > didn't happen. > > > > > > Unlikely, yes, but I figured we want to know about it if it ever does > > > happen. > > So the case you're worried about, is it an unconditional jump? As that > would be the only possibility based on the other warning. Right, the code up to that point would allow (if something really weird happened) to have fake_jump as destination there. We want to flag if that happens because bad.