live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Jessica Yu <jeyu@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Frederic Barrat <fbarrat@linux.ibm.com>,
	Andrew Donnellan <ajd@linux.ibm.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	dri-devel@lists.freedesktop.org, live-patching@vger.kernel.org,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 04/13] livepatch: move klp_find_object_module to module.c
Date: Wed, 27 Jan 2021 12:55:13 +0100	[thread overview]
Message-ID: <YBFUoYxHjRTmKOEn@alley> (raw)
In-Reply-To: <YBAmTAsT3S01kU1x@gunter>

On Tue 2021-01-26 15:25:16, Jessica Yu wrote:
> +++ Christoph Hellwig [21/01/21 08:49 +0100]:
> > To uncouple the livepatch code from module loader internals move a
> > slightly refactored version of klp_find_object_module to module.c
> > This allows to mark find_module static and removes one of the last
> > users of module_mutex outside of module.c.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > include/linux/module.h  |  3 +--
> > kernel/livepatch/core.c | 39 +++++++++++++--------------------------
> > kernel/module.c         | 17 ++++++++++++++++-
> > 3 files changed, 30 insertions(+), 29 deletions(-)
> > 
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index b4654f8a408134..8588482bde4116 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -586,8 +586,7 @@ static inline bool within_module(unsigned long addr, const struct module *mod)
> > 	return within_module_init(addr, mod) || within_module_core(addr, mod);
> > }
> > 
> > -/* Search for module by name: must hold module_mutex. */
> > -struct module *find_module(const char *name);
> > +struct module *find_klp_module(const char *name);
> > 
> > /* Check if a module is loaded. */
> > bool module_loaded(const char *name);
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index a7f625dc24add3..878759baadd81c 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -49,30 +49,6 @@ static bool klp_is_module(struct klp_object *obj)
> > 	return obj->name;
> > }
> > 
> > -/* sets obj->mod if object is not vmlinux and module is found */
> > -static void klp_find_object_module(struct klp_object *obj)
> > -{
> > -	struct module *mod;
> > -
> > -	mutex_lock(&module_mutex);
> > -	/*
> > -	 * We do not want to block removal of patched modules and therefore
> > -	 * we do not take a reference here. The patches are removed by
> > -	 * klp_module_going() instead.
> > -	 */
> > -	mod = find_module(obj->name);
> > -	/*
> > -	 * Do not mess work of klp_module_coming() and klp_module_going().
> > -	 * Note that the patch might still be needed before klp_module_going()
> > -	 * is called. Module functions can be called even in the GOING state
> > -	 * until mod->exit() finishes. This is especially important for
> > -	 * patches that modify semantic of the functions.
> > -	 */
> > -	if (mod && mod->klp_alive)
> > -		obj->mod = mod;
> > -	mutex_unlock(&module_mutex);
> > -}
> 
> Hmm, I am not a huge fan of moving more livepatch code into module.c, I
> wonder if we can keep them separate.
> 
> Why not have module_is_loaded() kill two birds with one stone? That
> is, just have it return a module pointer to signify that the module is
> loaded, NULL if not. Then we don't need an extra find_klp_module()
> function just to call find_module() and return a pointer, as
> module_is_loaded() can just do that for us.
> 
> As for the mod->klp_alive check, I believe this function
> (klp_find_object_module()) is called with klp_mutex held, and
> mod->klp_alive is only modified under klp_mutex. Also, if klp_alive is
> true, the module is at least COMING and cannot be GOING until it
> acquires the klp_mutex again in klp_module_going(). So does that hunk
> really need to be under module_mutex? It has been a long time since
> I've looked at livepatch code so it would be great if someone could
> double check.

We need to make sure that the module is not freed before we manipulate
mod->klp_alive.

One solution would be to take the reference and block it during this
operation.

Alternatively it might be to rely on RCU. It seems that the struct
is protected by RCU because of kallsyms. But I am not sure if it
is safe in all module states. But it should be. We find the module
via the same list like kallsyms.

Best Regards,
Petr

  reply	other threads:[~2021-01-27 11:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  7:49 module loader dead code removal and cleanusp Christoph Hellwig
2021-01-21  7:49 ` [PATCH 01/13] powerpc/powernv: remove get_cxl_module Christoph Hellwig
2021-01-21  9:09   ` Andrew Donnellan
2021-01-21  7:49 ` [PATCH 02/13] module: add a module_loaded helper Christoph Hellwig
2021-01-21 10:00   ` Christophe Leroy
2021-01-21 17:11     ` Christoph Hellwig
2021-01-21 17:44       ` David Laight
2021-01-21  7:49 ` [PATCH 03/13] livepatch: refactor klp_init_object Christoph Hellwig
2021-01-27 12:58   ` Petr Mladek
2021-01-28 16:22     ` Christoph Hellwig
2021-01-28 16:24       ` Christoph Hellwig
2021-01-21  7:49 ` [PATCH 04/13] livepatch: move klp_find_object_module to module.c Christoph Hellwig
2021-01-21 21:45   ` Josh Poimboeuf
2021-01-26 14:25   ` Jessica Yu
2021-01-27 11:55     ` Petr Mladek [this message]
2021-01-21  7:49 ` [PATCH 05/13] kallsyms: refactor {,module_}kallsyms_on_each_symbol Christoph Hellwig
2021-01-21  7:49 ` [PATCH 06/13] kallsyms: only build {,module_}kallsyms_on_each_symbol when required Christoph Hellwig
2021-01-21  7:49 ` [PATCH 07/13] module: mark module_mutex static Christoph Hellwig
2021-01-21  7:49 ` [PATCH 08/13] drm: remove drm_fb_helper_modinit Christoph Hellwig
2021-01-21  8:25   ` Daniel Vetter
2021-01-21  8:28     ` Christoph Hellwig
2021-01-21  8:39       ` Daniel Vetter
2021-01-21  7:49 ` [PATCH 09/13] module: remove each_symbol_in_section Christoph Hellwig
2021-01-21  7:49 ` [PATCH 10/13] module: merge each_symbol_section into find_symbol Christoph Hellwig
2021-01-21  7:49 ` [PATCH 11/13] module: pass struct find_symbol_args to find_symbol Christoph Hellwig
2021-01-21  7:49 ` [PATCH 12/13] module: remove EXPORT_SYMBOL_GPL_FUTURE Christoph Hellwig
2021-01-21  7:49 ` [PATCH 13/13] module: remove EXPORY_UNUSED_SYMBOL* Christoph Hellwig
2021-01-27 13:49   ` Jessica Yu
2021-01-28 16:09     ` Christoph Hellwig

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=YBFUoYxHjRTmKOEn@alley \
    --to=pmladek@suse.com \
    --cc=airlied@linux.ie \
    --cc=ajd@linux.ibm.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fbarrat@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=masahiroy@kernel.org \
    --cc=mbenes@suse.cz \
    --cc=michal.lkml@markovi.net \
    --cc=mripard@kernel.org \
    --cc=tzimmermann@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).