On 11/4/19 6:26 PM, Will Deacon wrote: > On Sat, Nov 02, 2019 at 05:42:25PM +0530, Amit Daniel Kachhap wrote: >> On 10/29/19 10:28 PM, Mark Rutland wrote: >>> This series is a reworked version of Torsten's FTRACE_WITH_REGS series >>> [1]. I've tried to rework the existing code in preparatory patches so >>> that the patchable-function-entry bits slot in with fewer surprises. >>> This version is based on v5.4-rc3, and can be found in my >>> arm64/ftrace-with-regs branch [2]. >>> >>> Patch 1 adds an (optional) ftrace_init_nop(), which the core code uses >>> to initialize callsites. This allows us to avoid a synthetic MCOUNT_ADDR >>> symbol, and more cleanly separates the one-time initialization of the >>> callsite from dynamic NOP<->CALL modification. Architectures which don't >>> implement this get the existing ftrace_make_nop() with MCOUNT_ADDR. >>> >>> Recently parisc gained ftrace support using patchable-function-entry. >>> Patch 2 makes the handling of module callsite locations common in >>> kernel/module.c with a new FTRACE_CALLSITE_SECTION definition, and >>> removed the newly redundant bits from arch/parisc. >>> >>> Patches 3 and 4 move the module PLT initialization to module load time, >>> which simplifies runtime callsite modification. This also means that we >>> don't transitently mark the module text RW, and will allow for the >>> removal of module_disable_ro(). >>> >>> Patches 5 and 6 add some trivial infrastructure, with patch 7 finally >>> adding FTRACE_WITH_REGS support. Additional work will be required for >>> livepatching (e.g. implementing reliable stack trace), which is >>> commented as part of patch 7. >>> >>> Patch 8 is a trivial cleanup atop of the rest of the series, making the >>> code easier to read and less susceptible to config-specific breakage. >> I tested the whole series with my latest in-kernel ptrauth patches [1] >> and graph_tracer/function_graph_tracer works fine, So for the whole series, >> Tested-by: Amit Daniel Kachhap <amit.kachhap@xxxxxxx> >> >> Also I gave few minor comments in the individual patches. With those >> comments, >> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@xxxxxxx> Oops sorry I meant, Reviewed-off-by: Amit Daniel Kachhap <amit.kachhap@xxxxxxx> > > I don't think this means what you think it means. Please read: Thanks for pointing it. > > Documentation/process/submitting-patches.rst > > Will > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
