Description of problem: I keep kmemleak enabled while developing/testing code. I've been seeing kmemleak report this leak for at least v3.4 and v3.5 (haven't tested v3.6 yet): unreferenced object 0xffff880324f6cd60 (size 32): comm "kthreadd", pid 2, jiffies 4294704184 (age 83615.009s) hex dump (first 32 bytes): 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814b740e>] kmemleak_alloc+0x5e/0xc0 [<ffffffff8114c777>] __kmalloc_track_caller+0x137/0x260 [<ffffffff8111cd6d>] kmemdup+0x2d/0x60 [<ffffffff811f50ef>] selinux_cred_prepare+0x1f/0x40 [<ffffffff811f1ab6>] security_prepare_creds+0x16/0x20 [<ffffffff81068c72>] prepare_creds+0x92/0xb0 [<ffffffff81069259>] copy_creds+0x79/0x1c0 [<ffffffff8103c40b>] copy_process+0x1ab/0xed0 [<ffffffff8103d464>] do_fork+0x54/0x260 [<ffffffff8100aea6>] kernel_thread+0x76/0x80 [<ffffffff81061b8a>] kthreadd+0x25a/0x290 [<ffffffff814d81e4>] kernel_thread_helper+0x4/0x10 [<ffffffffffffffff>] 0xffffffffffffffff After the first boot (of a RHEL6.2 distro) with these upstream kernels I see nearly 500 instances of this leak. And while the system is up I'll periodically get more coming in. Could be false-positives but kmemleak has found 3 nasty leaks in DM code for me so I'm inclined to trust it. It should be noted that I have SELINUX=disabled. I haven't put my finger on what is triggering the leaks but it happens so frequently that simply booting/running the kernel will expose these leaks.
(In reply to comment #0) > Description of problem: > > I keep kmemleak enabled while developing/testing code. I've been seeing > kmemleak report this leak for at least v3.4 and v3.5 (haven't tested > v3.6 yet): FYI, I'm seeing a wider variety of memory leaks with v3.6-rc2: kmemleak: 417 new suspected memory leaks (see /sys/kernel/debug/kmemleak) (all 417 are related to selinux, and again I have SELINUX=disabled) unreferenced object 0xffff88033f001540 (size 32): comm "swapper/0", pid 0, jiffies 4294667400 (age 900.820s) hex dump (first 32 bytes): 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0 [<ffffffff81151a3b>] __kmalloc_track_caller+0x14b/0x2d0 [<ffffffff8112197d>] kmemdup+0x2d/0x60 [<ffffffff811f3fbf>] selinux_cred_prepare+0x1f/0x40 [<ffffffff811f0986>] security_prepare_creds+0x16/0x20 [<ffffffff8106c562>] prepare_creds+0x92/0xb0 [<ffffffff8106cb49>] copy_creds+0x79/0x1c0 [<ffffffff8103f6db>] copy_process+0x1ab/0xec0 [<ffffffff81040794>] do_fork+0x54/0x260 [<ffffffff8100ae96>] kernel_thread+0x76/0x80 [<ffffffff814ba9d1>] rest_init+0x21/0x80 [<ffffffff81af9eed>] start_kernel+0x3d1/0x3de [<ffffffff81af9335>] x86_64_start_reservations+0x131/0x136 [<ffffffff81af943d>] x86_64_start_kernel+0x103/0x112 [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff880328a757c0 (size 128): comm "swapper/0", pid 1, jiffies 4294670653 (age 897.573s) hex dump (first 32 bytes): 00 80 ab 28 03 88 ff ff 03 00 00 00 05 00 00 00 ...(............ 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0 [<ffffffff811514cb>] kmem_cache_alloc_trace+0xdb/0x270 [<ffffffff811fa8a5>] selinux_sb_alloc_security+0x25/0x90 [<ffffffff811f05a6>] security_sb_alloc+0x16/0x20 [<ffffffff81161b9d>] alloc_super+0x3d/0x330 [<ffffffff811629b8>] sget+0x88/0x2b0 [<ffffffff81162c1d>] mount_single+0x3d/0xd0 [<ffffffff811fb738>] sel_mount+0x18/0x20 [<ffffffff811627d3>] mount_fs+0x43/0x1a0 [<ffffffff8117db92>] vfs_kern_mount+0x72/0x100 [<ffffffff8117dc39>] kern_mount_data+0x19/0x30 [<ffffffff81b1f358>] init_sel_fs+0x6a/0xa5 [<ffffffff810001c2>] do_one_initcall+0x42/0x180 [<ffffffff81af9646>] do_basic_setup+0x9d/0xbb [<ffffffff81af98b8>] kernel_init+0x1f9/0x27b [<ffffffff814dd9c4>] kernel_thread_helper+0x4/0x10 unreferenced object 0xffff88032891e348 (size 72): comm "swapper/0", pid 1, jiffies 4294670653 (age 897.573s) hex dump (first 32 bytes): 30 99 85 2e 03 88 ff ff 00 58 a7 28 03 88 ff ff 0........X.(.... 08 e3 91 28 03 88 ff ff 01 00 00 00 03 00 00 00 ...(............ backtrace: [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0 [<ffffffff81151783>] kmem_cache_alloc+0x123/0x290 [<ffffffff811f43c5>] selinux_inode_alloc_security+0x45/0xa0 [<ffffffff811f074e>] security_inode_alloc+0x1e/0x20 [<ffffffff8117a38a>] inode_init_always+0xca/0x1c0 [<ffffffff8117a4ba>] alloc_inode+0x3a/0xa0 [<ffffffff8117a533>] new_inode_pseudo+0x13/0x60 [<ffffffff8117a59d>] new_inode+0x1d/0x40 [<ffffffff8118371e>] simple_fill_super+0x4e/0x1f0 [<ffffffff811fdaaa>] sel_fill_super+0x2a/0x2e0 [<ffffffff81162c81>] mount_single+0xa1/0xd0 [<ffffffff811fb738>] sel_mount+0x18/0x20 [<ffffffff811627d3>] mount_fs+0x43/0x1a0 [<ffffffff8117db92>] vfs_kern_mount+0x72/0x100 [<ffffffff8117dc39>] kern_mount_data+0x19/0x30 [<ffffffff81b1f358>] init_sel_fs+0x6a/0xa5 unreferenced object 0xffff8803280d92e0 (size 32): comm "udevd", pid 135, jiffies 4294672167 (age 1018.607s) hex dump (first 32 bytes): 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0 [<ffffffff811514cb>] kmem_cache_alloc_trace+0xdb/0x270 [<ffffffff811faa06>] selinux_file_alloc_security+0x46/0x70 [<ffffffff811f07c6>] security_file_alloc+0x16/0x20 [<ffffffff81160ea4>] get_empty_filp+0xa4/0x190 [<ffffffff81160fbe>] alloc_file+0x2e/0xf0 [<ffffffff8140ad6f>] sock_alloc_file+0xaf/0x130 [<ffffffff8140ae09>] sock_map_fd+0x19/0x40 [<ffffffff8140bc31>] sys_socket+0x51/0x80 [<ffffffff814dc929>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff880326d674a0 (size 32): comm "load_policy", pid 459, jiffies 4294676623 (age 1129.198s) hex dump (first 32 bytes): 01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0 [<ffffffff811514cb>] kmem_cache_alloc_trace+0xdb/0x270 [<ffffffff811faa06>] selinux_file_alloc_security+0x46/0x70 [<ffffffff811f07c6>] security_file_alloc+0x16/0x20 [<ffffffff81160ea4>] get_empty_filp+0xa4/0x190 [<ffffffff8116fec8>] path_openat+0x48/0x480 [<ffffffff81170419>] do_filp_open+0x49/0xa0 [<ffffffff8115ee48>] do_sys_open+0x108/0x1e0 [<ffffffff8115ef61>] sys_open+0x21/0x30 [<ffffffff814dc929>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff
I'm not sure it is related, but I had several kernel panics while booting with message like "unable to handle kernel paging request at 6d0000006d" and IP here: kmem_cache_alloc_trace() 0x63/0x160 Called from: selinux_file_alloc_security() Can't provide the entire log, sorry. Kernel 3.6.2-4.fc17.x86_64
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still an issue with the 3.9 kernels in F19?
(In reply to comment #4) > Is this still an issue with the 3.9 kernels in F19? AFAIK it is. But I've just been running stock 3.9-rc5 and seeing it like crazy so cannot see why F19 wouldn't also be affected. But I'll defer to others who are actually running the F19 3.9 kernels...
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
(In reply to comment #6) > This bug is being closed with INSUFFICIENT_DATA as there has not been a > response in 2 weeks. If you are still experiencing this issue, > please reopen and attach the relevant data from the latest kernel you are > running and any data that might have been requested previously. I'm sorry but what you did there was really gross. And yes, it is still happening even with 3.9-rc8 (with kmemleak enabled): unreferenced object 0xffff88032d3d6520 (size 32): comm "load_policy", pid 467, jiffies 4294674360 (age 56995.147s) hex dump (first 32 bytes): 01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814f515e>] kmemleak_alloc+0x5e/0xc0 [<ffffffff8115ce75>] kmem_cache_alloc_trace+0xe5/0x230 [<ffffffff8120d176>] selinux_file_alloc_security+0x46/0x70 [<ffffffff81202e76>] security_file_alloc+0x16/0x20 [<ffffffff8116e240>] get_empty_filp+0x90/0x1a0 [<ffffffff8117ca68>] path_openat+0x48/0x460 [<ffffffff8117cfb9>] do_filp_open+0x49/0xa0 [<ffffffff8116ab98>] do_sys_open+0x108/0x1f0 [<ffffffff8116acc1>] sys_open+0x21/0x30 [<ffffffff81511719>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff Closing this bug doesn't make it go away. And the person you should be getting information from is Eric Paris or some other SE linux developer. I've not gotten any indication that a relevant developer has even looked into this.
Sorry, you got caught in the mass update of bugs that were moved from rawhide. This was a mass update that closed 60 bugs or so, and I wasn't looking at them individually, you had responded before but needinfo was set for some reason still.
You said you have SELINUX=disabled? Then it shouldn't even be calling those selinux_* functions anymore. grep selinux /proc/filesystems ls /sys/fs/selinux echo 1 > /sys/fs/selinux/disable
(In reply to comment #9) > You said you have SELINUX=disabled? Yes. > Then it shouldn't even be calling those selinux_* functions anymore. > grep selinux /proc/filesystems > ls /sys/fs/selinux > echo 1 > /sys/fs/selinux/disable Right, doesn't make any sense to me why selinux is even being called: # grep selinux /proc/filesystems # ls /sys/fs/selinux ls: cannot access /sys/fs/selinux: No such file or directory
Hmmm..and with selinux=0 on the grub command line?
(In reply to comment #11) > Hmmm..and with selinux=0 on the grub command line? No, selinux=0 isn't on the grub command line. I can try that to see if these kmemleaks go away.
So, with SELINUX=disabled, I would expect some leaks from allocation of security blobs for early tasks, inodes, etc, prior to systemd disabling SELinux. It doesn't try to track down everything allocated up to that point and free it. But it should continue to occur at runtime, as the SELinux hooks should no longer be called anymore. And if you have no selinuxfs in /proc/filesystems, then that suggests that it was truly disabled and not just permissive with no policy loaded. With selinux=0 on the grub command line, the kernel can disable at boot prior to allocating any security blobs and thus you shouldn't leak anything at all. Neither case should lead to ongoing leaks at runtime.
Sorry, s/should continue/should not continue/
I saw similar leaks using 3.9.5, and putting selinux=0 on the kernel command line 'fixed' the problem according to kmemleak.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
I'll avoid closing this again, but getting confirmation on 3.11 would still be good. Eric, are you going to look at this?
We know we leak some memory when selinux is disabled in the config file but not on the command line. it should be a very small amount. The book keeping required to ensure that the memory we leak is finally not being referenced is not reasonable. We do not intend to fix this bug at this time unless it poses an actual problem... I mean, maybe one day we'll have nothing to do and we'll get to it, but I highly doubt it...
(In reply to Eric Paris from comment #18) > We know we leak some memory when selinux is disabled in the config file but > not on the command line. it should be a very small amount. It isn't a one-time leak. it keeps occurring the entire time the system is up. > The book > keeping required to ensure that the memory we leak is finally not being > referenced is not reasonable. We do not intend to fix this bug at this time > unless it poses an actual problem... > > I mean, maybe one day we'll have nothing to do and we'll get to it, but I > highly doubt it... Pretty strange stance but OK...
This issue has been dormant for almost five years, I'm going to close this out. If you want to re-open the issue, I suggest doing so in the upstream GitHub issue tracker. * https://github.com/SELinuxProject/selinux-kernel