Delayed kobject debugging (CONFIG_DEBUG_KOBJECT_RELEASE) prints the
kobject pointer that's being released in kobject_release() before
scheduling a randomly delayed work to do the actual release work. If the
caller of kobject_put() frees the kobject upon return then we'll
typically see a debugobject warning about freeing an active timer.
Usually the release function is the function that does the kfree() of
the struct containing the kobject.
For example the following print is seen
kobject: 'queue' (ffff888114236190): kobject_release, parent 0000000000000000 (delayed 1000)
------------[ cut here ]------------
ODEBUG: free active (active state 0) object type: timer_list hint: kobject_delayed_cleanup+0x0/0x390
but we can't match up the kobject printk with the debug object printk
because it could be any number of kobjects that was released around that
time. The random delay for the work doesn't help either.
Print the address of the object being tracked to help us figure out
which kobject is the problem here. Note that we don't use %px here to
match the other %p usage in debugobject debugging. Due to %p usage we'll
have to disable pointer hashing to correlate the two pointer printks.
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
---
lib/debugobjects.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 6946f8e204e3..a1c987e967e0 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -503,9 +503,9 @@ static void debug_print_object(struct debug_obj *obj, char *msg)
descr->debug_hint(obj->object) : NULL;
limit++;
WARN(1, KERN_ERR "ODEBUG: %s %s (active state %u) "
- "object type: %s hint: %pS\n",
+ "object: %p object type: %s hint: %pS\n",
msg, obj_states[obj->state], obj->astate,
- descr->name, hint);
+ obj->object, descr->name, hint);
}
debug_objects_warnings++;
}
base-commit: ffb217a13a2eaf6d5bd974fc83036a53ca69f1e2
--
https://chromeos.dev
On Thu, May 19, 2022 at 01:22:01PM -0700, Stephen Boyd wrote:
> Delayed kobject debugging (CONFIG_DEBUG_KOBJECT_RELEASE) prints the
> kobject pointer that's being released in kobject_release() before
> scheduling a randomly delayed work to do the actual release work. If the
> caller of kobject_put() frees the kobject upon return then we'll
> typically see a debugobject warning about freeing an active timer.
> Usually the release function is the function that does the kfree() of
> the struct containing the kobject.
>
> For example the following print is seen
>
> kobject: 'queue' (ffff888114236190): kobject_release, parent 0000000000000000 (delayed 1000)
> ------------[ cut here ]------------
> ODEBUG: free active (active state 0) object type: timer_list hint: kobject_delayed_cleanup+0x0/0x390
>
> but we can't match up the kobject printk with the debug object printk
> because it could be any number of kobjects that was released around that
> time. The random delay for the work doesn't help either.
>
> Print the address of the object being tracked to help us figure out
> which kobject is the problem here. Note that we don't use %px here to
> match the other %p usage in debugobject debugging. Due to %p usage we'll
> have to disable pointer hashing to correlate the two pointer printks.
>
> Cc: Guenter Roeck <[email protected]>
> Signed-off-by: Stephen Boyd <[email protected]>
Did this patch get lost, or was it rejected ? I don't see a reply,
and it has not been applied.
FWIW:
Reviewed-by: Guenter Roeck <[email protected]>
Thanks,
Guenter
> ---
> lib/debugobjects.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index 6946f8e204e3..a1c987e967e0 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -503,9 +503,9 @@ static void debug_print_object(struct debug_obj *obj, char *msg)
> descr->debug_hint(obj->object) : NULL;
> limit++;
> WARN(1, KERN_ERR "ODEBUG: %s %s (active state %u) "
> - "object type: %s hint: %pS\n",
> + "object: %p object type: %s hint: %pS\n",
> msg, obj_states[obj->state], obj->astate,
> - descr->name, hint);
> + obj->object, descr->name, hint);
> }
> debug_objects_warnings++;
> }
>
> base-commit: ffb217a13a2eaf6d5bd974fc83036a53ca69f1e2
> --
> https://chromeos.dev
>
On Tue, Oct 04 2022 at 15:58, Guenter Roeck wrote:
>> Signed-off-by: Stephen Boyd <[email protected]>
>
> Did this patch get lost, or was it rejected ? I don't see a reply,
> and it has not been applied.
It fell through the cracks. /me adds to pile...
The following commit has been merged into the core/debugobjects branch of tip:
Commit-ID: c4db2d3b70e586c7c856c891f4f7052e8d789a06
Gitweb: https://git.kernel.org/tip/c4db2d3b70e586c7c856c891f4f7052e8d789a06
Author: Stephen Boyd <[email protected]>
AuthorDate: Thu, 19 May 2022 13:22:01 -07:00
Committer: Thomas Gleixner <[email protected]>
CommitterDate: Fri, 02 Dec 2022 12:32:24 +01:00
debugobjects: Print object pointer in debug_print_object()
Delayed kobject debugging (CONFIG_DEBUG_KOBJECT_RELEASE) prints the kobject
pointer that's being released in kobject_release() before scheduling a
randomly delayed work to do the actual release work.
If the caller of kobject_put() frees the kobject upon return then this will
typically emit a debugobject warning about freeing an active timer.
Usually the release function is the function that does the kfree() of the
struct containing the kobject.
For example the following print is seen
kobject: 'queue' (ffff888114236190): kobject_release, parent 0000000000000000 (delayed 1000)
------------[ cut here ]------------
ODEBUG: free active (active state 0) object type: timer_list hint: kobject_delayed_cleanup+0x0/0x390
but the kobject printk cannot be matched with the debug object printk
because it could be any number of kobjects that was released around that
time. The random delay for the work doesn't help either.
Print the address of the object being tracked to help to figure out which
kobject is the problem here. Note that this does not use %px here to match
the other %p usage in debugobject debugging. Due to %p usage it is required
to disable pointer hashing to correlate the two pointer printks.
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
lib/debugobjects.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 337d797..4c670d3 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -500,9 +500,9 @@ static void debug_print_object(struct debug_obj *obj, char *msg)
descr->debug_hint(obj->object) : NULL;
limit++;
WARN(1, KERN_ERR "ODEBUG: %s %s (active state %u) "
- "object type: %s hint: %pS\n",
+ "object: %p object type: %s hint: %pS\n",
msg, obj_states[obj->state], obj->astate,
- descr->name, hint);
+ obj->object, descr->name, hint);
}
debug_objects_warnings++;
}