It is advised to use module_name() macro instead of dereferencing mod->name
directly. This makes sense for consistencys sake and also it prevents a
hard dependency to CONFIG_MODULES.
Cc: [email protected]
Cc: Andi Kleen <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: Mark Rutland <[email protected]>,
Cc: Masami Hiramatsu <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Russell King <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
---
I thought that to get things moving it would make sense to fix this low
hanging fruit issue first. Similarly as Masami's fix kernel/kprobes.c
this will make my patch set less rambling, and thus easier to follow.
kernel/trace/trace_kprobe.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index aefb6065b508..19c00ee90945 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -106,9 +106,10 @@ static nokprobe_inline bool trace_kprobe_has_gone(struct trace_kprobe *tk)
static nokprobe_inline bool trace_kprobe_within_module(struct trace_kprobe *tk,
struct module *mod)
{
- int len = strlen(mod->name);
+ int len = strlen(module_name(mod));
const char *name = trace_kprobe_symbol(tk);
- return strncmp(mod->name, name, len) == 0 && name[len] == ':';
+
+ return strncmp(module_name(mod), name, len) == 0 && name[len] == ':';
}
static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
@@ -688,7 +689,7 @@ static int trace_kprobe_module_callback(struct notifier_block *nb,
if (ret)
pr_warn("Failed to re-register probe %s on %s: %d\n",
trace_probe_name(&tk->tp),
- mod->name, ret);
+ module_name(mod), ret);
}
}
mutex_unlock(&event_mutex);
--
2.25.1
On Tue, 18 Aug 2020 08:08:57 +0300
Jarkko Sakkinen <[email protected]> wrote:
> It is advised to use module_name() macro instead of dereferencing mod->name
> directly. This makes sense for consistencys sake and also it prevents a
> hard dependency to CONFIG_MODULES.
>
> Cc: [email protected]
> Cc: Andi Kleen <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Jessica Yu <[email protected]>
> Cc: Mark Rutland <[email protected]>,
> Cc: Masami Hiramatsu <[email protected]>
> Cc: Mike Rapoport <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Will Deacon <[email protected]>
> Signed-off-by: Jarkko Sakkinen <[email protected]>
OK, this looks good to me.
Acked-by: Masami Hiramatsu <[email protected]>
Thank you,
> ---
> I thought that to get things moving it would make sense to fix this low
> hanging fruit issue first. Similarly as Masami's fix kernel/kprobes.c
> this will make my patch set less rambling, and thus easier to follow.
> kernel/trace/trace_kprobe.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index aefb6065b508..19c00ee90945 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -106,9 +106,10 @@ static nokprobe_inline bool trace_kprobe_has_gone(struct trace_kprobe *tk)
> static nokprobe_inline bool trace_kprobe_within_module(struct trace_kprobe *tk,
> struct module *mod)
> {
> - int len = strlen(mod->name);
> + int len = strlen(module_name(mod));
> const char *name = trace_kprobe_symbol(tk);
> - return strncmp(mod->name, name, len) == 0 && name[len] == ':';
> +
> + return strncmp(module_name(mod), name, len) == 0 && name[len] == ':';
> }
>
> static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
> @@ -688,7 +689,7 @@ static int trace_kprobe_module_callback(struct notifier_block *nb,
> if (ret)
> pr_warn("Failed to re-register probe %s on %s: %d\n",
> trace_probe_name(&tk->tp),
> - mod->name, ret);
> + module_name(mod), ret);
> }
> }
> mutex_unlock(&event_mutex);
> --
> 2.25.1
>
--
Masami Hiramatsu <[email protected]>
On Tue, Aug 18, 2020 at 11:49:56PM +0900, Masami Hiramatsu wrote:
> On Tue, 18 Aug 2020 08:08:57 +0300
> Jarkko Sakkinen <[email protected]> wrote:
>
> > It is advised to use module_name() macro instead of dereferencing mod->name
> > directly. This makes sense for consistencys sake and also it prevents a
> > hard dependency to CONFIG_MODULES.
> >
> > Cc: [email protected]
> > Cc: Andi Kleen <[email protected]>
> > Cc: Ard Biesheuvel <[email protected]>
> > Cc: Jessica Yu <[email protected]>
> > Cc: Mark Rutland <[email protected]>,
> > Cc: Masami Hiramatsu <[email protected]>
> > Cc: Mike Rapoport <[email protected]>
> > Cc: Peter Zijlstra <[email protected]>
> > Cc: Russell King <[email protected]>
> > Cc: Will Deacon <[email protected]>
> > Signed-off-by: Jarkko Sakkinen <[email protected]>
>
> OK, this looks good to me.
>
> Acked-by: Masami Hiramatsu <[email protected]>
Great, thank you.
When this might get included to a PR, or at minimum land to linux-next?
Just thinking what to use as the baseline for the next version of my
main series.
BR,
/Jarkko
On Tue, 18 Aug 2020 19:33:56 +0300
Jarkko Sakkinen <[email protected]> wrote:
> > Acked-by: Masami Hiramatsu <[email protected]>
>
> Great, thank you.
>
> When this might get included to a PR, or at minimum land to linux-next?
>
> Just thinking what to use as the baseline for the next version of my
> main series.
I can apply this to my tree along with Masami's latest bootconfig
patches. This will be for linux-next. I don't usually push to
linux-next until around -rc3. Would that be too late?
-- Steve
On Tue, Aug 18, 2020 at 01:00:45PM -0400, Steven Rostedt wrote:
> On Tue, 18 Aug 2020 19:33:56 +0300
> Jarkko Sakkinen <[email protected]> wrote:
>
> > > Acked-by: Masami Hiramatsu <[email protected]>
> >
> > Great, thank you.
> >
> > When this might get included to a PR, or at minimum land to linux-next?
> >
> > Just thinking what to use as the baseline for the next version of my
> > main series.
>
> I can apply this to my tree along with Masami's latest bootconfig
> patches. This will be for linux-next. I don't usually push to
> linux-next until around -rc3. Would that be too late?
>
> -- Steve
Nope. I have piles of stuff to catch before getting to work with this
(because coming back from vacation).
/Jarkko
The following commit has been merged into the perf/core branch of tip:
Commit-ID: e9ffc8c1b83931599663c21ba9082bcafa51d333
Gitweb: https://git.kernel.org/tip/e9ffc8c1b83931599663c21ba9082bcafa51d333
Author: Jarkko Sakkinen <[email protected]>
AuthorDate: Mon, 21 Sep 2020 21:24:25 -04:00
Committer: Peter Zijlstra <[email protected]>
CommitterDate: Thu, 24 Sep 2020 15:55:49 +02:00
kprobes: Use module_name() macro
It is advised to use module_name() macro instead of dereferencing mod->name
directly. This makes sense for consistencys sake and also it prevents a
hard dependency to CONFIG_MODULES.
Signed-off-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
---
kernel/trace/trace_kprobe.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index aefb606..19c00ee 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -106,9 +106,10 @@ static nokprobe_inline bool trace_kprobe_has_gone(struct trace_kprobe *tk)
static nokprobe_inline bool trace_kprobe_within_module(struct trace_kprobe *tk,
struct module *mod)
{
- int len = strlen(mod->name);
+ int len = strlen(module_name(mod));
const char *name = trace_kprobe_symbol(tk);
- return strncmp(mod->name, name, len) == 0 && name[len] == ':';
+
+ return strncmp(module_name(mod), name, len) == 0 && name[len] == ':';
}
static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
@@ -688,7 +689,7 @@ static int trace_kprobe_module_callback(struct notifier_block *nb,
if (ret)
pr_warn("Failed to re-register probe %s on %s: %d\n",
trace_probe_name(&tk->tp),
- mod->name, ret);
+ module_name(mod), ret);
}
}
mutex_unlock(&event_mutex);