similar to: [PATCH] headers: untangle kmemleak.h from mm.h

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

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

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> 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.

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

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

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

From: Thierry Reding <treding at nvidia.com> The memory allocated for a nouveau_cli object in nouveau_cli_create() is never freed. Free the memory in nouveau_cli_destroy() to plug this leak. kmemleak recorded this after running a couple of nouveau test programs. Note that kmemleak points at drm_open_helper() because for some reason it thinks that skipping the first two stack frames is a

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 Syzbot On Fri, 14 Jun 2019 02:26:02 +0800 syzbot wrote: > > Hello, > > syzbot has tested the proposed patch but the reproducer still triggered crash: > memory leak in vhost_net_ioctl > Oh sorry for my poor patch. > ANGE): hsr_slave_1: link becomes ready > 2019/06/13 18:24:57 executed programs: 18 > BUG: memory leak > unreferenced object 0xffff88811cbc6ac0

Hello Syzbot On Fri, 14 Jun 2019 02:26:02 +0800 syzbot wrote: > > Hello, > > syzbot has tested the proposed patch but the reproducer still triggered crash: > memory leak in vhost_net_ioctl > Oh sorry for my poor patch. > ANGE): hsr_slave_1: link becomes ready > 2019/06/13 18:24:57 executed programs: 18 > BUG: memory leak > unreferenced object 0xffff88811cbc6ac0

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:

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

The following changes since commit 33807f4f0daec3b00565c2932d95f614f5833adf: Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 (2014-03-11 11:53:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/virtio-next-for-linus for you to fetch changes up to fc4324b4597c4eb8907207e82f9a6acec84dd335:

The following changes since commit 33807f4f0daec3b00565c2932d95f614f5833adf: Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 (2014-03-11 11:53:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/virtio-next-for-linus for you to fetch changes up to fc4324b4597c4eb8907207e82f9a6acec84dd335:

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