Date:   Wed, 8 Mar 2023 14:11:39 +0100
From:   Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
To:     Andy Shevchenko <andriy.shevchenko@...el.com>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-kernel@...r.kernel.org,
        Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: INFO: REPRODUCED: memory leak in gpio device in 6.2-rc6

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@...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

Powered by blists - more mailing lists