search for: kmemleaks

From: Randy Dunlap <rdunlap at infradead.org> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious reason. It looks like it's only a convenience, so remove kmemleak.h from slab.h and add <linux/kmemleak.h> to any users of kmemleak_* that don't already #include it. Also remove <linux/kmemleak.h> from source files that do not use it. This is

From: Randy Dunlap <rdunlap at infradead.org> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious reason. It looks like it's only a convenience, so remove kmemleak.h from slab.h and add <linux/kmemleak.h> to any users of kmemleak_* that don't already #include it. Also remove <linux/kmemleak.h> from source files that do not use it. This is

On 02/12/2018 04:28 AM, Michael Ellerman wrote: > Randy Dunlap <rdunlap at infradead.org> writes: > >> From: Randy Dunlap <rdunlap at infradead.org> >> >> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious >> reason. It looks like it's only a convenience, so remove kmemleak.h >> from slab.h and add

On 02/12/2018 04:28 AM, Michael Ellerman wrote: > Randy Dunlap <rdunlap at infradead.org> writes: > >> From: Randy Dunlap <rdunlap at infradead.org> >> >> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious >> reason. It looks like it's only a convenience, so remove kmemleak.h >> from slab.h and add

While doing simple IPv6 tests in KVM virtual machines, (add an IPv6 address to eth0) kmemleak complains about an unreferenced object: unreferenced object 0xffff88001e804120 (size 32): comm "softirq", pid 0, jiffies 4294900928 (age 631.544s) hex dump (first 32 bytes): 28 cb fd 1d 00 00 00 00 0c 00 00 00 01 00 01 00 (............... 02 d0 83 1d 00 00 00 00 6e 00 00 00 00 00

While doing simple IPv6 tests in KVM virtual machines, (add an IPv6 address to eth0) kmemleak complains about an unreferenced object: unreferenced object 0xffff88001e804120 (size 32): comm "softirq", pid 0, jiffies 4294900928 (age 631.544s) hex dump (first 32 bytes): 28 cb fd 1d 00 00 00 00 0c 00 00 00 01 00 01 00 (............... 02 d0 83 1d 00 00 00 00 6e 00 00 00 00 00

* Randy Dunlap <rdunlap at infradead.org> wrote: > From: Randy Dunlap <rdunlap at infradead.org> > > Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious > reason. It looks like it's only a convenience, so remove kmemleak.h > from slab.h and add <linux/kmemleak.h> to any users of kmemleak_* > that don't already #include it.

Randy Dunlap <rdunlap at infradead.org> writes: > From: Randy Dunlap <rdunlap at infradead.org> > > Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious > reason. It looks like it's only a convenience, so remove kmemleak.h > from slab.h and add <linux/kmemleak.h> to any users of kmemleak_* > that don't already #include it.

Randy Dunlap <rdunlap at infradead.org> writes: > On 02/12/2018 04:28 AM, Michael Ellerman wrote: >> Randy Dunlap <rdunlap at infradead.org> writes: >> >>> From: Randy Dunlap <rdunlap at infradead.org> >>> >>> Currently <linux/slab.h> #includes <linux/kmemleak.h> for no obvious >>> reason. It looks like it's

Hello, 5.1.0-next-20190517 I'm looking at quite a lot of kmemleak reports coming from drm/nouveau/core/memory, all of which are: unreferenced object 0xffff8deec27c4ac0 (size 16): comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:

Hello, I have been hunting a memory-leak warning in vring_add_indirect: unreferenced object 0xffff88003d467e20 (size 32): comm "softirq", pid 0, jiffies 4295197765 (age 6.364s) hex dump (first 32 bytes): 28 19 bf 3d 00 00 00 00 0c 00 00 00 01 00 01 00 (..=............ 02 dc 51 3c 00 00 00 00 56 00 00 00 00 00 00 00 ..Q<....V....... backtrace:

Hello, I have been hunting a memory-leak warning in vring_add_indirect: unreferenced object 0xffff88003d467e20 (size 32): comm "softirq", pid 0, jiffies 4295197765 (age 6.364s) hex dump (first 32 bytes): 28 19 bf 3d 00 00 00 00 0c 00 00 00 01 00 01 00 (..=............ 02 dc 51 3c 00 00 00 00 56 00 00 00 00 00 00 00 ..Q<....V....... backtrace:

Hi I got a kmemleak and it is pointing to nvkm_iccsense_oneinit(). Please refer to the below kmemleak message. # uname -a Linux climb 4.19.0-rc1+ #4 SMP Thu Sep 20 11:48:55 KST 2018 x86_64 x86_64 x86_64 GNU/Linux # HW LG Notebook. (Model Name:lg15n54) # kmemleak mesage unreferenced object 0xffff8801e9c58388 (size 96): comm "systemd-udevd", pid 130, jiffies 4294895052 (age

## I forgot the write email without checking the enable text mode. So, send email again. Sorry for send E-mail twice. Hi I got a kmemleak and it is pointing to nvkm_iccsense_oneinit(). Please refer to the below kmemleak message. # uname -a Linux climb 4.19.0-rc1+ #4 SMP Thu Sep 20 11:48:55 KST 2018 x86_64 x86_64 x86_64 GNU/Linux # HW LG Notebook. (Model Name:lg15n54) # kmemleak mesage

On Fri, Oct 4, 2013 at 1:59 AM, Rusty Russell <rusty at rustcorp.com.au> wrote: > Thanks! Does this work? > > virtio_ring: plug kmemleak false positive. > > unreferenced object 0xffff88003d467e20 (size 32): > comm "softirq", pid 0, jiffies 4295197765 (age 6.364s) > hex dump (first 32 bytes): > 28 19 bf 3d 00 00 00 00 0c 00 00 00 01 00 01 00

On Fri, Oct 4, 2013 at 1:59 AM, Rusty Russell <rusty at rustcorp.com.au> wrote: > Thanks! Does this work? > > virtio_ring: plug kmemleak false positive. > > unreferenced object 0xffff88003d467e20 (size 32): > comm "softirq", pid 0, jiffies 4295197765 (age 6.364s) > hex dump (first 32 bytes): > 28 19 bf 3d 00 00 00 00 0c 00 00 00 01 00 01 00

Christoph Paasch <christoph.paasch at uclouvain.be> writes: > Hello, > > I have been hunting a memory-leak warning in vring_add_indirect: > > unreferenced object 0xffff88003d467e20 (size 32): > comm "softirq", pid 0, jiffies 4295197765 (age 6.364s) > hex dump (first 32 bytes): > 28 19 bf 3d 00 00 00 00 0c 00 00 00 01 00 01 00 (..=............ >

When adding orphans to an inode''s root, we start a transaction for that root that when ended in several places such as for example extent-tree.c:btrfs_remove_block_group(), inode.c:btrfs_unlink() and inode.c:btrfs_evict_node(), doesn''t result in a commit, that is, inode.c:btrfs_orphan_commit_root() doesn''t get called (via transaction.c:commit_fs_roots()). The respective

http://bugs.freedesktop.org/show_bug.cgi?id=26767 Summary: kmemleak complain about possible memory leak Product: xorg Version: 7.5 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

Recent changes to drivers/virtio broke compilation for the tests in tools/virtio. The following patches are build fixes for those changes, as well as a fix for a typo that would have never built. The changes were tested on my amd64 system against 3.14-rc2. Joel Stanley (3): tools/virtio: update internal copies of headers tools/virtio: fix missing kmemleak_ignore symbol tools/virtio: add a