On October 2, 2018 7:13:13 PM GMT+02:00, "Martin Liška" <mliska@xxxxxxx> wrote: >On 10/2/18 5:12 PM, Qing Zhao wrote: >> >>> On Oct 2, 2018, at 9:55 AM, Martin Liška <mliska@xxxxxxx ><mailto:mliska@xxxxxxx>> wrote: >>>>>> >>>>>> Affected functions: 5 >>>>>> __ilog2_u64/132 (include/linux/log2.h:40:5) >>>>>> ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82) >>>>>> ablkcipher_request_alloc.constprop.8/3198 >(include/linux/crypto.h:979:82) >>>>>> helper_rfc4106_decrypt/3007 >(arch/x86/crypto/aesni-intel_glue.c:1016:12) >>>>>> helper_rfc4106_encrypt/3006 >(arch/x86/crypto/aesni-intel_glue.c:939:12) >>>>>> [..skipped..] >>>>>> >>>>>> >>>>>> if we want to patch the function “fls64/63”, what else functions >we need to patch, too? my guess is: >>>>> >>>>> Hi. >>>>> >>>>> Yes, 'Affected functions' is exactly the list of functions you >want to patch. >>>>> >>>>>> >>>>>> **all the callers: >>>>>> __ilog2_u64/132 >>>>>> ablkcipher_request_alloc/1639 >>>>>> helper_rfc4106_decrypt/3007 >>>>>> helper_rfc4106_encrypt/3006 >>>>>> **and: >>>>>> ablkcipher_request_alloc.constprop.8/3198 >>>>>> is the above correct? >>>>>> >>>>>> how to generate patch for >ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in >the source code? >>>>> >>>>> Well, it's a 'static inline' function in a header file thus the >function will be inlined in all usages. >>>>> In this particular case there's no such caller function, so you're >fine. >>>> >>>> So, for cloned functions, you have to analyze them case by case >manually to see their callers? >>> >>> No, the tool should provide complete list of affected functions. >> >> So, the tool will provide the callers of the cloned routine? > >No, the tool does not list callers of affected functions. But function >call ABI is reasonable >live-patching boundary. > >then we will patch the callers of the cloned routine, Not the cloned >routine itself? >> >>> >>>> why not just disable ipa-cp or ipa-sra completely? >>> >>> Because the optimizations create function clones, which are >trackable with my tool >>> and one knows then all affected functions. >> Okay. I see. >>> >>> You can disable the optimizations, but you'll miss some performance >benefit provide >>> by compiler. >>> >>> Note that as Martin Jambor mentioned in point 2) there are also IPA >optimizations that >>> do not create clones. These should be listed and eventually disabled >for kernel live >>> patching. >> >> Yes, such IPA analyzes should be disabled. we need to identify a >complete list of such analyzes. > >That was promised to be done by Honza Hubička. He's very skilled in IPA >optimizations and he's aware >of optimizations that cause troubles for live-patching. One could also compute the list of possibly affected functions from such semantic changes. Richard. >Martin > >> >> thanks. >> >> Qing >>
