All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.