Hi Peter,
Thanks for sharing your thoughts.
Once we identify the memory leak, I'll share the details with you
and Kamil, and we can discuss how to proceed further. Please keep
us updated on any findings on your side. We’re running weekly
tests with the -keach
parameter, so it’s applied to every test.
Best regards,
Vitaly
Hi Vitaly, On 12.03.2025 23:35, vitaly prosyak wrote:Hi Peter, We ran the updated igt-runner in our CI with your merged patches, and the memleak feature is working (using the -keach command). However, we noticed what seems to be false positives related to the ACPI driver. The stack is provided below.Thank you for testing and reporting back! I've noticed false positives as well. In my case the likelihood of false positives seems to be related to hardware and test list.I haven’t had a chance to investigate this further, but I think it would be a good idea to share our findings upstream for memleaks found outside of the AMDGPU or i915 drivers.I haven't considered this idea before: reporting other leaks upstream. You are correct, reporting these leaks is probably a good idea. I'm unsure on how to proceed here because I see two issues: - manual reporting does not scale in the context of our automated tests - upstream response to the reports We want kmemleak results to improve our upstream code, but I do not know if these reports will be welcome everywhere. For projects that do not have the manpower to fix the issues, we may simply increase noise. What do you suggest? Thank you, and have a great week, PeterHere the stack: comm "swapper/0", pid 1, jiffies 4294672730 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 0d 01 a2 00 00 00 00 00 ................ f0 7c 03 00 00 c9 ff ff 00 00 00 00 00 00 00 00 .|.............. backtrace (crc 2df71a7e): [<ffffffff824cd71b>] kmemleak_alloc+0x4b/0x80 [<ffffffff814e169b>] kmem_cache_alloc_noprof+0x2ab/0x370 [<ffffffff81c2f4dc>] acpi_ps_alloc_op+0xdc/0xf0 [<ffffffff81c2d650>] acpi_ps_create_op+0x1c0/0x400 [<ffffffff81c2c8dc>] acpi_ps_parse_loop+0x16c/0xa60 [<ffffffff81c2e94f>] acpi_ps_parse_aml+0x22f/0x5f0 [<ffffffff81c2fa82>] acpi_ps_execute_method+0x152/0x380 [<ffffffff81c233ed>] acpi_ns_evaluate+0x31d/0x5e0 [<ffffffff81c2a606>] acpi_evaluate_object+0x206/0x490 [<ffffffff81bf1202>] __acpi_power_off.isra.0+0x22/0x70 [<ffffffff81bf275b>] acpi_turn_off_unused_power_resources+0xbb/0xf0 [<ffffffff83867799>] acpi_scan_init+0x119/0x290 [<ffffffff8386711a>] acpi_init+0x23a/0x590 [<ffffffff81002c71>] do_one_initcall+0x61/0x3d0 [<ffffffff837dce32>] kernel_init_freeable+0x3e2/0x680 [<ffffffff824ca53b>] kernel_init+0x1b/0x170unreferenced object 0xffff888102a2ed18 (size 80): comm "swapper/0", pid 1, jiffies 4294672730 hex dump (first 32 bytes): 38 e6 a2 02 81 88 ff ff 0d 11 2d 00 00 00 00 00 8.........-..... f2 7c 03 00 00 c9 ff ff 58 ea a2 02 81 88 ff ff .|......X....... Thanks, Vitaly On 2025-03-10 16:05, vitaly prosyak wrote:Hi Peter and Kamil, We'll run the tests and I'll follow up on this thread. Really appreciate you merging this—thank you! Best, Vitaly On 2025-03-10 03:07, Peter Senna Tschudin wrote:Hi Vitaly, On 10.03.2025 04:07, vitaly prosyak wrote:Hi Peter, Version 8 of your three patches looks good to me. However, I haven't tested them locally. Let me know if you’d like us to run them locally ( not CI)I ran local tests before sending the patches, so I’m confident there are no major issues. That said, if you’re able to test them locally as well, it would help confirm that everything is working as expected. I’d appreciate it if you could run the tests.Thanks for the improvements!Thank you for reviewing the patches! Peter [...]