Argument 'p' of monitors_show() is not a pointer to struct rv_monitor, it
is actually a pointer to the list_head inside struct rv_monitor. Therefore
it is wrong to cast 'p' to struct rv_monitor *.

This wrong type cast has been there since the beginning. But it still
worked because the list_head was the first field in struct rv_monitor_def.
This is no longer true since commit 24cbfe18d55a ("rv: Merge struct
rv_monitor_def into struct rv_monitor") moved the list_head, and this wrong
type cast became a functional problem.

Properly use container_of() instead.

Fixes: 24cbfe18d55a ("rv: Merge struct rv_monitor_def into struct rv_monitor")
Signed-off-by: Nam Cao <namcao@linutronix.de>
---
 kernel/trace/rv/rv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/rv/rv.c b/kernel/trace/rv/rv.c
index 2ac0e8bf4e60..1482e91c39f4 100644
--- a/kernel/trace/rv/rv.c
+++ b/kernel/trace/rv/rv.c
@@ -458,7 +458,7 @@ static int create_monitor_dir(struct rv_monitor *mon, struct rv_monitor *parent)
  */
 static int monitors_show(struct seq_file *m, void *p)
 {
-	struct rv_monitor *mon = p;
+	struct rv_monitor *mon = container_of(p, struct rv_monitor, list);
 
 	if (mon->parent)
 		seq_printf(m, "%s:%s\n", mon->parent->name, mon->name);
-- 
2.39.5

On Sun, 2025-07-27 at 19:31 +0200, Nam Cao wrote:
> Argument 'p' of monitors_show() is not a pointer to struct
> rv_monitor, it is actually a pointer to the list_head inside struct
> rv_monitor. Therefore it is wrong to cast 'p' to struct rv_monitor *.
> 
> This wrong type cast has been there since the beginning. But it still
> worked because the list_head was the first field in struct
> rv_monitor_def. This is no longer true since commit 24cbfe18d55a
> ("rv: Merge struct rv_monitor_def into struct rv_monitor") moved the
> list_head, and this wrong type cast became a functional problem.
> 
> Properly use container_of() instead.
> 
> Fixes: 24cbfe18d55a ("rv: Merge struct rv_monitor_def into struct
> rv_monitor")
> Signed-off-by: Nam Cao <namcao@linutronix.de>
> ---
>  kernel/trace/rv/rv.c | 2 +-
> 
> @@ -458,7 +458,7 @@ static int create_monitor_dir(struct rv_monitor
> *mon, struct rv_monitor *parent)
>   */
>  static int monitors_show(struct seq_file *m, void *p)
>  {
> -	struct rv_monitor *mon = p;
> +	struct rv_monitor *mon = container_of(p, struct rv_monitor,
> list);
>  

Good catch, thanks! The container_of is the way to go.
Do you have valid reasons not to move the list_head to the top? It's
not a big deal but it would save computing and summing the offset. It
doesn't seem name (the current first element) really needs to stay
there.

Thanks,
Gabriele

>  	if (mon->parent)
>  		seq_printf(m, "%s:%s\n", mon->parent->name, mon-
> >name);

On Mon, Jul 28, 2025 at 10:59:01AM +0200, Gabriele Monaco wrote:
> Good catch, thanks! The container_of is the way to go.
> Do you have valid reasons not to move the list_head to the top? It's
> not a big deal but it would save computing and summing the offset. It
> doesn't seem name (the current first element) really needs to stay
> there.

I checked x86_64 and riscv64, the generated assembly of this function
before & after moving the list_head on top is almost the same except for
some instructions' intermediate values. Both architectures have
instructions which load data at (pointer + offset), so this offset
computing does not require any extra instruction.

Best regards,
Nam

On Mon, 2025-07-28 at 11:36 +0200, Nam Cao wrote:
> On Mon, Jul 28, 2025 at 10:59:01AM +0200, Gabriele Monaco wrote:
> > Good catch, thanks! The container_of is the way to go.
> > Do you have valid reasons not to move the list_head to the top?
> > It's
> > not a big deal but it would save computing and summing the offset.
> > It
> > doesn't seem name (the current first element) really needs to stay
> > there.
> 
> I checked x86_64 and riscv64, the generated assembly of this function
> before & after moving the list_head on top is almost the same except
> for
> some instructions' intermediate values. Both architectures have
> instructions which load data at (pointer + offset), so this offset
> computing does not require any extra instruction.
> 
> Best regards,
> Nam

Alright then, thanks for checking!

Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>