* [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
@ 2016-06-10 6:11 ` Sergey Senozhatsky
0 siblings, 0 replies; 17+ messages in thread
From: Sergey Senozhatsky @ 2016-06-10 6:11 UTC (permalink / raw)
To: Michal Hocko, Andrew Morton
Cc: Vlastimil Babka, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Sergey Senozhatsky, Sergey Senozhatsky
Hello,
[ 429.191962] gfp: 2
[ 429.192634] ------------[ cut here ]------------
[ 429.193281] kernel BUG at mm/slub.c:1616!
[ 429.193920] invalid opcode: 0000 [#1] PREEMPT SMP
[ 429.194556] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_timer snd soundcore coretemp hwmon mousedev r8169 i2c_i801 crc32c_intel mii lpc_ich mfd_core acpi_cpufreq processor sch_fq_codel uas usb_storage hid_generi
c usbhid hid sd_mod ahci libahci libata scsi_mod ehci_pci ehci_hcd usbcore usb_common
[ 429.196008] CPU: 0 PID: 562 Comm: gzip Not tainted 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.197385] task: ffff8800bf8e3a80 ti: ffff88009434c000 task.ti: ffff88009434c000
[ 429.198082] RIP: 0010:[<ffffffff811036a5>] [<ffffffff811036a5>] new_slab+0x25/0x2be
[ 429.198782] RSP: 0018:ffff88009434f820 EFLAGS: 00010082
[ 429.199475] RAX: 0000000000000006 RBX: 0000000000000000 RCX: 0000000000000001
[ 429.200173] RDX: ffff880137c10401 RSI: ffffffff81796bf9 RDI: 00000000ffffffff
[ 429.200871] RBP: ffff88009434f850 R08: 0000000000000001 R09: 0000000000000000
[ 429.201568] R10: ffff88009434f860 R11: 00000000ffffffff R12: 000000000203138a
[ 429.202272] R13: ffff880133001800 R14: 0000000000000000 R15: 0000000000000000
[ 429.202969] FS: 00007fa79ea77700(0000) GS:ffff880137c00000(0000) knlGS:0000000000000000
[ 429.203665] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 429.204363] CR2: 00000000015ec1c0 CR3: 00000000940a6000 CR4: 00000000000006f0
[ 429.205063] Stack:
[ 429.205760] 000000000203138a 0000000000000000 ffff880137c17e50 ffff880133001800
[ 429.206474] 0000000000000000 0000000000000000 ffff88009434f930 ffffffff81105467
[ 429.207197] ffffffff8105993f ffffffff810c7582 0000000100150015 0203138a00000001
[ 429.207914] Call Trace:
[ 429.208618] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.209328] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.210034] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.210739] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.211423] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.212102] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.212781] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.213446] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.214110] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.214771] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.215426] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.216078] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.216724] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.219914] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.220544] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.221170] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.221825] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.222456] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.223087] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.223718] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.224349] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.224979] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.225614] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.226236] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.226852] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.227464] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.228093] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.228699] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
[ 429.229308] Code: 5a 5b 41 5c 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 41 89 f4 81 e6 06 00 00 fc 53 51 74 0e 48 c7 c7 66 9a 75 81 e8 39 fe fb ff <0f> 0b 44 23 25 56 39 78 00 49 89 ff 4c 8b 6f 28 41 81 e4 e0 3e
[ 429.230077] RIP [<ffffffff811036a5>] new_slab+0x25/0x2be
[ 429.230739] RSP <ffff88009434f820>
[ 429.231392] ---[ end trace ddce043dc10fc3d2 ]---
[ 429.232059] BUG: sleeping function called from invalid context at include/linux/sched.h:2960
[ 429.232719] in_atomic(): 0, irqs_disabled(): 1, pid: 562, name: gzip
[ 429.233376] INFO: lockdep is turned off.
[ 429.234034] irq event stamp: 1994762
[ 429.234697] hardirqs last enabled at (1994761): [<ffffffff8113f360>] __find_get_block+0xd9/0x117
[ 429.235360] hardirqs last disabled at (1994762): [<ffffffff81105516>] __slab_alloc.isra.18.constprop.22+0x20/0x6d
[ 429.236026] softirqs last enabled at (1994554): [<ffffffff81040285>] __do_softirq+0x1bc/0x217
[ 429.236694] softirqs last disabled at (1994535): [<ffffffff810404ba>] irq_exit+0x3b/0x8f
[ 429.237360] CPU: 0 PID: 562 Comm: gzip Tainted: G D 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.238708] 0000000000000000 ffff88009434f520 ffffffff811e632c 0000000000000000
[ 429.239397] ffff8800bf8e3a80 ffff88009434f548 ffffffff810598c8 ffffffff8174b8c3
[ 429.240077] 0000000000000b90 0000000000000000 ffff88009434f570 ffffffff8105993f
[ 429.240757] Call Trace:
[ 429.241433] [<ffffffff811e632c>] dump_stack+0x68/0x92
[ 429.242113] [<ffffffff810598c8>] ___might_sleep+0x1fb/0x202
[ 429.242816] [<ffffffff8105993f>] __might_sleep+0x70/0x77
[ 429.243493] [<ffffffff810487a0>] exit_signals+0x1e/0x119
[ 429.244168] [<ffffffff8103eec3>] do_exit+0x111/0x8f8
[ 429.244844] [<ffffffff8107da75>] ? kmsg_dump+0x149/0x154
[ 429.245525] [<ffffffff81014a03>] oops_end+0x9d/0xa4
[ 429.246200] [<ffffffff81014b27>] die+0x55/0x5e
[ 429.246868] [<ffffffff81012450>] do_trap+0x67/0x11d
[ 429.247538] [<ffffffff8101272d>] do_error_trap+0x100/0x10f
[ 429.248212] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.248878] [<ffffffff8107c870>] ? wake_up_klogd+0x4e/0x61
[ 429.249544] [<ffffffff8107ccda>] ? console_unlock+0x457/0x4a2
[ 429.250202] [<ffffffff81001036>] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 429.250856] [<ffffffff81012889>] do_invalid_op+0x1b/0x1d
[ 429.251508] [<ffffffff814a5e25>] invalid_op+0x15/0x20
[ 429.252158] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.252803] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.253451] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.254102] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.254740] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.255376] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.256012] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.256657] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.257292] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.257959] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.258592] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.259226] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.259849] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.260432] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.261024] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.261614] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.262185] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.262753] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.263320] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.263887] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.264447] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.265017] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.265575] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.266135] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.266691] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.267240] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.267798] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.268345] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.268896] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.269438] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.269976] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.270518] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.271057] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
-ss
^ permalink raw reply [flat|nested] 17+ messages in thread
* [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
@ 2016-06-10 6:11 ` Sergey Senozhatsky
0 siblings, 0 replies; 17+ messages in thread
From: Sergey Senozhatsky @ 2016-06-10 6:11 UTC (permalink / raw)
To: Michal Hocko, Andrew Morton
Cc: Vlastimil Babka, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Sergey Senozhatsky, Sergey Senozhatsky
Hello,
[ 429.191962] gfp: 2
[ 429.192634] ------------[ cut here ]------------
[ 429.193281] kernel BUG at mm/slub.c:1616!
[ 429.193920] invalid opcode: 0000 [#1] PREEMPT SMP
[ 429.194556] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_timer snd soundcore coretemp hwmon mousedev r8169 i2c_i801 crc32c_intel mii lpc_ich mfd_core acpi_cpufreq processor sch_fq_codel uas usb_storage hid_generi
c usbhid hid sd_mod ahci libahci libata scsi_mod ehci_pci ehci_hcd usbcore usb_common
[ 429.196008] CPU: 0 PID: 562 Comm: gzip Not tainted 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.197385] task: ffff8800bf8e3a80 ti: ffff88009434c000 task.ti: ffff88009434c000
[ 429.198082] RIP: 0010:[<ffffffff811036a5>] [<ffffffff811036a5>] new_slab+0x25/0x2be
[ 429.198782] RSP: 0018:ffff88009434f820 EFLAGS: 00010082
[ 429.199475] RAX: 0000000000000006 RBX: 0000000000000000 RCX: 0000000000000001
[ 429.200173] RDX: ffff880137c10401 RSI: ffffffff81796bf9 RDI: 00000000ffffffff
[ 429.200871] RBP: ffff88009434f850 R08: 0000000000000001 R09: 0000000000000000
[ 429.201568] R10: ffff88009434f860 R11: 00000000ffffffff R12: 000000000203138a
[ 429.202272] R13: ffff880133001800 R14: 0000000000000000 R15: 0000000000000000
[ 429.202969] FS: 00007fa79ea77700(0000) GS:ffff880137c00000(0000) knlGS:0000000000000000
[ 429.203665] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 429.204363] CR2: 00000000015ec1c0 CR3: 00000000940a6000 CR4: 00000000000006f0
[ 429.205063] Stack:
[ 429.205760] 000000000203138a 0000000000000000 ffff880137c17e50 ffff880133001800
[ 429.206474] 0000000000000000 0000000000000000 ffff88009434f930 ffffffff81105467
[ 429.207197] ffffffff8105993f ffffffff810c7582 0000000100150015 0203138a00000001
[ 429.207914] Call Trace:
[ 429.208618] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.209328] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.210034] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.210739] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.211423] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.212102] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.212781] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.213446] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.214110] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.214771] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.215426] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.216078] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.216724] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.219914] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.220544] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.221170] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.221825] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.222456] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.223087] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.223718] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.224349] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.224979] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.225614] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.226236] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.226852] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.227464] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.228093] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.228699] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
[ 429.229308] Code: 5a 5b 41 5c 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 41 89 f4 81 e6 06 00 00 fc 53 51 74 0e 48 c7 c7 66 9a 75 81 e8 39 fe fb ff <0f> 0b 44 23 25 56 39 78 00 49 89 ff 4c 8b 6f 28 41 81 e4 e0 3e
[ 429.230077] RIP [<ffffffff811036a5>] new_slab+0x25/0x2be
[ 429.230739] RSP <ffff88009434f820>
[ 429.231392] ---[ end trace ddce043dc10fc3d2 ]---
[ 429.232059] BUG: sleeping function called from invalid context at include/linux/sched.h:2960
[ 429.232719] in_atomic(): 0, irqs_disabled(): 1, pid: 562, name: gzip
[ 429.233376] INFO: lockdep is turned off.
[ 429.234034] irq event stamp: 1994762
[ 429.234697] hardirqs last enabled at (1994761): [<ffffffff8113f360>] __find_get_block+0xd9/0x117
[ 429.235360] hardirqs last disabled at (1994762): [<ffffffff81105516>] __slab_alloc.isra.18.constprop.22+0x20/0x6d
[ 429.236026] softirqs last enabled at (1994554): [<ffffffff81040285>] __do_softirq+0x1bc/0x217
[ 429.236694] softirqs last disabled at (1994535): [<ffffffff810404ba>] irq_exit+0x3b/0x8f
[ 429.237360] CPU: 0 PID: 562 Comm: gzip Tainted: G D 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.238708] 0000000000000000 ffff88009434f520 ffffffff811e632c 0000000000000000
[ 429.239397] ffff8800bf8e3a80 ffff88009434f548 ffffffff810598c8 ffffffff8174b8c3
[ 429.240077] 0000000000000b90 0000000000000000 ffff88009434f570 ffffffff8105993f
[ 429.240757] Call Trace:
[ 429.241433] [<ffffffff811e632c>] dump_stack+0x68/0x92
[ 429.242113] [<ffffffff810598c8>] ___might_sleep+0x1fb/0x202
[ 429.242816] [<ffffffff8105993f>] __might_sleep+0x70/0x77
[ 429.243493] [<ffffffff810487a0>] exit_signals+0x1e/0x119
[ 429.244168] [<ffffffff8103eec3>] do_exit+0x111/0x8f8
[ 429.244844] [<ffffffff8107da75>] ? kmsg_dump+0x149/0x154
[ 429.245525] [<ffffffff81014a03>] oops_end+0x9d/0xa4
[ 429.246200] [<ffffffff81014b27>] die+0x55/0x5e
[ 429.246868] [<ffffffff81012450>] do_trap+0x67/0x11d
[ 429.247538] [<ffffffff8101272d>] do_error_trap+0x100/0x10f
[ 429.248212] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.248878] [<ffffffff8107c870>] ? wake_up_klogd+0x4e/0x61
[ 429.249544] [<ffffffff8107ccda>] ? console_unlock+0x457/0x4a2
[ 429.250202] [<ffffffff81001036>] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 429.250856] [<ffffffff81012889>] do_invalid_op+0x1b/0x1d
[ 429.251508] [<ffffffff814a5e25>] invalid_op+0x15/0x20
[ 429.252158] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.252803] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.253451] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.254102] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.254740] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.255376] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.256012] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.256657] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.257292] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.257959] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.258592] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.259226] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.259849] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.260432] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.261024] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.261614] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.262185] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.262753] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.263320] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.263887] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.264447] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.265017] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.265575] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.266135] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.266691] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.267240] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.267798] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.268345] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.268896] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.269438] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.269976] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.270518] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.271057] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
2016-06-10 6:11 ` Sergey Senozhatsky
@ 2016-06-10 6:34 ` Michal Hocko
-1 siblings, 0 replies; 17+ messages in thread
From: Michal Hocko @ 2016-06-10 6:34 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky
On Fri 10-06-16 15:11:39, Sergey Senozhatsky wrote:
> Hello,
>
> [ 429.191962] gfp: 2
> [ 429.192634] ------------[ cut here ]------------
> [ 429.193281] kernel BUG at mm/slub.c:1616!
[...]
> [ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
> [ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
> [ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
> [ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
___GFP_HIGHMEM. It is my [1] patch which has introduced it.
I think we need the following. Andrew could you fold it into
mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
it as a separate patch?
[1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
Thanks for the report Sergey!
---
>From 89cfc9bf27b9b5af47fece7eab36deb2fb04516d Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Fri, 10 Jun 2016 08:27:33 +0200
Subject: [PATCH] mm: restrict gfp mask in mpage_alloc
Sergey has reported that we might hit BUG_ON in new_slab() because
unrestricted gfp mask used for the readahead purposes contains
incompatible flags (__GFP_HIGHMEM in his case):
[ 429.191962] gfp: 2
[ 429.192634] ------------[ cut here ]------------
[ 429.193281] kernel BUG at mm/slub.c:1616!
[...]
[ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
Make sure that mpage_alloc always restricts the mask GFP_KERNEL subset.
This is what was done before "mm, memcg: use consistent gfp flags during
readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
mpage_readpages.
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
fs/mpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/mpage.c b/fs/mpage.c
index 9c11255b0797..5ce75b2e60d1 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -71,7 +71,7 @@ mpage_alloc(struct block_device *bdev,
{
struct bio *bio;
- bio = bio_alloc(gfp_flags, nr_vecs);
+ bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
while (!bio && (nr_vecs /= 2))
--
2.8.1
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
@ 2016-06-10 6:34 ` Michal Hocko
0 siblings, 0 replies; 17+ messages in thread
From: Michal Hocko @ 2016-06-10 6:34 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky
On Fri 10-06-16 15:11:39, Sergey Senozhatsky wrote:
> Hello,
>
> [ 429.191962] gfp: 2
> [ 429.192634] ------------[ cut here ]------------
> [ 429.193281] kernel BUG at mm/slub.c:1616!
[...]
> [ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
> [ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
> [ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
> [ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
___GFP_HIGHMEM. It is my [1] patch which has introduced it.
I think we need the following. Andrew could you fold it into
mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
it as a separate patch?
[1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
Thanks for the report Sergey!
---
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
2016-06-10 6:34 ` Michal Hocko
@ 2016-06-10 7:24 ` Sergey Senozhatsky
-1 siblings, 0 replies; 17+ messages in thread
From: Sergey Senozhatsky @ 2016-06-10 7:24 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky
that was fast!
On (06/10/16 08:34), Michal Hocko wrote:
[..]
> OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> I think we need the following. Andrew could you fold it into
> mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> it as a separate patch?
>
> [1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
>
> Thanks for the report Sergey!
after quick tests -- works for me. please see below.
> Sergey has reported that we might hit BUG_ON in new_slab() because
> unrestricted gfp mask used for the readahead purposes contains
> incompatible flags (__GFP_HIGHMEM in his case):
> [ 429.191962] gfp: 2
> [ 429.192634] ------------[ cut here ]------------
> [ 429.193281] kernel BUG at mm/slub.c:1616!
> [...]
> [ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
> [ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
> [ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
> [ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
>
> Make sure that mpage_alloc always restricts the mask GFP_KERNEL subset.
> This is what was done before "mm, memcg: use consistent gfp flags during
> readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
> mpage_readpages.
>
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> fs/mpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/mpage.c b/fs/mpage.c
> index 9c11255b0797..5ce75b2e60d1 100644
> --- a/fs/mpage.c
> +++ b/fs/mpage.c
> @@ -71,7 +71,7 @@ mpage_alloc(struct block_device *bdev,
> {
> struct bio *bio;
>
> - bio = bio_alloc(gfp_flags, nr_vecs);
> + bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
>
> if (bio == NULL && (current->flags & PF_MEMALLOC)) {
> while (!bio && (nr_vecs /= 2))
so the first bio_alloc() is ok now. what about the second bio_alloc()
in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?
may be something like this (composed in mail client)
static struct bio *
mpage_alloc(struct block_device *bdev,
sector_t first_sector, int nr_vecs,
gfp_t gfp_flags)
{
struct bio *bio;
+ gfp_flags &= GFP_KERNEL;
- bio = bio_alloc(gfp_flags, nr_vecs);
+ bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
while (!bio && (nr_vecs /= 2))
bio = bio_alloc(gfp_flags, nr_vecs);
^^^^^^^^^^^^^^^^^^^^ BUG?
}
if (bio) {
bio->bi_bdev = bdev;
bio->bi_iter.bi_sector = first_sector;
}
return bio;
}
=====
the second part of the original report (sleeping function called from
invalid context at include/linux/sched.h:2960) is unrelated, I'll fork
a new thread; seems that it's coming from a380a3c755, Christoph Lameter,
2015-11-20.
-ss
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
@ 2016-06-10 7:24 ` Sergey Senozhatsky
0 siblings, 0 replies; 17+ messages in thread
From: Sergey Senozhatsky @ 2016-06-10 7:24 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky
that was fast!
On (06/10/16 08:34), Michal Hocko wrote:
[..]
> OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> I think we need the following. Andrew could you fold it into
> mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> it as a separate patch?
>
> [1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
>
> Thanks for the report Sergey!
after quick tests -- works for me. please see below.
> Sergey has reported that we might hit BUG_ON in new_slab() because
> unrestricted gfp mask used for the readahead purposes contains
> incompatible flags (__GFP_HIGHMEM in his case):
> [ 429.191962] gfp: 2
> [ 429.192634] ------------[ cut here ]------------
> [ 429.193281] kernel BUG at mm/slub.c:1616!
> [...]
> [ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
> [ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
> [ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
> [ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
>
> Make sure that mpage_alloc always restricts the mask GFP_KERNEL subset.
> This is what was done before "mm, memcg: use consistent gfp flags during
> readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
> mpage_readpages.
>
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> fs/mpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/mpage.c b/fs/mpage.c
> index 9c11255b0797..5ce75b2e60d1 100644
> --- a/fs/mpage.c
> +++ b/fs/mpage.c
> @@ -71,7 +71,7 @@ mpage_alloc(struct block_device *bdev,
> {
> struct bio *bio;
>
> - bio = bio_alloc(gfp_flags, nr_vecs);
> + bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
>
> if (bio == NULL && (current->flags & PF_MEMALLOC)) {
> while (!bio && (nr_vecs /= 2))
so the first bio_alloc() is ok now. what about the second bio_alloc()
in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?
may be something like this (composed in mail client)
static struct bio *
mpage_alloc(struct block_device *bdev,
sector_t first_sector, int nr_vecs,
gfp_t gfp_flags)
{
struct bio *bio;
+ gfp_flags &= GFP_KERNEL;
- bio = bio_alloc(gfp_flags, nr_vecs);
+ bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
while (!bio && (nr_vecs /= 2))
bio = bio_alloc(gfp_flags, nr_vecs);
^^^^^^^^^^^^^^^^^^^^ BUG?
}
if (bio) {
bio->bi_bdev = bdev;
bio->bi_iter.bi_sector = first_sector;
}
return bio;
}
=====
the second part of the original report (sleeping function called from
invalid context at include/linux/sched.h:2960) is unrelated, I'll fork
a new thread; seems that it's coming from a380a3c755, Christoph Lameter,
2015-11-20.
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
2016-06-10 7:24 ` Sergey Senozhatsky
@ 2016-06-10 7:42 ` Michal Hocko
-1 siblings, 0 replies; 17+ messages in thread
From: Michal Hocko @ 2016-06-10 7:42 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky
On Fri 10-06-16 16:24:59, Sergey Senozhatsky wrote:
> that was fast!
>
> On (06/10/16 08:34), Michal Hocko wrote:
> [..]
> > OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> > ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> > I think we need the following. Andrew could you fold it into
> > mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> > it as a separate patch?
> >
> > [1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
> >
> > Thanks for the report Sergey!
>
> after quick tests -- works for me. please see below.
[...]
> so the first bio_alloc() is ok now. what about the second bio_alloc()
> in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?
Sure, early morning for me... Thanks for catching that.
---
>From a2712312c0a36506ba003747c593dfbdf8eaa8be Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Fri, 10 Jun 2016 08:27:33 +0200
Subject: [PATCH] mm: restrict gfp mask in mpage_alloc
Sergey has reported that we might hit BUG_ON in new_slab() because
unrestricted gfp mask used for the readahead purposes contains
incompatible flags (__GFP_HIGHMEM in his case):
[ 429.191962] gfp: 2
[ 429.192634] ------------[ cut here ]------------
[ 429.193281] kernel BUG at mm/slub.c:1616!
[...]
[ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
Make sure that mpage_alloc always restricts the mask to GFP_KERNEL subset.
This is what was done before "mm, memcg: use consistent gfp flags during
readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
mpage_readpages.
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
fs/mpage.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/mpage.c b/fs/mpage.c
index 9c11255b0797..c8a05901a37b 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -71,6 +71,8 @@ mpage_alloc(struct block_device *bdev,
{
struct bio *bio;
+ /* Restrict the given (page cache) mask for slab allocations */
+ gfp_flags &= GFP_KERNEL;
bio = bio_alloc(gfp_flags, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
--
2.8.1
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
@ 2016-06-10 7:42 ` Michal Hocko
0 siblings, 0 replies; 17+ messages in thread
From: Michal Hocko @ 2016-06-10 7:42 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky
On Fri 10-06-16 16:24:59, Sergey Senozhatsky wrote:
> that was fast!
>
> On (06/10/16 08:34), Michal Hocko wrote:
> [..]
> > OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> > ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> > I think we need the following. Andrew could you fold it into
> > mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> > it as a separate patch?
> >
> > [1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
> >
> > Thanks for the report Sergey!
>
> after quick tests -- works for me. please see below.
[...]
> so the first bio_alloc() is ok now. what about the second bio_alloc()
> in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?
Sure, early morning for me... Thanks for catching that.
---
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
2016-06-10 6:11 ` Sergey Senozhatsky
(?)
(?)
@ 2016-06-10 9:50 ` Sergey Senozhatsky
2016-06-10 9:55 ` mhocko
-1 siblings, 1 reply; 17+ messages in thread
From: Sergey Senozhatsky @ 2016-06-10 9:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: Michal Hocko, Andrew Morton, Vlastimil Babka, Stephen Rothwell,
linux-mm, linux-next, linux-kernel, Sergey Senozhatsky,
Sergey Senozhatsky
Hello,
forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
new_slab()->BUG->die()->exit_signals() can be called from atomic
context: local IRQs disabled in slab_alloc().
[ 429.232059] BUG: sleeping function called from invalid context at include/linux/sched.h:2960
[ 429.232719] in_atomic(): 0, irqs_disabled(): 1, pid: 562, name: gzip
[ 429.233376] INFO: lockdep is turned off.
[ 429.234034] irq event stamp: 1994762
[ 429.234697] hardirqs last enabled at (1994761): [<ffffffff8113f360>] __find_get_block+0xd9/0x117
[ 429.235360] hardirqs last disabled at (1994762): [<ffffffff81105516>] __slab_alloc.isra.18.constprop.22+0x20/0x6d
[ 429.236026] softirqs last enabled at (1994554): [<ffffffff81040285>] __do_softirq+0x1bc/0x217
[ 429.236694] softirqs last disabled at (1994535): [<ffffffff810404ba>] irq_exit+0x3b/0x8f
[ 429.237360] CPU: 0 PID: 562 Comm: gzip Tainted: G D 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.238708] 0000000000000000 ffff88009434f520 ffffffff811e632c 0000000000000000
[ 429.239397] ffff8800bf8e3a80 ffff88009434f548 ffffffff810598c8 ffffffff8174b8c3
[ 429.240077] 0000000000000b90 0000000000000000 ffff88009434f570 ffffffff8105993f
[ 429.240757] Call Trace:
[ 429.241433] [<ffffffff811e632c>] dump_stack+0x68/0x92
[ 429.242113] [<ffffffff810598c8>] ___might_sleep+0x1fb/0x202
[ 429.242816] [<ffffffff8105993f>] __might_sleep+0x70/0x77
[ 429.243493] [<ffffffff810487a0>] exit_signals+0x1e/0x119
[ 429.244168] [<ffffffff8103eec3>] do_exit+0x111/0x8f8
[ 429.244844] [<ffffffff8107da75>] ? kmsg_dump+0x149/0x154
[ 429.245525] [<ffffffff81014a03>] oops_end+0x9d/0xa4
[ 429.246200] [<ffffffff81014b27>] die+0x55/0x5e
[ 429.246868] [<ffffffff81012450>] do_trap+0x67/0x11d
[ 429.247538] [<ffffffff8101272d>] do_error_trap+0x100/0x10f
[ 429.248212] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.248878] [<ffffffff8107c870>] ? wake_up_klogd+0x4e/0x61
[ 429.249544] [<ffffffff8107ccda>] ? console_unlock+0x457/0x4a2
[ 429.250202] [<ffffffff81001036>] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 429.250856] [<ffffffff81012889>] do_invalid_op+0x1b/0x1d
[ 429.251508] [<ffffffff814a5e25>] invalid_op+0x15/0x20
[ 429.252158] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.252803] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.253451] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.254102] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.254740] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.255376] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.256012] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.256657] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.257292] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.257959] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.258592] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.259226] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.259849] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.260432] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.261024] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.261614] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.262185] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.262753] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.263320] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.263887] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.264447] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.265017] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.265575] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.266135] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.266691] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.267240] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.267798] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.268345] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.268896] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.269438] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.269976] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.270518] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.271057] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
-ss
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
2016-06-10 9:50 ` [mmots-2016-06-09-16-49] sleeping function called from slab_alloc() Sergey Senozhatsky
@ 2016-06-10 9:55 ` mhocko
0 siblings, 0 replies; 17+ messages in thread
From: mhocko @ 2016-06-10 9:55 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Christoph Lameter, Michal Hocko, Andrew Morton, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky, linux-kernel-owner
On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> Hello,
>
> forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
>
> new_slab()->BUG->die()->exit_signals() can be called from atomic
> context: local IRQs disabled in slab_alloc().
I have sent a patch to drop the BUG() from that path today. It
is just too aggressive way to react to a non-critical bug.
See
http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
--
Michal Hocko
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
@ 2016-06-10 9:55 ` mhocko
0 siblings, 0 replies; 17+ messages in thread
From: mhocko @ 2016-06-10 9:55 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Christoph Lameter, Michal Hocko, Andrew Morton, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky, linux-kernel-owner
On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> Hello,
>
> forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
>
> new_slab()->BUG->die()->exit_signals() can be called from atomic
> context: local IRQs disabled in slab_alloc().
I have sent a patch to drop the BUG() from that path today. It
is just too aggressive way to react to a non-critical bug.
See
http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
--
Michal Hocko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
2016-06-10 9:55 ` mhocko
@ 2016-06-10 9:58 ` Sergey Senozhatsky
-1 siblings, 0 replies; 17+ messages in thread
From: Sergey Senozhatsky @ 2016-06-10 9:58 UTC (permalink / raw)
To: mhocko
Cc: Sergey Senozhatsky, Christoph Lameter, Michal Hocko,
Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky, linux-kernel-owner
On (06/10/16 11:55), mhocko wrote:
> On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > Hello,
> >
> > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> >
> > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > context: local IRQs disabled in slab_alloc().
>
> I have sent a patch to drop the BUG() from that path today. It
> is just too aggressive way to react to a non-critical bug.
> See
> http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
ah, ok. didn't see that one.
thanks.
-ss
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
@ 2016-06-10 9:58 ` Sergey Senozhatsky
0 siblings, 0 replies; 17+ messages in thread
From: Sergey Senozhatsky @ 2016-06-10 9:58 UTC (permalink / raw)
To: mhocko
Cc: Sergey Senozhatsky, Christoph Lameter, Michal Hocko,
Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky, linux-kernel-owner
On (06/10/16 11:55), mhocko wrote:
> On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > Hello,
> >
> > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> >
> > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > context: local IRQs disabled in slab_alloc().
>
> I have sent a patch to drop the BUG() from that path today. It
> is just too aggressive way to react to a non-critical bug.
> See
> http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
ah, ok. didn't see that one.
thanks.
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
2016-06-10 9:55 ` mhocko
@ 2016-06-10 21:59 ` Andrew Morton
-1 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2016-06-10 21:59 UTC (permalink / raw)
To: mhocko
Cc: Sergey Senozhatsky, Christoph Lameter, Michal Hocko,
Vlastimil Babka, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Sergey Senozhatsky, linux-kernel-owner
On Fri, 10 Jun 2016 11:55:54 +0200 mhocko <mhocko@suse.de> wrote:
> On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > Hello,
> >
> > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> >
> > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > context: local IRQs disabled in slab_alloc().
>
> I have sent a patch to drop the BUG() from that path today. It
> is just too aggressive way to react to a non-critical bug.
> See
> http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
Doesn't this simply mean that Sergey's workload will blurt a pr_warn()
rather than a BUG()? That still needs fixing. Confused.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
@ 2016-06-10 21:59 ` Andrew Morton
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2016-06-10 21:59 UTC (permalink / raw)
To: mhocko
Cc: Sergey Senozhatsky, Christoph Lameter, Michal Hocko,
Vlastimil Babka, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Sergey Senozhatsky, linux-kernel-owner
On Fri, 10 Jun 2016 11:55:54 +0200 mhocko <mhocko@suse.de> wrote:
> On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > Hello,
> >
> > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> >
> > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > context: local IRQs disabled in slab_alloc().
>
> I have sent a patch to drop the BUG() from that path today. It
> is just too aggressive way to react to a non-critical bug.
> See
> http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
Doesn't this simply mean that Sergey's workload will blurt a pr_warn()
rather than a BUG()? That still needs fixing. Confused.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
2016-06-10 21:59 ` Andrew Morton
@ 2016-06-13 10:47 ` Michal Hocko
-1 siblings, 0 replies; 17+ messages in thread
From: Michal Hocko @ 2016-06-13 10:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Sergey Senozhatsky, Christoph Lameter, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky, linux-kernel-owner
On Fri 10-06-16 14:59:16, Andrew Morton wrote:
> On Fri, 10 Jun 2016 11:55:54 +0200 mhocko <mhocko@suse.de> wrote:
>
> > On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > > Hello,
> > >
> > > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> > >
> > > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > > context: local IRQs disabled in slab_alloc().
> >
> > I have sent a patch to drop the BUG() from that path today. It
> > is just too aggressive way to react to a non-critical bug.
> > See
> > http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
>
> Doesn't this simply mean that Sergey's workload will blurt a pr_warn()
> rather than a BUG()? That still needs fixing. Confused.
Yes that should be fixed by
http://lkml.kernel.org/r/20160610074223.GC32285@dhcp22.suse.cz
which prevents from using a wrong GFP...
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
@ 2016-06-13 10:47 ` Michal Hocko
0 siblings, 0 replies; 17+ messages in thread
From: Michal Hocko @ 2016-06-13 10:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Sergey Senozhatsky, Christoph Lameter, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky, linux-kernel-owner
On Fri 10-06-16 14:59:16, Andrew Morton wrote:
> On Fri, 10 Jun 2016 11:55:54 +0200 mhocko <mhocko@suse.de> wrote:
>
> > On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > > Hello,
> > >
> > > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> > >
> > > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > > context: local IRQs disabled in slab_alloc().
> >
> > I have sent a patch to drop the BUG() from that path today. It
> > is just too aggressive way to react to a non-critical bug.
> > See
> > http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
>
> Doesn't this simply mean that Sergey's workload will blurt a pr_warn()
> rather than a BUG()? That still needs fixing. Confused.
Yes that should be fixed by
http://lkml.kernel.org/r/20160610074223.GC32285@dhcp22.suse.cz
which prevents from using a wrong GFP...
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-06-13 10:47 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-10 6:11 [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616 Sergey Senozhatsky
2016-06-10 6:11 ` Sergey Senozhatsky
2016-06-10 6:34 ` Michal Hocko
2016-06-10 6:34 ` Michal Hocko
2016-06-10 7:24 ` Sergey Senozhatsky
2016-06-10 7:24 ` Sergey Senozhatsky
2016-06-10 7:42 ` Michal Hocko
2016-06-10 7:42 ` Michal Hocko
2016-06-10 9:50 ` [mmots-2016-06-09-16-49] sleeping function called from slab_alloc() Sergey Senozhatsky
2016-06-10 9:55 ` mhocko
2016-06-10 9:55 ` mhocko
2016-06-10 9:58 ` Sergey Senozhatsky
2016-06-10 9:58 ` Sergey Senozhatsky
2016-06-10 21:59 ` Andrew Morton
2016-06-10 21:59 ` Andrew Morton
2016-06-13 10:47 ` Michal Hocko
2016-06-13 10:47 ` Michal Hocko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.