Signed-off-by: Zhao Lei <[email protected]>
---
kernel/marker.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/marker.c b/kernel/marker.c
index 7d1faec..2c3172d 100644
--- a/kernel/marker.c
+++ b/kernel/marker.c
@@ -836,8 +836,6 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
if (!e->ptype) {
if (num == 0 && e->single.func == probe)
return e->single.probe_private;
- else
- break;
} else {
struct marker_probe_closure *closure;
int match = 0;
@@ -849,6 +847,7 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
return closure[i].probe_private;
}
}
+ break;
}
}
return ERR_PTR(-ENOENT);
--
1.5.5.3
* Zhaolei <[email protected]> wrote:
> Signed-off-by: Zhao Lei <[email protected]>
> ---
> kernel/marker.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/marker.c b/kernel/marker.c
> index 7d1faec..2c3172d 100644
> --- a/kernel/marker.c
> +++ b/kernel/marker.c
> @@ -836,8 +836,6 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
> if (!e->ptype) {
> if (num == 0 && e->single.func == probe)
> return e->single.probe_private;
> - else
> - break;
> } else {
> struct marker_probe_closure *closure;
> int match = 0;
> @@ -849,6 +847,7 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
> return closure[i].probe_private;
> }
> }
> + break;
> }
> }
> return ERR_PTR(-ENOENT);
hm, could you describe the necessity of this patch some more? This has
the change to change behavior, which might even be a bugfix: is there
any chance that the closure-loop in the e->ptype != NULL branch does not
exit? Before your patch we'd continue the iteration - which _probably_
does not lead to any more matches (e->name is supposed to be unique).
Ingo
Ingo Molnar wrote:
> hm, could you describe the necessity of this patch some more? This has
> the change to change behavior, which might even be a bugfix: is there
> any chance that the closure-loop in the e->ptype != NULL branch does not
> exit? Before your patch we'd continue the iteration - which _probably_
> does not lead to any more matches (e->name is supposed to be unique).
Because e->name is unique in list, we don't need to continue the iteration
after matched.
This is a cleanup.
Signed-off-by: Zhao Lei <[email protected]>
---
kernel/marker.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/marker.c b/kernel/marker.c
index 7d1faec..2c3172d 100644
--- a/kernel/marker.c
+++ b/kernel/marker.c
@@ -836,8 +836,6 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
if (!e->ptype) {
if (num == 0 && e->single.func == probe)
return e->single.probe_private;
- else
- break;
} else {
struct marker_probe_closure *closure;
int match = 0;
@@ -849,6 +847,7 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
return closure[i].probe_private;
}
}
+ break;
}
}
return ERR_PTR(-ENOENT);
--
1.5.5.3
* Zhaolei <[email protected]> wrote:
> Ingo Molnar wrote:
> > hm, could you describe the necessity of this patch some more? This has
> > the change to change behavior, which might even be a bugfix: is there
> > any chance that the closure-loop in the e->ptype != NULL branch does not
> > exit? Before your patch we'd continue the iteration - which _probably_
> > does not lead to any more matches (e->name is supposed to be unique).
>
> Because e->name is unique in list, we don't need to continue the iteration
> after matched.
> This is a cleanup.
ok - it's useful to point this out in the changelog. You can use the
"Impact:" header we started using recently:
Impact: cleanup, no functionality changed
See for example this upstream commit:
| commit 07454bfff151d2465ada809bbaddf3548cc1097c
| Author: Thomas Gleixner <[email protected]>
| Date: Sat Oct 4 10:51:07 2008 +0200
|
| clockevents: check broadcast tick device not the clock events device
|
| Impact: jiffies increment too fast.
Mathieu, any objections against the patch?
Ingo
* Ingo Molnar ([email protected]) wrote:
>
> * Zhaolei <[email protected]> wrote:
>
> > Ingo Molnar wrote:
> > > hm, could you describe the necessity of this patch some more? This has
> > > the change to change behavior, which might even be a bugfix: is there
> > > any chance that the closure-loop in the e->ptype != NULL branch does not
> > > exit? Before your patch we'd continue the iteration - which _probably_
> > > does not lead to any more matches (e->name is supposed to be unique).
> >
> > Because e->name is unique in list, we don't need to continue the iteration
> > after matched.
> > This is a cleanup.
>
> ok - it's useful to point this out in the changelog. You can use the
> "Impact:" header we started using recently:
>
> Impact: cleanup, no functionality changed
>
> See for example this upstream commit:
>
> | commit 07454bfff151d2465ada809bbaddf3548cc1097c
> | Author: Thomas Gleixner <[email protected]>
> | Date: Sat Oct 4 10:51:07 2008 +0200
> |
> | clockevents: check broadcast tick device not the clock events device
> |
> | Impact: jiffies increment too fast.
>
> Mathieu, any objections against the patch?
>
> Ingo
It looks all good with an extended changelog.
Acked-by: Mathieu Desnoyers <[email protected]>
Thanks,
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
Because e->name is unique in list, we don't need to continue the iteration
after matched.
Impact: cleanup, no functionality changed
Signed-off-by: Zhao Lei <[email protected]>
---
kernel/marker.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/marker.c b/kernel/marker.c
index e9c6b2b..8b5d253 100644
--- a/kernel/marker.c
+++ b/kernel/marker.c
@@ -848,8 +848,6 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
if (!e->ptype) {
if (num == 0 && e->single.func == probe)
return e->single.probe_private;
- else
- break;
} else {
struct marker_probe_closure *closure;
int match = 0;
@@ -861,6 +859,7 @@ void *marker_get_private_data(const char *name, marker_probe_func *probe,
return closure[i].probe_private;
}
}
+ break;
}
}
return ERR_PTR(-ENOENT);
--
1.5.5.3
* Zhaolei <[email protected]> wrote:
> Because e->name is unique in list, we don't need to continue the iteration
> after matched.
>
> Impact: cleanup, no functionality changed
>
> Signed-off-by: Zhao Lei <[email protected]>
> ---
> kernel/marker.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
applied to tip/tracing/markers, thanks! (also added Mathieu's ack)
Ingo