search for: slabs

Hi, llvm::BumpPtrAllocatorImpl::Reset() looks like it has a bug. There is this check at the top: if (Slabs.empty()) return; But what if you don't have any normal Slabs allocated but only CustomSizedSlabs. I think this should be: if (Slabs.empty() && CustomSizedSlabs.empty()) return;

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 Dmitry On Thu, 13 Jun 2019 20:12:06 +0800 Dmitry Vyukov wrote: > On Thu, Jun 13, 2019 at 2:07 PM Hillf Danton <hdanton at sina.com> wrote: > > > > Hello Jason > > > > On Thu, 13 Jun 2019 17:10:39 +0800 Jason Wang wrote: > > > > > > This is basically a kfree(ubuf) after the second vhost_net_flush() in > > > vhost_net_release(). >

Hello Dmitry On Thu, 13 Jun 2019 20:12:06 +0800 Dmitry Vyukov wrote: > On Thu, Jun 13, 2019 at 2:07 PM Hillf Danton <hdanton at sina.com> wrote: > > > > Hello Jason > > > > On Thu, 13 Jun 2019 17:10:39 +0800 Jason Wang wrote: > > > > > > This is basically a kfree(ubuf) after the second vhost_net_flush() in > > > vhost_net_release(). >

...truct kmem_cache { gfp_t allocflags; /* gfp flags to use on each alloc */ int refcount; /* Refcount for slab cache destroy */ void (*ctor)(void *); + void (*decoder)(void *); int inuse; /* Offset to metadata */ int align; /* Alignment */ int reserved; /* Reserved bytes at the end of slabs */ diff --git a/mm/slab_common.c b/mm/slab_common.c index 3f3cd97..8c19bfd 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -193,6 +193,7 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const char *name, size_t size, s->object_size = s->size = size; s->align = calculate_a...

...truct kmem_cache { gfp_t allocflags; /* gfp flags to use on each alloc */ int refcount; /* Refcount for slab cache destroy */ void (*ctor)(void *); + void (*decoder)(void *); int inuse; /* Offset to metadata */ int align; /* Alignment */ int reserved; /* Reserved bytes at the end of slabs */ diff --git a/mm/slab_common.c b/mm/slab_common.c index 3f3cd97..39a0fb2 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -193,6 +193,7 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const char *name, size_t size, s->object_size = s->size = size; s->align = calculate_a...

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

Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: memory leak in batadv_tvlv_handler_register 484.626788][ T156] bond0 (unregistering): Releasing backup interface bond_slave_1 Warning: Permanently added '10.128.0.87' (ECDSA) to the list of known hosts. BUG: memory leak unreferenced object 0xffff88811d25c4c0 (size 64): comm

Hello Syzbot On Fri, 14 Jun 2019 11:04:03 +0800 syzbot wrote: > >Hello, > >syzbot has tested the proposed patch but the reproducer still triggered crash: >memory leak in batadv_tvlv_handler_register > It is not ubuf leak which is addressed in this thread. Good news. I will see this new leak soon. > 484.626788][ T156] bond0 (unregistering): Releasing backup interface

...otice the difference between 0x7f80a28325e0 and 0x7f80a28325a0, especially when they're a few screens apart. Hence the idea: why don't we print the offset into the allocator's memory slab instead of a pointer? We use BumpPtrAllocator all over the place, which boils down to a set of slabs on which all objects are placed in the order in which they are allocated. It is easy for the allocator to identify if a pointer belongs to that allocator, and if so, deteremine which slab it belongs to and at what offset the object is in that slab. Therefore it is possible to identify the objec...

Hello Syzbot On Fri, 14 Jun 2019 11:04:03 +0800 syzbot wrote: > >Hello, > >syzbot has tested the proposed patch but the reproducer still triggered crash: >memory leak in batadv_tvlv_handler_register > > 484.626788][ T156] bond0 (unregistering): Releasing backup interface bond_slave_1 >Warning: Permanently added '10.128.0.87' (ECDSA) to the list of known hosts.

...shows, of the 32 cores, 0, 2, > 4 and 6 ok, and *all* other show "is now offline. > > What's happening here? > A followup: I also find a core in /var/spool/abrt, and "reason" is kernel BUG at mm/slub.c:3601! In googling, I see threads about incorrect calculation of slabs. Following one thread, I find cat /sys/kernel/slab/:t-0000048/cpu_slabs gives me 4 N0=4 Meanwhile, slabtop shows Active / Total Slabs (% used) : 25927 / 25927 (100.0%) Which changes, but just varying around that number, and st 100%. So: should I increase the number of slabs, using the ke...

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

On Fri, May 14, 2010 at 09:10:57PM +0200, Peter Klar wrote: > As the bug seems to be related to the SLAB allocator, the dump says ''kernel > BUG at mm/slub.c:2969!'', I also recompiled the kernel using the SLAB instead > of SLUB allocator, but this does not make any difference, the behaviour is > the same (beside the dump then reports a bug within slab.c instead of

On Fri, May 14, 2010 at 09:10:57PM +0200, Peter Klar wrote: > As the bug seems to be related to the SLAB allocator, the dump says ''kernel > BUG at mm/slub.c:2969!'', I also recompiled the kernel using the SLAB instead > of SLUB allocator, but this does not make any difference, the behaviour is > the same (beside the dump then reports a bug within slab.c instead of

Jan Niehusmann <jan@gondor.com> wrote: > > Yesterday, I got the following error with 2.6.16.13 during a file copy > from a smb filesystem over a wireless link. I guess there was some error > on the wireless link, which in turn caused an error condition for the > smb filesystem. > > In the log, smb_file_read reports error=4294966784 (0xfffffe00), which > also shows up

On Wed, 05 Jun 2019 16:42:05 -0700 (PDT) syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: 788a0249 Merge tag 'arc-5.2-rc4' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15dc9ea6a00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=d5c73825cbdc7326