All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Miroslav Benes <mbenes@suse.cz>
Cc: linuxppc-dev@ozlabs.org, bsingharora@gmail.com, duwe@lst.de,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	kamalesh@linux.vnet.ibm.com,  pmladek@suse.com, jeyu@redhat.com,
	jikos@kernel.org, live-patching@vger.kernel.org
Subject: Re: [PATCH 2/5] livepatch: Allow architectures to specify an alternate ftrace location
Date: Thu, 14 Apr 2016 23:06:18 +1000	[thread overview]
Message-ID: <1460639178.21066.3.camel@ellerman.id.au> (raw)
In-Reply-To: <alpine.LNX.2.00.1604141354130.10605@pobox.suse.cz>

On Thu, 2016-04-14 at 14:01 +0200, Miroslav Benes wrote:
> On Wed, 13 Apr 2016, Michael Ellerman wrote:
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index d68fbf63b083..b0476bb30f92 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -298,6 +298,19 @@ unlock:
> >       rcu_read_unlock();
> >  }
> >  
> > +/*
> > + * Convert a function address into the appropriate ftrace location.
> > + *
> > + * Usually this is just the address of the function, but on some architectures
> > + * it's more complicated so allow them to provide a custom behaviour.
> > + */
> > +#ifndef klp_get_ftrace_location
> > +static unsigned long klp_get_ftrace_location(unsigned long faddr)
> > +{
> > +     return faddr;
> > +}
> > +#endif
> 
> Whoah, what an ugly hack :)
 
Hey it's a "cool trick" ;)

> Note to my future self - This is what you want to do if you need a weak 
> static inline function.
> 
> static inline is probably unnecessary here so __weak function would be 
> enough. It would introduce powerpc-specific livepatch.c though because of 
> it and this is not worth it.

Yeah that was my logic, at least for now. We can always change it in future
to be weak if anyone cares deeply.

> >  static void klp_disable_func(struct klp_func *func)
> >  {
> >       struct klp_ops *ops;
> > @@ -312,8 +325,14 @@ static void klp_disable_func(struct klp_func *func)
> >               return;
> >  
> >       if (list_is_singular(&ops->func_stack)) {
> > +             unsigned long ftrace_loc;
> 
> This is a nit, but could you move the definition up to have them all in 
> one place to be consistent with the rest of the code? The same applies to 
> klp_enable_func() below.

Hmm, actually I moved it in there because you pointed out we only needed it
inside the if:

http://lkml.kernel.org/r/alpine.LNX.2.00.1603151113020.20252@pobox.suse.cz

    Thinking about it, we need ftrace_loc only in cases where we call 
    ftrace_set_filter_ip() right? So we can move klp_get_ftrace_location() 
    call to appropriate if branch both in klp_disable_func() and 
    klp_enable_func().

But I guess you meant the function call, not the variable declaration.

Personally I think it's better this way, as the variable is in scope for the
shortest possible amount of time, but I can change it if you want me to.

cheers

  reply	other threads:[~2016-04-14 13:06 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 12:53 [PATCH 0/5] Live patching for powerpc Michael Ellerman
2016-04-13 12:53 ` [PATCH 1/5] ftrace: Make ftrace_location_range() global Michael Ellerman
2016-04-19 10:16   ` [1/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 2/5] livepatch: Allow architectures to specify an alternate ftrace location Michael Ellerman
2016-04-14 12:01   ` Miroslav Benes
2016-04-14 13:06     ` Michael Ellerman [this message]
2016-04-14 14:06       ` Miroslav Benes
2016-04-19 10:16   ` [2/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 3/5] powerpc/livepatch: Add livepatch header Michael Ellerman
2016-04-14 12:18   ` Miroslav Benes
2016-04-14 12:23     ` Miroslav Benes
2016-04-14 13:12       ` Michael Ellerman
2016-04-19 10:16   ` [3/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 4/5] powerpc/livepatch: Add livepatch stack to struct thread_info Michael Ellerman
2016-04-19 10:16   ` [4/5] " Michael Ellerman
2016-04-13 12:53 ` [PATCH 5/5] powerpc/livepatch: Add live patching support on ppc64le Michael Ellerman
2016-04-19 10:16   ` [5/5] " Michael Ellerman
2016-04-13 13:01 ` [PATCH 0/5] Live patching for powerpc Miroslav Benes
2016-04-13 13:22   ` Jiri Kosina
2016-04-14  6:49     ` Michael Ellerman
2016-04-14 12:57       ` Torsten Duwe
2016-04-14 13:08         ` Michael Ellerman
2016-04-14 15:20           ` Torsten Duwe
2016-04-14 16:41             ` Josh Poimboeuf
2016-04-15 11:22               ` Michael Ellerman
2016-04-15 12:59                 ` Josh Poimboeuf
2016-04-15 13:21                   ` Michael Ellerman
2016-04-14 14:34         ` Jiri Kosina
2016-04-15 12:24           ` Michael Ellerman
2016-04-15 15:07       ` Jiri Kosina
2016-04-19 21:42         ` Balbir Singh
2016-04-19 21:52           ` Jiri Kosina
2016-04-13 18:22   ` Jessica Yu
2016-04-14 13:28     ` Miroslav Benes
2016-04-14 19:20       ` Jessica Yu
2016-04-15  8:28         ` Miroslav Benes
2016-04-15 10:01           ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1460639178.21066.3.camel@ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=bsingharora@gmail.com \
    --cc=duwe@lst.de \
    --cc=jeyu@redhat.com \
    --cc=jikos@kernel.org \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.