Messages in this thread | | | Date | Thu, 1 May 2014 22:37:47 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [RFC 03/16] kgr: initial code |
| |
On Thu, 1 May 2014, Andi Kleen wrote:
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S > > index 1e96c3628bf2..a03b1e9d2de3 100644 > > --- a/arch/x86/kernel/entry_64.S > > +++ b/arch/x86/kernel/entry_64.S > > @@ -615,6 +615,7 @@ GLOBAL(system_call_after_swapgs) > > movq %rax,ORIG_RAX-ARGOFFSET(%rsp) > > movq %rcx,RIP-ARGOFFSET(%rsp) > > CFI_REL_OFFSET rip,RIP-ARGOFFSET > > + movw $0, TI_kgr_in_progress+THREAD_INFO(%rsp,RIP-ARGOFFSET) > > Better use 4 bytes. This has the potential to cause an expensive > Length Changing Prefixes Stall on Intel CPUs.
Patch 16/16 converts this to a single bit within TI_flags.
> > +static int kgr_init_ftrace_ops(const struct kgr_patch_fun *patch_fun) > > +{ > > + struct kgr_loc_caches *caches; > > + unsigned long fentry_loc; > > + > > + /* > > + * Initialize the ftrace_ops->private with pointers to the fentry > > + * sites of both old and new functions. This is used as a > > + * redirection target in the per-arch stubs. > > + * > > + * Beware! -- freeing (once unloading will be implemented) > > + * will require synchronize_sched() etc. > > + */ > > + > > + caches = kmalloc(sizeof(*caches), GFP_KERNEL); > > + if (!caches) { > > + kgr_debug("kgr: unable to allocate fentry caches\n"); > > + return -ENOMEM; > > + } > > All the error paths in this function leak memory.
Gah, good catch, thanks a lot.
-- Jiri Kosina SUSE Labs
| |