Messages in this thread | | | Date | Tue, 31 Mar 2020 16:17:55 -0500 | From | Josh Poimboeuf <> | Subject | Re: [RFC][PATCH] objtool,ftrace: Implement UNWIND_HINT_RET_OFFSET |
| |
On Tue, Mar 31, 2020 at 10:40:47PM +0200, Peter Zijlstra wrote: > > I now understand what you're trying to do with the RET_TAIL thing, and I > > guess it's ok for the ftrace case. But I'd rather an UNWIND_HINT_IGNORE > > before the tail cail, which would tell objtool to just silence the tail > > call warning. It's simpler for the user to understand, it's simpler > > logic in objtool, and I think an "ignore warnings for the next insn" > > hint would be more generally applicable anyway. > > I like how this is specific on how far the stack can be off, as opposed > so say 'ignore any warning on this instruction'. > > Because by saying this RET should be +8, we'll still get a warning when > this is not the case (and in fact I should strengthen the patch to > implement that). > > Also, you don't want to suppress any other valid warning at that > instruction.
Ok, I guess I'm convinced :-) As we continue to add new warnings to objtool, it is true that "ignore all warnings at this insn" is probably too broad.
/me stops writing patch
BTW, if we're in agreement that this hint doesn't belong for sync_core(), will sp_offset always be +8? Just wondering if we can hard-code that assumption.
> > I know you said it's like an indirect tail call with a bigger frame, but > > that's kind of stretching it because the function frame is still there. > > > > And objtool doesn't treat it like a tail call at all. In fact, it > > handles it *completely* differently from the normal ret-tail-call case. > > Instead of silencing a tail call warning, it adjusts the stack offset > > and continues the code path. > > > > This basically adds *two* new hint types, while trying to call them the > > same thing. There's no overlapping functionality between them in > > objtool, other than the use of the same insn->ret_offset variable. But > > it's two distinct functionalities, depending on the context (return/tail > > vs IRETQ). > > I'm not against adding a second/separate hint for this. In fact, I > almost considered teaching objtool how to interpret the whole IRET frame > so that we can do it without hints. It's just that that's too much code > for this one case. > > HINT_IRET_SELF ?
Despite my earlier complaint about stack size knowledge, we could just forget the hint and make "iretq in C code" equivalent to "reduce stack size by arch_exception_stack_size()" and keep going. There's file->c_file which tells you it's a C file.
-- Josh
| |