From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Jason Baron <jbaron@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>,
rusty@rustcorp.co.au, rostedt@goodmis.com,
linux-kernel@vger.kernel.org, mingo@elte.hu, hpa@zytor.com,
tglx@linutronix.de, roland@redhat.com, rth@redhat.com,
mhiramat@redhat.com, fweisbec@gmail.com, avi@redhat.com,
davem@davemloft.net, vgoyal@redhat.com, sam@ravnborg.org,
tony@bakeyournoodle.com, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 2/2] Rewrite jump_label.c to use binary search
Date: Wed, 22 Sep 2010 15:19:36 -0400 [thread overview]
Message-ID: <20100922191936.GA28463@Krystal> (raw)
In-Reply-To: <20100922152833.GD2816@redhat.com>
* Jason Baron (jbaron@redhat.com) wrote:
> On Wed, Sep 22, 2010 at 11:02:50AM -0400, Mathieu Desnoyers wrote:
> > * Andi Kleen (andi@firstfloor.org) wrote:
> > >
> > > >
> > > >>> + for (; entry < stop && entry->key == key; entry++)
> > > >>> + if (kernel_text_address(entry->code))
> > > >>
> > > >> This does not work for modules I'm afraid, only for the core kernel. You
> > > >> should test for __module_text_address() somewhere.
> > > >
> > > > I thought it was shared now, but ok.
> > >
> > > Double checked. This is ok because kernel_text_address()
> > > already checks for modules. You were probably thinking
> > > of __kernel_text_address()
> >
> > Ah right,
> >
> > Although we have another problem:
> >
> > __module_text_address() includes module init text, which defeats the
> > purpose of the check put in there by Jason.
> >
> > So the check works for the core kernel, but not for modules.
> >
> > Mathieu
> >
>
> it works for modules too...it does:
>
> struct module *__module_text_address(unsigned long addr)
> {
> struct module *mod = __module_address(addr);
> if (mod) {
> /* Make sure it's within the text section. */
> if (!within(addr, mod->module_init, mod->init_text_size)
> && !within(addr, mod->module_core,
> mod->core_text_size))
> mod = NULL;
> }
> return mod;
> }
>
> and then in kernel/module.c we have :
>
>
> module_free(mod, mod->module_init);
> mod->module_init = NULL;
>
>
> So, I was relying on the fact module_init gets set to NULL after the
> free happens. However, there a small race there in that the vfree()
> happens before module_init() is set to NULL. So that is probably most
> easily fixed be wrapping those two lines with the jump_label_mutex.
It's both module_init = NULL _and_ init_text_size = 0 that make sure
the test "within(addr, mod->module_init, mod->init_text_size)" is valid.
Just the "module_init = NULL" can cause problems with addresses in the
low range of kernel addresses. With a long enough module init section,
the offset from NULL can end up (temporarily) in the kernel address
range.
But this is all wrong: __module_text_address is relying on
preempt_disable() to ensure coherency of this test is just racy, as you
point out above. So we either do the RCU synchronization properly, or
hold the module_mutex around the module text address test _and_ actual
access to the module init section.
Thanks,
Mathieu
>
> thanks,
>
> -Jason
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2010-09-22 19:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-22 10:08 [PATCH 1/2] Add for_each_module iterator function Andi Kleen
2010-09-22 10:08 ` [PATCH 2/2] Rewrite jump_label.c to use binary search Andi Kleen
2010-09-22 11:31 ` Mathieu Desnoyers
2010-09-22 11:56 ` Andi Kleen
2010-09-22 12:04 ` Andi Kleen
2010-09-22 15:02 ` Mathieu Desnoyers
2010-09-22 15:07 ` Mathieu Desnoyers
2010-09-22 15:43 ` Jason Baron
2010-09-22 15:28 ` Jason Baron
2010-09-22 19:19 ` Mathieu Desnoyers [this message]
2010-09-22 13:46 ` Jason Baron
2010-09-22 18:14 ` Jason Baron
2010-09-22 11:57 ` Frederic Weisbecker
2010-09-22 16:12 ` H. Peter Anvin
2010-09-22 19:43 ` Mathieu Desnoyers
2010-09-22 20:06 ` H. Peter Anvin
2010-09-22 20:41 ` Mathieu Desnoyers
2010-09-22 20:54 ` H. Peter Anvin
2010-09-22 12:25 ` [PATCH 1/2] Add for_each_module iterator function Thomas Gleixner
2010-09-22 12:52 ` Andi Kleen
2010-09-22 14:03 ` Mathieu Desnoyers
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=20100922191936.GA28463@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=avi@redhat.com \
--cc=davem@davemloft.net \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.com \
--cc=rth@redhat.com \
--cc=rusty@rustcorp.co.au \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=tony@bakeyournoodle.com \
--cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox