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

Andy Shevchenko
2023-03-08T15:21:22Z

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