@johnwaynee: we plan to address every issue that is technically possible to address. Hopefully the more detailed breakdown of issues around memory use, both leak, and could be perceived as a leak helps address your concern.
So what I have managed to trace down so far. This isn't a single bug, but multiple issues. Some of them existed before 6.8 but have been exacerbated by the apparmor patchset (eg see issue 2). 1. There is a ref count leak in the prompt listener. I have patch for this and it will be fixed. 2. There is a bug in the userspace policy compiler that makes policy, unnecessarily large. It shows up in slab monitoring mostly in kmalloc-rnd-*-8 slabs. I have a kernel mitigation for this that can detect and fix it as part of policy verification. A policy compiler fix is also in the works. This bug exists pre 6.8, however the Ubuntu apparmor patchset, advertises support for permstable32 v3 which triggers the compiler to generate the erroneously large tables. 3. There is a ref count leak in complain mode due to a cycle. This can be manually broken, and cleaned up by explicitly removing complain mode null-XXX profiles, but they currently won't auto cleanup when no longer used. Manually you can use the aa-remove-unknown tool to clean these up but that tool may also break snap, and lxd policy. A fix for this is a wip progress but it is going to take time, as it requires rearchitecting the profile/label and label proxy interaction. This bug has existed for a long time. 4. There is a ref count leak, that is still being chased. It may be cyclic. It will be fixed when the cause is understood. Issues 5 and on are not technically leaks but are sources of increased memory usage, that may look like a leak. They are not the only issues, but increased memory usages that in some way that can be addressed. 5. The increased policy shipped with Noble and following is just causing more memory usage. Issue 2 exacerbates this but doesn't account for all of this. So I will note the larger ones that can be seen, and addressed in some way, that is the memory use isn't required (or at least fully) and can be addressed. 5.1 apparmorfs - the increased policy is causing a proportionally large increase in pre-allocated inodes, and dentries. It is currently a permanent increase, and requires a rewrite of apparmorfs to by more dynamic. This is currently planned for but not priority for addressing the issue seen here. 5.2 policy criu support compress - to support criu apparmor is storing extra policy info in the kernel. It compresses it, but it is not optimal. There is work to allow this to be done in userspace, which will allow for better sharing and compression. Reducing the overhead of criu support. In addition there will be support for a runtime flag (currently only compile) to disable criu support for machines where it isn't needed. 5.3 Increased caching - the apparmor patchset has a cache to store audit logging information. Items in the cache can live beyond replacement. Appear to be a leak. Atm unless prompt is in heavy use this should be resulting in a large amount of data being used. Regardless it could be improved. 6. This is an issue that is going to need further investigation and design. AppArmor labels all open fd objects. These fd object will contain references to profiles, and for as long as the object lives those references will pin old profiles in memory even after they have been replaced. This can look like a leak but isn't, and is part of what makes chasing issues 4 down so hard. With the increase in policy we are seeing a lot more of this. It is possible we could mitigate some of the memory use here by allowing a replaced profile to be partially freed after being replaced, if it is pinned in this way. 7. There is some work in progress that will improve apparmor policy compression (this is different than issue 5.2 criu compression) which will result in less memory needed for policy in general. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2098730 Title: Kernel 6.8.0 memory leak To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2098730/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
