Messages in this thread | | | Date | Mon, 15 Jun 2020 18:17:13 +0200 | From | Peter Zijlstra <> | Subject | Re: [patch V6 00/37] x86/entry: Rework leftovers and merge plan |
| |
On Sat, May 23, 2020 at 03:08:36PM +0200, Peter Zijlstra wrote: > On Sat, May 23, 2020 at 10:52:24AM +0800, Lai Jiangshan wrote: > > > Hello, > > > > I, who don't know how does the objtool handle it, am just curious. > > _begin() and _end() are symmetrical, which means if _end() (without nop) > > can escape, so can _begin() in a reverse way. For example: > > > > noinstr void foo() > > { > > instrumentation_begin(); > > do { > > instrumentation_begin(); > > ... > > instrumentation_end(); > > } while (cond); > > bar(); > > instrumentation_end(); > > } > > > > Here, the first _begin() can be "dragged" into the do-while block. > > Expectedly, objtool validation should not complain here. > > > > But objtool validation's not complaining means it can handle it > > magically correctly (by distinguishing how many _begin()s should > > be taken around the jmp target when jmp in a specific path), or > > handle it by not checking if all paths have the same count onto > > a jmp target (a little nervous to me), or other possible ways. > > No, I tihnk you're right. It could be we never hit this particular > problem. Even the one described, where end leaks out, is quite rare. For > instance, the last one I debgged (that led to this patch) only showed > itself with gcc-9, but not with gcc-8 for example. > > Anyway, if we ever find the above, I'll add the NOP to begin too.
FYI, I just found one, I'll be making instrumentation_begin() a NOP too.
| |