All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: 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>,
	Petr Mladek <pmladek@suse.com>,
	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: Tue, 26 Jan 2021 15:25:16 +0100	[thread overview]
Message-ID: <YBAmTAsT3S01kU1x@gunter> (raw)
In-Reply-To: <20210121074959.313333-5-hch@lst.de>

+++ 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.

Jessica

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

+++ 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.

Jessica

WARNING: multiple messages have this Message-ID
From: Jessica Yu <jeyu@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Petr Mladek <pmladek@suse.com>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Andrew Donnellan <ajd@linux.ibm.com>,
	linux-kbuild@vger.kernel.org, David Airlie <airlied@linux.ie>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Jiri Kosina <jikos@kernel.org>,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	Michal Marek <michal.lkml@markovi.net>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Frederic Barrat <fbarrat@linux.ibm.com>,
	Miroslav Benes <mbenes@suse.cz>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 04/13] livepatch: move klp_find_object_module to module.c
Date: Tue, 26 Jan 2021 15:25:16 +0100	[thread overview]
Message-ID: <YBAmTAsT3S01kU1x@gunter> (raw)
In-Reply-To: <20210121074959.313333-5-hch@lst.de>

+++ 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.

Jessica
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2021-01-26 14:30 UTC|newest]

Thread overview: 70+ 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 ` Christoph Hellwig
2021-01-21  7:49 ` [PATCH 01/13] powerpc/powernv: remove get_cxl_module Christoph Hellwig
2021-01-21  7:49   ` Christoph Hellwig
2021-01-21  9:09   ` Andrew Donnellan
2021-01-21  9:09     ` Andrew Donnellan
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  7:49   ` Christoph Hellwig
2021-01-21  9:59   ` Christophe Leroy
2021-01-21 10:13     ` David Laight
2021-01-21 10:17       ` Christophe Leroy
2021-01-21 10:00   ` Christophe Leroy
2021-01-21 10:00     ` Christophe Leroy
2021-01-21 17:11     ` Christoph Hellwig
2021-01-21 17:11       ` Christoph Hellwig
2021-01-21 17:44       ` David Laight
2021-01-21 17:44         ` David Laight
2021-01-21 17:44         ` David Laight
2021-01-21  7:49 ` [PATCH 03/13] livepatch: refactor klp_init_object Christoph Hellwig
2021-01-21  7:49   ` Christoph Hellwig
2021-01-27 12:58   ` Petr Mladek
2021-01-27 12:58     ` Petr Mladek
2021-01-27 12:58     ` Petr Mladek
2021-01-28 16:22     ` Christoph Hellwig
2021-01-28 16:22       ` Christoph Hellwig
2021-01-28 16:24       ` 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  7:49   ` Christoph Hellwig
2021-01-21 21:45   ` Josh Poimboeuf
2021-01-21 21:45     ` Josh Poimboeuf
2021-01-21 21:45     ` Josh Poimboeuf
2021-01-26 14:25   ` Jessica Yu [this message]
2021-01-26 14:25     ` Jessica Yu
2021-01-26 14:25     ` Jessica Yu
2021-01-27 11:55     ` Petr Mladek
2021-01-27 11:55       ` Petr Mladek
2021-01-27 11:55       ` Petr Mladek
2021-01-21  7:49 ` [PATCH 05/13] kallsyms: refactor {,module_}kallsyms_on_each_symbol Christoph Hellwig
2021-01-21  7:49   ` 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 06/13] kallsyms: only build {, module_}kallsyms_on_each_symbol " Christoph Hellwig
2021-01-21  7:49 ` [PATCH 07/13] module: mark module_mutex static Christoph Hellwig
2021-01-21  7:49   ` Christoph Hellwig
2021-01-21  7:49 ` [PATCH 08/13] drm: remove drm_fb_helper_modinit Christoph Hellwig
2021-01-21  7:49   ` Christoph Hellwig
2021-01-21  8:25   ` Daniel Vetter
2021-01-21  8:25     ` Daniel Vetter
2021-01-21  8:25     ` Daniel Vetter
2021-01-21  8:28     ` Christoph Hellwig
2021-01-21  8:28       ` Christoph Hellwig
2021-01-21  8:39       ` Daniel Vetter
2021-01-21  8:39         ` Daniel Vetter
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   ` 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   ` 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   ` Christoph Hellwig
2021-01-21  7:49 ` [PATCH 12/13] module: remove EXPORT_SYMBOL_GPL_FUTURE Christoph Hellwig
2021-01-21  7:49   ` Christoph Hellwig
2021-01-21  7:49 ` [PATCH 13/13] module: remove EXPORY_UNUSED_SYMBOL* Christoph Hellwig
2021-01-21  7:49   ` Christoph Hellwig
2021-01-27 13:49   ` Jessica Yu
2021-01-27 13:49     ` Jessica Yu
2021-01-27 13:49     ` Jessica Yu
2021-01-28 16:09     ` Christoph Hellwig
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=YBAmTAsT3S01kU1x@gunter \
    --to=jeyu@kernel.org \
    --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=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=pmladek@suse.com \
    --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 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.