On 2017/05/18 03:22PM, Michael Ellerman wrote: > "Naveen N. Rao" <naveen.n....@linux.vnet.ibm.com> writes: > > > As pointed out in x86 setjmp_pre_handler(), we need to save and restore > > the parameter save area since the jprobe hook might overwrite it. Since > > there is no easy way to identify the size of the parameter save area, > > we choose to save/restore a fixed 16 [double]word-sized area including > > the stack frame header. > > > > We introduce STACK_FRAME_PARM_SAVE to encode the offset of the parameter > > save area from the stack frame pointer. Remove the similarly named > > PARAMETER_SAVE_AREA_OFFSET in ptrace.c as those are currently not used > > anywhere. > > > > Signed-off-by: Naveen N. Rao <naveen.n....@linux.vnet.ibm.com> > > --- > > Michael, > > I've set the limit to 16 parameters as being a "reasonable" number, but > > we could very well make this 24 or 32 if we want to be sure. Let me > > know what you prefer. > > That sounds incredibly fragile. Are we really just guessing at the size > required? What happens if we under estimate, do we crash, silently > corrupt data .. ?
There is a _chance_ of crashing/corrupting data, yes. The conditions required for that include: - a function that takes > 8 parameters, hence requiring parameters to be passed on the stack - the jprobe hook replacing that function having to clobber one of those parameters passed on the stack. Assuming C code, I am not sure what conditions could trigger gcc to emit code that may do the latter. However, per the ABI, this is possible as the parameter save area is owned by the callee and the caller can't assume that it'll remain intact. Given the slim probability, I felt that saving/restoring a fixed amount of stack is sufficient to mitigate this. The other option is to save/restore the entire stack frame, but that may be quite large and just a lot of overhead in most cases. Thoughts? - Naveen
