search for: slab

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;

...01 00 00 00 81 88 ff ff 00 00 00 00 82 88 ff ff ................ > d0 6a bc 1c 81 88 ff ff d0 6a bc 1c 81 88 ff ff .j.......j...... > backtrace: > [<000000006c752978>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] > [<000000006c752978>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<000000006c752978>] slab_alloc mm/slab.c:3326 [inline] > [<000000006c752978>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<00000000b3825d52>] kmalloc include/linux/slab.h:547 [inline] > [<0000000...

...01 00 00 00 81 88 ff ff 00 00 00 00 82 88 ff ff ................ > d0 6a bc 1c 81 88 ff ff d0 6a bc 1c 81 88 ff ff .j.......j...... > backtrace: > [<000000006c752978>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] > [<000000006c752978>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<000000006c752978>] slab_alloc mm/slab.c:3326 [inline] > [<000000006c752978>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<00000000b3825d52>] kmalloc include/linux/slab.h:547 [inline] > [<0000000...

...(first 32 bytes): 01 00 00 00 20 69 6f 63 00 00 00 00 64 65 76 2f .... ioc....dev/ 50 fe 21 24 81 88 ff ff 50 fe 21 24 81 88 ff ff P.!$....P.!$.... backtrace: [<00000000ae0c4ae0>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<00000000ae0c4ae0>] slab_post_alloc_hook mm/slab.h:439 [inline] [<00000000ae0c4ae0>] slab_alloc mm/slab.c:3326 [inline] [<00000000ae0c4ae0>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<0000000079ebab38>] kmalloc include/linux/slab.h:547 [inline] [<0000000079ebab38>] vhost...

...(first 32 bytes): 01 00 00 00 20 69 6f 63 00 00 00 00 64 65 76 2f .... ioc....dev/ 50 fe 21 24 81 88 ff ff 50 fe 21 24 81 88 ff ff P.!$....P.!$.... backtrace: [<00000000ae0c4ae0>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<00000000ae0c4ae0>] slab_post_alloc_hook mm/slab.h:439 [inline] [<00000000ae0c4ae0>] slab_alloc mm/slab.c:3326 [inline] [<00000000ae0c4ae0>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<0000000079ebab38>] kmalloc include/linux/slab.h:547 [inline] [<0000000079ebab38>] vhost...

This adds a leak decoder callback so that slab destruction can use to generate debugging output for the allocated objects. Callers like btrfs are using their own leak tracking which will manage allocated objects in a list(or something else), this does indeed the same thing as what slab does. So adding a callback for leak tracking can avoid th...

This adds a leak decoder callback so that kmem_cache_destroy() can use to generate debugging output for the allocated objects. Callers like btrfs are using their own leak tracking which will manage allocated objects in a list(or something else), this does indeed the same thing as what slab does. So adding a callback for leak tracking can avoid this as well as runtime overhead. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> --- The idea is from Zach Brown <zab@zabbo.net>. fs/btrfs/extent_io.c | 24 ++++++++++++++++++++++++ fs/btrfs/extent_map.c | 12 ++++++++++...

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

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

...irst 32 bytes): 00 00 00 00 00 00 00 00 e0 fc 5b 20 81 88 ff ff ..........[ .... 00 00 00 00 00 00 00 00 20 91 15 83 ff ff ff ff ........ ....... backtrace: [<000000000045bc9d>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<000000000045bc9d>] slab_post_alloc_hook mm/slab.h:439 [inline] [<000000000045bc9d>] slab_alloc mm/slab.c:3326 [inline] [<000000000045bc9d>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<00000000197d773e>] kmalloc include/linux/slab.h:547 [inline] [<00000000197d773e>] kzall...

...t; 00 00 00 00 00 00 00 00 e0 fc 5b 20 81 88 ff ff ..........[ .... > 00 00 00 00 00 00 00 00 20 91 15 83 ff ff ff ff ........ ....... > backtrace: > [<000000000045bc9d>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] > [<000000000045bc9d>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<000000000045bc9d>] slab_alloc mm/slab.c:3326 [inline] > [<000000000045bc9d>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<00000000197d773e>] kmalloc include/linux/slab.h:547 [inline] > [<00000000197...

...om different runs together. Additionally, pointers are hard to read and memorize; it's hard to notice 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 bel...

...t; 00 00 00 00 00 00 00 00 e0 fc 5b 20 81 88 ff ff ..........[ .... > 00 00 00 00 00 00 00 00 20 91 15 83 ff ff ff ff ........ ....... > backtrace: > [<000000000045bc9d>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] > [<000000000045bc9d>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<000000000045bc9d>] slab_alloc mm/slab.c:3326 [inline] > [<000000000045bc9d>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<00000000197d773e>] kmalloc include/linux/slab.h:547 [inline] > [<00000000197...

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

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 <linux/kmemleak.h> to any users of kmemleak_* >> that don't already #include it. >> Also remove <linux/kmeml...

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 <linux/kmemleak.h> to any users of kmemleak_* >> that don't already #include it. >> Also remove <linux/kmeml...

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

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

...uring 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 in the slab dumps, and also is -ERESTARTSYS. Error code > 27499 corresponds to 0x6b6b, so the rq_errno field seems to be the only > one being set after freeing the slab. > > In smb_add_request (which is the only place in smbfs where I found > ERESTARTSYS), I found the following: > >...

...01 00 00 00 20 69 6f 63 00 00 00 00 64 65 76 2f .... ioc....dev/ > 50 fe 21 24 81 88 ff ff 50 fe 21 24 81 88 ff ff P.!$....P.!$.... > backtrace: > [<00000000ae0c4ae0>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] > [<00000000ae0c4ae0>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<00000000ae0c4ae0>] slab_alloc mm/slab.c:3326 [inline] > [<00000000ae0c4ae0>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<0000000079ebab38>] kmalloc include/linux/slab.h:547 [inline] > [<0000000...