From: Petr Mladek <pmladek@suse.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Jessica Yu <jeyu@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Seth Jennings <sjenning@redhat.com>,
Vojtech Pavlik <vojtech@suse.com>,
Jonathan Corbet <corbet@lwn.net>, Miroslav Benes <mbenes@suse.cz>,
linux-api@vger.kernel.org, live-patching@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [RFC PATCH v4 2/6] module: preserve Elf information for livepatch modules
Date: Tue, 9 Feb 2016 13:31:48 +0100 [thread overview]
Message-ID: <20160209123148.GB12548@pathway.suse.cz> (raw)
In-Reply-To: <alpine.LNX.2.00.1602091131510.22727@cbobk.fhfr.pm>
On Tue 2016-02-09 11:33:07, Jiri Kosina wrote:
> On Tue, 9 Feb 2016, Petr Mladek wrote:
>
> > > +#ifdef CONFIG_KALLSYMS
> > > + /* Make symtab and strtab available prior to module init call */
> > > + mod->num_symtab = mod->core_num_syms;
> > > + mod->symtab = mod->core_symtab;
> > > + mod->strtab = mod->core_strtab;
> > > +#endif
> >
> > This should be done with module_mutex. Otherwise, it looks racy at least
> > against module_kallsyms_on_each_symbol().
>
> Hmm, if this is the case, the comment describing the locking rules for
> module_mutex should be updated.
>
> > BTW: I wonder why even the original code is not racy for example against
> > module_get_kallsym. It is called without the mutex. This code sets the
> > number of entries before the pointer to the entries.
> >
> > Note that the module is in the list even in the UNFORMED state.
>
> module_kallsyms_on_each_symbol() gives up in such case though.
The problem is that we set the three values above in the COMMING
state. They were even set in the LIVE state before this patch.
IMHO, we should reorder the writes and add a write barrier.
#ifdef CONFIG_KALLSYMS
/* Make symtab and strtab available prior to module init call */
mod->strtab = mod->core_strtab;
mod->symtab = mod->core_symtab;
/* Tables must be availabe before the number is set */
smp_wmb();
mod->num_symtab = mod->core_num_syms;
#endif
Then we should add the corresponding read barrier to
the read functions that are protected only by
the disabled preeption. For example:
static unsigned long mod_find_symname(struct module *mod, const char *name)
{
unsigned int i;
for (i = 0; i < mod->num_symtab; i++)
/* Make sure that tables are set for the read num_symtab */
smp_rmb();
if (strcmp(name, mod->strtab+mod->symtab[i].st_name) == 0 &&
mod->symtab[i].st_info != 'U')
return mod->symtab[i].st_value;
return 0;
}
Or am I too paranoid, please?
Best Regards,
Petr
next prev parent reply other threads:[~2016-02-09 12:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 1:11 [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-02-04 1:11 ` [RFC PATCH v4 1/6] Elf: add livepatch-specific Elf constants Jessica Yu
2016-02-04 1:11 ` [RFC PATCH v4 2/6] module: preserve Elf information for livepatch modules Jessica Yu
2016-02-08 20:10 ` Josh Poimboeuf
2016-02-08 20:34 ` Jessica Yu
2016-02-09 8:44 ` [RFC PATCH v4 2/6] " Petr Mladek
2016-02-09 10:33 ` Jiri Kosina
2016-02-09 12:31 ` Petr Mladek [this message]
2016-02-10 0:18 ` Rusty Russell
2016-02-10 15:53 ` Petr Mladek
2016-02-04 1:11 ` [RFC PATCH v4 3/6] module: s390: keep mod_arch_specific " Jessica Yu
2016-02-04 1:37 ` Jessica Yu
2016-02-04 21:03 ` Josh Poimboeuf
2016-02-05 15:32 ` Miroslav Benes
2016-02-04 1:11 ` [RFC PATCH v4 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2016-02-08 15:05 ` Miroslav Benes
2016-02-09 13:32 ` Miroslav Benes
2016-02-08 20:26 ` Josh Poimboeuf
2016-02-10 0:56 ` Jessica Yu
2016-02-09 14:01 ` [RFC PATCH v4 4/6] " Petr Mladek
2016-02-09 15:57 ` Miroslav Benes
2016-02-10 1:21 ` Jessica Yu
2016-02-04 1:11 ` [RFC PATCH v4 5/6] samples: livepatch: mark as livepatch module Jessica Yu
2016-02-04 1:11 ` [RFC PATCH v4 6/6] Documentation: livepatch: outline Elf format and requirements for patch modules Jessica Yu
2016-02-08 14:54 ` [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch Miroslav Benes
2016-02-08 20:28 ` Josh Poimboeuf
2016-02-09 15:56 ` Petr Mladek
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=20160209123148.GB12548@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=corbet@lwn.net \
--cc=jeyu@redhat.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=rusty@rustcorp.com.au \
--cc=sjenning@redhat.com \
--cc=vojtech@suse.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®