Re: INFO: REPRODUCED: memory leak in gpio device in 6.2-rc6

[Andy Shevchenko]

On Wed, Mar 08, 2023 at 02:11:39PM +0100, Mirsad Todorovac wrote:
> On 2/28/23 00:13, Andy Shevchenko wrote:

...

> > > 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?

Have you read the code in drivers/base/devres.c?

https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/base/devres.c#L53

> 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 :-/

Congrats, you found a real issue somewhere.  `git grep` usually helps
with this, like `git grep -n -w '"integrity"'` shows a few files, most
likely security/integrity/iint.c is the culprit.

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

> I hope I did this right. However, I have to play a bit with these results before
> I could make any interpretation.

Yes. Just be sure you have all data dumped.

> I just wanted to provide some feedback.

Thanks.

-- 
With Best Regards,
Andy Shevchenko