All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@redhat.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"David S. Miller" <davem@davemloft.net>,
	David Daney <david.daney@cavium.com>,
	Michael Ellerman <michael@ellerman.id.au>,
	Jan Glauber <jang@linux.vnet.ibm.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH RFC V2 3/5] jump_label: if a key has already been initialized, don't nop it out
Date: Mon, 10 Oct 2011 16:10:28 -0400	[thread overview]
Message-ID: <20111010201027.GC2413@redhat.com> (raw)
In-Reply-To: <4E934E5B.3000603@goop.org>

On Mon, Oct 10, 2011 at 12:58:19PM -0700, Jeremy Fitzhardinge wrote:
> > Hi,
> >
> > I just realized that the early call to jump_label_inc(), isn't being
> > honored with this patch until later when we invoke jump_label_init().
> > That strikes me as being inconsistent. When jump_label_inc() returns we
> > should expect the branch to be updated.
> 
> Why is that?  It looks to me like it will unconditionally update the
> instruction, irrespective of whether _init() has been called?
> 

No. jump_label_init(), sets up key->entries, to point into the jump
table...before that jump_label_update(), doesn't know where the table is
located, and will just return, without doing the update.


> > Thus, I think what probably want is to add a new 'int jump_label_init'
> > flag. If its not set we can call 'jump_label_init()' from
> > jump_label_inc()/dec().
> 
> Hm.  I worry that it may end up calling jump_label_init() in an
> unexpected context, especially since it may well be config-dependent, or
> adding a jump_label_inc() later on starts mysteriously failing.

good point.

> 
> >  And jump_label_init() can avoid initialization
> > if its already set.
> 
> That doesn't seem worthwhile in itself.  I suspect the number of "early"
> jump_label_incs will be very small (or we should look at doing the init
> earlier).
> 
>     J

I have it as 'early_initcall()', but perhaps it should be moved into
init/main.c. I don't think there's any reason it can't be done super
early. So I think this might be the best answer. It will also simplify
your series.

Thanks,

-Jason

  reply	other threads:[~2011-10-10 20:10 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-01 21:55 [PATCH RFC V2 0/5] jump-label: allow early jump_label_enable() Jeremy Fitzhardinge
2011-10-01 21:55 ` [PATCH RFC V2 1/5] jump_label: use proper atomic_t initializer Jeremy Fitzhardinge
2011-10-01 21:55   ` Jeremy Fitzhardinge
2011-10-01 21:55 ` [PATCH RFC V2 2/5] stop_machine: make stop_machine safe and efficient to call early Jeremy Fitzhardinge
2011-10-02  0:36   ` Tejun Heo
2011-10-03 19:24   ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-10-03 19:24     ` Konrad Rzeszutek Wilk
2011-10-01 21:55 ` [PATCH RFC V2 3/5] jump_label: if a key has already been initialized, don't nop it out Jeremy Fitzhardinge
2011-10-03 15:02   ` Jason Baron
2011-10-03 15:47     ` Steven Rostedt
2011-10-03 16:27     ` Jeremy Fitzhardinge
2011-10-04 14:10       ` Jason Baron
2011-10-04 15:18         ` Jeremy Fitzhardinge
2011-10-04 16:30         ` H. Peter Anvin
2011-10-04 16:30           ` H. Peter Anvin
2011-10-04 17:53           ` Jason Baron
2011-10-04 18:05             ` Steven Rostedt
2011-10-06  0:16           ` Jeremy Fitzhardinge
2011-10-06  0:17             ` H. Peter Anvin
2011-10-06  0:47               ` Jeremy Fitzhardinge
2011-10-06 17:53               ` Jeremy Fitzhardinge
2011-10-06 18:10                 ` Jason Baron
2011-10-06 18:13                   ` H. Peter Anvin
2011-10-06 21:39                     ` Jeremy Fitzhardinge
2011-10-06 22:08                       ` Steven Rostedt
2011-10-06 18:15                   ` Jeremy Fitzhardinge
2011-10-06 18:33                     ` Jason Baron
2011-10-06 18:35                       ` H. Peter Anvin
2011-10-06 18:43                         ` Jason Baron
2011-10-06 18:26                   ` Steven Rostedt
2011-10-06 18:29                     ` H. Peter Anvin
2011-10-06 18:29                       ` H. Peter Anvin
2011-10-06 18:38                       ` Jason Baron
2011-10-06 19:34                         ` Steven Rostedt
2011-10-06 20:33                           ` Jason Baron
2011-10-06 20:45                             ` Steven Rostedt
2011-10-06 18:50                     ` Richard Henderson
2011-10-06 19:28                       ` Steven Rostedt
2011-10-06 21:42                         ` Jeremy Fitzhardinge
2011-10-06 22:06                           ` Steven Rostedt
2011-10-06 22:10                             ` Jeremy Fitzhardinge
2011-10-06 22:20                               ` Steven Rostedt
2011-10-07 17:09                               ` [PATCH][RFC] jump_labels/x86: Use either 5 byte or 2 byte jumps Steven Rostedt
2011-10-07 18:52                                 ` Jason Baron
2011-10-07 19:21                                   ` Steven Rostedt
2011-10-07 21:48                                     ` H. Peter Anvin
2011-10-07 22:00                                       ` Steven Rostedt
2011-10-07 22:03                                         ` H. Peter Anvin
2011-10-07 19:33                                   ` Steven Rostedt
2011-10-07 19:40                                 ` Jeremy Fitzhardinge
2011-10-07 19:58                                   ` Steven Rostedt
2011-10-07 20:04                                   ` Peter Zijlstra
2011-10-10 15:36   ` [PATCH RFC V2 3/5] jump_label: if a key has already been initialized, don't nop it out Jason Baron
2011-10-10 19:58     ` Jeremy Fitzhardinge
2011-10-10 20:10       ` Jason Baron [this message]
2011-10-01 21:55 ` [PATCH RFC V2 4/5] x86/jump_label: drop arch_jump_label_text_poke_early() Jeremy Fitzhardinge
2011-10-01 21:55 ` [PATCH RFC V2 5/5] sparc/jump_label: " Jeremy Fitzhardinge

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=20111010201027.GC2413@redhat.com \
    --to=jbaron@redhat.com \
    --cc=davem@davemloft.net \
    --cc=david.daney@cavium.com \
    --cc=jang@linux.vnet.ibm.com \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@ellerman.id.au \
    --cc=rostedt@goodmis.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /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.