linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Julien Thierry <jthierry@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	tglx@linutronix.de, linux-kernel@vger.kernel.org, x86@kernel.org,
	mhiramat@kernel.org, mbenes@suse.cz,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v2] objtool,ftrace: Implement UNWIND_HINT_RET_OFFSET
Date: Wed, 1 Apr 2020 19:09:10 +0200	[thread overview]
Message-ID: <20200401170910.GX20730@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <d2cad75e-1708-f0bf-7f88-194bcb29e61d@redhat.com>

On Wed, Apr 01, 2020 at 04:43:35PM +0100, Julien Thierry wrote:

> > +static bool has_modified_stack_frame(struct instruction *insn, struct insn_state *state)
> >   {
> > +	u8 ret_offset = insn->ret_offset;
> >   	int i;
> > 
> > -	if (state->cfa.base != initial_func_cfi.cfa.base ||
> > -	    state->cfa.offset != initial_func_cfi.cfa.offset ||
> > -	    state->stack_size != initial_func_cfi.cfa.offset ||
> > -	    state->drap)
> > +	if (state->cfa.base != initial_func_cfi.cfa.base || state->drap)
> > +		return true;
> > +
> > +	if (state->cfa.offset != initial_func_cfi.cfa.offset &&
> > +	    !(ret_offset && state->cfa.offset == initial_func_cfi.cfa.offset + ret_offset))
> 
> Isn't that the same thing as "state->cfa.offset !=
> initial_func_cfi.cfa.offset + ret_offset" ?

I'm confused on what cfa.offset is, sometimes it increase with
stack_size, sometimes it doesn't.

ISTR that for the ftrace case it was indeed cfa.offset + 8, but for the
IRET case below (where it is now not used anymore) it was cfa.offset
(not cfa.offset + 40, which I was expecting).

> > +		return true;
> > +
> > +	if (state->stack_size != initial_func_cfi.cfa.offset + ret_offset)
> >   		return true;
> > 
> > -	for (i = 0; i < CFI_NUM_REGS; i++)
> > +	for (i = 0; i < CFI_NUM_REGS; i++) {
> >   		if (state->regs[i].base != initial_func_cfi.regs[i].base ||
> >   		    state->regs[i].offset != initial_func_cfi.regs[i].offset)
> >   			return true;
> > +	}
> > 
> >   	return false;
> >   }

> > @@ -2185,6 +2148,13 @@ static int validate_branch(struct objtoo
> > 
> >   			break;
> > 
> > +		case INSN_EXCEPTION_RETURN:
> > +			if (func) {
> > +				state.stack_size -= arch_exception_frame_size;
> > +				break;
> 
> Why break instead of returning? Shouldn't an exception return mark the end
> of a branch (whether inside or outside a function) ?
> 
> Here it seems it will continue to the next instruction which might have been
> unreachable.

The code in question (x86's sync_core()), is an exception return to
self. It pushes an exception frame that points to right after the
exception return instruction.

This is the only usage of IRET in STT_FUNC symbols.

So rather than teaching objtool how to interpret the whole
push;push;push;push;push;iret sequence, teach it how big the frame is
(arch_exception_frame_size) and let it continue.

All the other (real) IRETs are in STT_NOTYPE in the entry assembly.

> > +			}
> > +
> > +			/* fallthrough */
> 
> What is the purpose of the fallthrough here? If the exception return was in
> a function, it carried on to the next instruction, so it won't use the
> WARN_FUNC(). So, if I'm looking at the right version of the code only the
> "return 0;" will be used. And, unless my previous comment is wrong, I'd
> argue that we should return both for func and !func.

That came from the fact that we split it out of INSN_CONTEXT_SWITCH.
You're right that it has now reduced to just return 0.

> >   		case INSN_CONTEXT_SWITCH:
> >   			if (func && (!next_insn || !next_insn->hint)) {
> >   				WARN_FUNC("unsupported instruction in callable function",




  reply	other threads:[~2020-04-01 17:09 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 17:45 [PATCH v4 00/13] objtool: vmlinux.o and moinstr validation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 01/13] objtool: Remove CFI save/restore special case Peter Zijlstra
2020-03-26 11:30   ` Peter Zijlstra
2020-03-26 12:58     ` Peter Zijlstra
2020-03-26 13:44       ` Josh Poimboeuf
2020-03-26 15:38         ` Peter Zijlstra
2020-03-27  4:19           ` Josh Poimboeuf
2020-03-26 14:44       ` Miroslav Benes
2020-03-26 15:04         ` Miroslav Benes
2020-03-26 13:00     ` Peter Zijlstra
2020-03-26 13:56     ` Josh Poimboeuf
2020-03-26 15:49       ` Peter Zijlstra
2020-03-26 19:57         ` Peter Zijlstra
2020-03-27  1:00           ` Josh Poimboeuf
2020-03-30 17:02             ` Peter Zijlstra
2020-03-30 19:02               ` Josh Poimboeuf
2020-03-30 20:02                 ` Peter Zijlstra
2020-03-30 20:29                   ` Peter Zijlstra
2020-03-31 11:16                   ` [RFC][PATCH] objtool,ftrace: Implement UNWIND_HINT_RET_OFFSET Peter Zijlstra
2020-03-31 15:31                     ` Steven Rostedt
2020-03-31 16:06                       ` [RFC][PATCH] x86,ftrace: Shrink ftrace_regs_caller() by one byte Peter Zijlstra
2020-03-31 19:58                       ` [RFC][PATCH] objtool,ftrace: Implement UNWIND_HINT_RET_OFFSET Peter Zijlstra
2020-03-31 20:26                         ` Josh Poimboeuf
2020-03-31 20:23                     ` Josh Poimboeuf
2020-03-31 20:40                       ` Peter Zijlstra
2020-03-31 21:07                         ` Peter Zijlstra
2020-03-31 21:17                         ` Josh Poimboeuf
2020-03-31 21:20                           ` Josh Poimboeuf
2020-03-31 22:27                             ` [PATCH v2] " Peter Zijlstra
2020-04-01 14:14                               ` Josh Poimboeuf
2020-04-01 14:22                                 ` Peter Zijlstra
2020-04-01 14:39                                   ` Josh Poimboeuf
2020-04-01 15:38                                     ` Peter Zijlstra
2020-04-01 15:39                                     ` Steven Rostedt
2020-04-01 15:43                               ` Julien Thierry
2020-04-01 17:09                                 ` Peter Zijlstra [this message]
2020-04-01 17:33                                   ` Steven Rostedt
2020-04-01 17:45                                     ` Peter Zijlstra
2020-04-01 18:20                                       ` Steven Rostedt
2020-04-01 20:20                                         ` Peter Zijlstra
2020-04-01 17:37                                   ` Josh Poimboeuf
2020-04-02  6:41                                   ` Julien Thierry
2020-04-02  6:56                                     ` Julien Thierry
2020-04-02  7:50                                     ` Peter Zijlstra
2020-04-02  8:16                                       ` Julien Thierry
2020-04-02  8:17                                       ` Peter Zijlstra
2020-04-02  8:29                                         ` Julien Thierry
2020-04-02  8:58                                           ` Miroslav Benes
2020-03-25 17:45 ` [PATCH v4 02/13] objtool: Factor out CFI hints Peter Zijlstra
2020-03-25 18:26   ` Miroslav Benes
2020-03-25 19:41     ` Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 03/13] objtool: Rename struct cfi_state Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 04/13] objtool: Fix !CFI insn_state propagation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 05/13] objtool: Implement noinstr validation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 06/13] objtool: Optimize !vmlinux.o again Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 07/13] objtool: Use sec_offset_hash() for insn_hash Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 08/13] objtool: Detect loading function pointers across noinstr Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 09/13] kbuild/objtool: Add objtool-vmlinux.o pass Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 10/13] objtool: Avoid iterating !text section symbols Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 11/13] objtool: Rearrange validate_section() Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 12/13] objtool: Add STT_NOTYPE noinstr validation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 13/13] objtool: Also consider .entry.text as noinstr Peter Zijlstra
2020-03-25 19:03 ` [PATCH v4 00/13] objtool: vmlinux.o and moinstr validation Miroslav Benes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200401170910.GX20730@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=jpoimboe@redhat.com \
    --cc=jthierry@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).