Displaying 12 results from an estimated 12 matches for "__kmalloc_track_caller".
2013 Mar 27
2
system death under oom - 3.7.9
...//pastebin.com/YCYUXWvV. It was in
my messages, so I guess the system took a bit to die completely.
nouveau is somewhat implicated, as it is the first thing that hits an
allocation failure in nouveau_vm_create, and has a subsequent warn in
nouveau_mm_fini, but then there's a GPF in
__alloc_skb/__kmalloc_track_caller (and I'm using SLUB). Here is a
partial disassembly for __kmalloc_track_caller:
0xffffffff811325b1 <+138>: e8 a0 60 56 00 callq
0xffffffff81698656 <__slab_alloc.constprop.68>
0xffffffff811325b6 <+143>: 49 89 c4 mov %rax,%r12
0xffffffff811325b9 <+146...
2020 Nov 10
3
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
...7a/0x7e0 [nouveau]
[ 18.374133] kasan_report+0x3a/0x50
[ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
<...>
[ 18.767690] Allocated by task 342:
[ 18.773087] kasan_save_stack+0x1b/0x40
[ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0
[ 18.785646] __kmalloc_track_caller+0x1be/0x390
[ 18.792165] kstrdup_const+0x46/0x70
[ 18.797686] kobject_set_name_vargs+0x2f/0xb0
[ 18.803992] kobject_init_and_add+0x9d/0xf0
[ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]
[ 18.816853] ttm_bo_global_init+0x4a/0x160 [ttm]
[ 18.823420] ttm_bo_device_ini...
2010 Aug 02
4
softirq warnings when calling dev_kfree_skb_irq - bug in conntrack?
...0100729+ #29
Call Trace:
<IRQ> [<ffffffff81030de3>] warn_slowpath_common+0x80/0x98
[<ffffffff81030e10>] warn_slowpath_null+0x15/0x17
[<ffffffff81035ff3>] local_bh_enable+0x40/0x87
[<ffffffff814236e5>] destroy_conntrack+0x78/0x9e
[<ffffffff810bea55>] ? __kmalloc_track_caller+0xc3/0x135
[<ffffffff814203b4>] nf_conntrack_destroy+0x16/0x18
[<ffffffff813fadee>] skb_release_head_state+0x97/0xd9
[<ffffffff813fabbe>] __kfree_skb+0x11/0x7a
[<ffffffff813fac4e>] consume_skb+0x27/0x29
[<ffffffff81402d3a>] dev_kfree_skb_irq+0x18/0x62
[<...
2020 Nov 11
2
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
...t+0x3a/0x50
>> [ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>> <...>
>> [ 18.767690] Allocated by task 342:
>> [ 18.773087] kasan_save_stack+0x1b/0x40
>> [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0
>> [ 18.785646] __kmalloc_track_caller+0x1be/0x390
>> [ 18.792165] kstrdup_const+0x46/0x70
>> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0
>> [ 18.803992] kobject_init_and_add+0x9d/0xf0
>> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]
>> [ 18.816853] ttm_bo_global_init+0x4a/0x160 [...
2020 Nov 10
0
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
...18.374133] kasan_report+0x3a/0x50
> [ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> <...>
> [ 18.767690] Allocated by task 342:
> [ 18.773087] kasan_save_stack+0x1b/0x40
> [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0
> [ 18.785646] __kmalloc_track_caller+0x1be/0x390
> [ 18.792165] kstrdup_const+0x46/0x70
> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0
> [ 18.803992] kobject_init_and_add+0x9d/0xf0
> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]
> [ 18.816853] ttm_bo_global_init+0x4a/0x160 [ttm]
> [ 18.82...
2013 Sep 23
6
btrfs: qgroup scan failed with -12
...arn_alloc_failed+0x110/0x124
[1878432.675981] [<ffffffff810b1fd8>] __alloc_pages_nodemask+0x6a4/0x793
[1878432.676036] [<ffffffff810db7e8>] alloc_pages_current+0xc8/0xe5
[1878432.676098] [<ffffffff810af06c>] __get_free_pages+0x9/0x36
[1878432.676150] [<ffffffff810e27b9>] __kmalloc_track_caller+0x35/0x163
[1878432.676204] [<ffffffff810bde12>] krealloc+0x52/0x8c
[1878432.676265] [<ffffffffa036cdcb>] ulist_add_merge+0xe1/0x14e [btrfs]
[1878432.676324] [<ffffffffa036bcf0>] find_parent_nodes+0x49c/0x5a5 [btrfs]
[1878432.676383] [<ffffffffa036be75>] btrfs_find_all_r...
2011 Sep 12
1
SLUB allocation error on 3.0.3 / 4.1.1
...>] ? xen_restore_fl_direct_reloc+0x4/0x4
[1721485.352614] [<ffffffff810ed11e>] new_slab+0x7e/0x1f6
[1721485.352617] [<ffffffff810ed430>] __slab_alloc+0x19a/0x33c
[1721485.352623] [<ffffffff815b1655>] ? __netdev_alloc_skb+0x1d/0x3c
[1721485.352627] [<ffffffff810ed84e>] __kmalloc_track_caller+0x106/0x145
[1721485.352631] [<ffffffff815b1655>] ? __netdev_alloc_skb+0x1d/0x3c
[1721485.352634] [<ffffffff815b066d>] __alloc_skb+0x69/0x129
[1721485.352638] [<ffffffff815b1655>] __netdev_alloc_skb+0x1d/0x3c
[1721485.352643] [<ffffffff81469c03>] e1000_alloc_rx_buffers+0...
2020 Nov 11
0
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
...[ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
>>> <...>
>>> [ 18.767690] Allocated by task 342:
>>> [ 18.773087] kasan_save_stack+0x1b/0x40
>>> [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0
>>> [ 18.785646] __kmalloc_track_caller+0x1be/0x390
>>> [ 18.792165] kstrdup_const+0x46/0x70
>>> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0
>>> [ 18.803992] kobject_init_and_add+0x9d/0xf0
>>> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]
>>> [ 18.816853] ttm_bo_glob...
2020 Nov 12
2
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
..._ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>> <...>
> >>> [ 18.767690] Allocated by task 342:
> >>> [ 18.773087] kasan_save_stack+0x1b/0x40
> >>> [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0
> >>> [ 18.785646] __kmalloc_track_caller+0x1be/0x390
> >>> [ 18.792165] kstrdup_const+0x46/0x70
> >>> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0
> >>> [ 18.803992] kobject_init_and_add+0x9d/0xf0
> >>> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]
> >>> [...
2020 Nov 12
0
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
...0x17a/0x7e0 [nouveau]
>> >>> <...>
>> >>> [ 18.767690] Allocated by task 342:
>> >>> [ 18.773087] kasan_save_stack+0x1b/0x40
>> >>> [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0
>> >>> [ 18.785646] __kmalloc_track_caller+0x1be/0x390
>> >>> [ 18.792165] kstrdup_const+0x46/0x70
>> >>> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0
>> >>> [ 18.803992] kobject_init_and_add+0x9d/0xf0
>> >>> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]
>&...
2011 Dec 05
3
xen 4.0.1/w 2.6.32 swapper: page allocation failure
...2 01:29:39 xenhost-rack1 kernel: [4437064.011983]
[<ffffffff81038d75>] ? xen_force_evtchn_callback+0xd/0xf
Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.011987]
[<ffffffff8149064d>] ? find_skb+0x32/0x7d
Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.011991]
[<ffffffff811113db>] __kmalloc_track_caller+0xfd/0x17e
Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.011994]
[<ffffffff8103947f>] ? xen_restore_fl_direct_end+0x0/0x1
Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.011997]
[<ffffffff8149064d>] ? find_skb+0x32/0x7d
Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.011999]
[<fffffff...
2013 Aug 22
23
Question: How can I recover this partition? (unable to find logical $hugenum len 4096)
...fs]
[ 45.917188] [<f9ce23f7>] read_tree_block+0x47/0x50 [btrfs]
[ 45.917188] [<f9ce5f5c>] open_ctree+0x13bc/0x1b60 [btrfs]
[ 45.917188] [<c030b163>] ? strlcpy+0x33/0x50
[ 45.917188] [<f9cbe89b>] btrfs_mount+0x77b/0x8c0 [btrfs]
[ 45.917188] [<c0231ef0>] ? __kmalloc_track_caller+0x80/0x1d0
[ 45.917188] [<c0246351>] mount_fs+0x31/0x180
[ 45.917188] [<c020e3df>] ? __alloc_percpu+0xf/0x20
[ 45.917188] [<c025c6b5>] vfs_kern_mount+0x45/0xc0
[ 45.917188] [<c025e402>] do_mount+0x1e2/0x840
[ 45.917188] [<c025e10f>] ? copy_mount_options+...