On 2/28/23 00:13, Andy Shevchenko wrote:
Hi, Andy!
The logs are extensive if you are willing to skim over them, but I believe the interesting
part is this:
I'm not sure I understand where the problem is.
[ 4830.764748] kobject: 'gpio-sim' (000000005b8d0726): kobject_release, parent 000000007425b13f (delayed 750)
[ 4833.908238] kobject: 'gpio-sim' (000000005b8d0726): kobject_cleanup, parent 000000007425b13f
[ 4833.908244] kobject: 'gpio-sim' (000000005b8d0726): auto cleanup kobject_del
[ 4833.908245] kobject: 'gpio-sim' (000000005b8d0726): auto cleanup 'remove' event
[ 4833.908247] kobject: 'gpio-sim' (000000005b8d0726): kobject_uevent_env
[ 4833.908273] kobject: 'gpio-sim' (000000005b8d0726): fill_kobj_path: path = '/bus/platform/drivers/gpio-sim'
[ 4833.908311] kobject: 'gpio-sim' (000000005b8d0726): calling ktype release
[ 4833.908315] kobject: 'gpio-sim': free name
[ 4834.932303] kobject: 'gpio_sim' (0000000096ea0bb1): kobject_release, parent 0000000093357d30 (delayed 250)
[ 4835.952388] kobject: 'gpio_sim' (0000000096ea0bb1): kobject_cleanup, parent 0000000093357d30
[ 4835.952413] kobject: 'gpio_sim' (0000000096ea0bb1): auto cleanup kobject_del
[ 4835.952415] kobject: 'gpio_sim' (0000000096ea0bb1): auto cleanup 'remove' event
[ 4835.952416] kobject: 'gpio_sim' (0000000096ea0bb1): kobject_uevent_env
[ 4835.952424] kobject: 'gpio_sim' (0000000096ea0bb1): fill_kobj_path: path = '/module/gpio_sim'
[ 4835.952445] kobject: 'gpio_sim' (0000000096ea0bb1): calling ktype release
[ 4835.952448] kobject: 'gpio_sim': free name
Or, with CONFIG_DEBUG_DEVRES=y, it looks like this:
I don't see that been enabled (it requires to pass a command line option to the kernel).
I don't think I have found this command line option to LK.
So far it seems that the kobject_release() was called for both /bus/platform/drivers/gpio-sim
and /module/gpio_sim . Is there soemthing I'm missing?
However, I've found one relatively unrelated failure to call kobject_release().
This happens during shutdown, after the syslog is shutdown, so I can only provide
a screenshot as a proof and for diagnostics:
https://domac.alu.hr/~mtodorov/linux/bugreports/integrity/20230308_123748.jpg
https://domac.alu.hr/~mtodorov/linux/bugreports/integrity/20230308_123752.jpg
I failed to locate the driver and responsible maintainers to the present moment.
It is happening on shutdown and it isn't that critical IMHO, except if it shows
some other problem in the code :-/
Or maybe the chip->gc.parent should be changed to something else (actual GPIO
device, but then it's unclear how to provide the attributes in non-racy way
Really, dunno. I have to repeat that my learning curve cannot adapt so quickly.
I merely gave the report of KMEMLEAK, otherwise I am not a Linux kernel
device expert nor would be appropriate to try the craft not earned ;-)
With all of these additional debugging, cat /sys/kernel/debug/kmemleak
showed nothing new.
I believe this is reasonably safe.
However, I was unsuccessful in seeing gpio trace, even with
echo 1 > /sys/kernel/tracing/events/gpio/enable ... :-/
It's available in the trace buffer (you need to read a documentation to
understand how it works).
Still working on that, had other tasks to do ... So far I got to this:
1020 echo "1" > /sys/kernel/tracing/events/gpio/enable
1021 more /sys/kernel/tracing/trace
1022 cd ~marvin/linux/kernel/linux_torvalds/tools/testing/selftests/gpio/
1023 ls
1024 ./gpio-sim.sh
1025 more /sys/kernel/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 9/9 #P:6
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
gpio-sim.sh-21157 [000] ..... 2705.538025: gpio_direction: 560 in (0)
gpio-mockup-cde-21471 [000] ..... 2705.579730: gpio_direction: 564 in (0)
gpio-mockup-cde-21471 [000] ..... 2705.579745: gpio_value: 564 get 1
gpio-mockup-cde-21478 [003] ..... 2705.589475: gpio_direction: 565 in (0)
gpio-mockup-cde-21478 [003] ..... 2705.589488: gpio_value: 565 get 0
gpio-mockup-cde-21561 [003] ..... 2705.721427: gpio_value: 589 set 1
gpio-mockup-cde-21561 [003] ..... 2705.721427: gpio_direction: 589 out (0)
gpio-mockup-cde-21595 [000] ..... 2705.855861: gpio_direction: 597 in (0)
gpio-mockup-cde-21595 [000] ..... 2705.855875: gpio_value: 597 get 1
[root@pc-mtodorov gpio]#
I hope I did this right. However, I have to play a bit with these results before
I could make any interpretation.
I just wanted to provide some feedback.
Regards,
Mirsad
--
Mirsad Goran Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
