lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 19 Mar 2023 12:14:22 +0800 From: Donglin Peng <pengdonglin@...gfor.com.cn> To: Steven Rostedt <rostedt@...dmis.org> Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, mhiramat@...nel.org, mark.rutland@....com, will@...nel.org, catalin.marinas@....com, palmer@...belt.com, paul.walmsley@...ive.com, tglx@...utronix.de, dave.hansen@...ux.intel.com, x86@...nel.org, mingo@...hat.com, xiehuan09@...il.com, dinghui@...gfor.com.cn, huangcun@...gfor.com.cn, dolinux.peng@...il.com, linux-trace-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v4 1/2] function_graph: Support recording and printing the return value of function On 2023/3/19 0:40, Steven Rostedt wrote: > On Fri, 17 Mar 2023 10:49:49 +0800 > Donglin Peng <pengdonglin@...gfor.com.cn> wrote: > >>> So, really it depends what size of return value we want to report. >>> Also, please bear in mind that where a function returns a 32-bit >>> value, that will be in r0, and r1 will be whatever happened to be >>> in it at function exit - there's no defined value for r1. >>> >> >> Thank you. I will document this as a limitation of fgraph return value. >> It can just cover most cases at present and I think the r0 is enough. > > One thing we could possibly do here is to use BTF or objtool to denote > the return value of each function and use 2 bits of the ftrace > rec->flags to state that it is: > > 0 - void > 1 - 1 word size return > 2 - 2 word size return Yeah, the BTF contains details of the function return type. However the direct search cost is a bit high, we may parse it to fill the dyn_ftrace.flags. > > I believe we can get access to the function's rec via the return call > (or add that access) and pass both words to the return function, and > then the return callback can use this lookup to determine what values > are useful or not. Yeah, we can obtain the function address via ret_stack in the function ftrace_pop_return_trace, then pass the address to lookup_rec to find the dyn_ftrace. > > In any case, I would suggest passing both regs to the callback, and for > now just ignore the second reg until we can come up with a way to > differentiate each function. > Yeah, I will modify it to pass two regs in v5. > -- Steve
Powered by blists - more mailing lists