[Kgdb-bugreport] [BUG] kgdb/ftrace - sleeping in invalid context
Hi, I've been poking around KGDB, and I noticed that the KDB 'ftdump' command (to dump ftrace logs) produces warnings like this: (gdb) monitor ftdump Dumping ftrace buffer: BUG: sleeping function called from invalid context at mm/slab.h:359 in_atomic(): 1, irqs_disabled(): 128, pid: 116, name: irq/65-chromeos CPU: 4 PID: 116 Comm: irq/65-chromeos Not tainted 4.4.21 #575 Call trace: [] dump_backtrace+0x0/0x160 [] show_stack+0x20/0x28 [] dump_stack+0x90/0xb0 [] ___might_sleep+0x140/0x14c [] __might_sleep+0x80/0x90 [] kmem_cache_alloc_trace+0x5c/0x238 [] ring_buffer_read_prepare+0x4c/0xa4 [] kdb_ftdump+0x200/0x3e4 [] kdb_parse+0x548/0x628 [] gdb_serial_stub+0x89c/0xaac [] kgdb_cpu_enter+0x1e0/0x5b0 [] kgdb_handle_exception+0x1a0/0x1e4 [] kgdb_compiled_brk_fn+0x30/0x3c [] brk_handler+0x9c/0xb0 [] do_debug_exception+0x60/0xe0 Exception stack(0xffc0ecffb820 to 0xffc0ecffb950) b820: ffc0010a6000 0080 ffc0ecffba10 ffc0002bf020 b840: 61c5 ffc0ecffb870 00018160 b860: 0003 00c3 ffc000be15b9 ffc000be7053 b880: 0005 ffc0010a6c48 ffc0ecffb930 ffc00026f8e8 b8a0: ffc000c362ca ffc00108c000 ffc00026f880 0001 b8c0: 0007 ffc0ecfb6600 0001 cb88537fdc8ba615 b8e0: ffc0011b6430 0001 ffc0011b6438 b900: 0006 ffc0010cc1c0 b920: ffc00043eed8 7f7f7f7f 681f39616369ff46 7f7f7f7f7f7f7f7f b940: 0101010101010101 0008 [] el1_dbg+0x18/0x74 [] sysrq_handle_dbg+0x54/0x5c [] __handle_sysrq+0xa4/0x15c [] sysrq_filter+0x11c/0x348 [] input_to_handler+0x60/0x100 [] input_pass_values.part.2+0x78/0x144 [] input_handle_event+0x280/0x4d4 [] input_event+0x70/0x8c [...] It looks like (almost?) all KDB code gets run in an exception context, so I don't see how sleeping allocations (such as those in ring_buffer_read_prepare()) are supposed to be able to work if they don't immediately find enough memory. I can't think of a great simple fix for this, other than borrowing the hack from kdb_private.h: #define GFP_KDB (in_interrupt() ? GFP_ATOMIC : GFP_KERNEL) AFAICT, the necessary allocations are all pretty small actually, and so GFP_ATOMIC may not be a problem, even in the non-KDB ring buffer case. Thoughts? I figured I'd ask questions before blindly sending patches, as I'm not very familiar with this code. Regards, Brian -- ___ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
Re: [Kgdb-bugreport] [BUG] kgdb/ftrace - sleeping in invalid context
On 11/17/2016 01:16 PM, Brian Norris wrote: > Hi, > > I've been poking around KGDB, and I noticed that the KDB 'ftdump' > command (to dump ftrace logs) produces warnings like this: > > (gdb) monitor ftdump > Dumping ftrace buffer: > BUG: sleeping function called from invalid context at mm/slab.h:359 > in_atomic(): 1, irqs_disabled(): 128, pid: 116, name: irq/65-chromeos > CPU: 4 PID: 116 Comm: irq/65-chromeos Not tainted 4.4.21 #575 > Call trace: > [] dump_backtrace+0x0/0x160 > [] show_stack+0x20/0x28 > [] dump_stack+0x90/0xb0 > [] ___might_sleep+0x140/0x14c > [] __might_sleep+0x80/0x90 > [] kmem_cache_alloc_trace+0x5c/0x238 > [] ring_buffer_read_prepare+0x4c/0xa4 > [] kdb_ftdump+0x200/0x3e4 > [] kdb_parse+0x548/0x628 > [] gdb_serial_stub+0x89c/0xaac > [] kgdb_cpu_enter+0x1e0/0x5b0 > [] kgdb_handle_exception+0x1a0/0x1e4 > [] kgdb_compiled_brk_fn+0x30/0x3c > [] brk_handler+0x9c/0xb0 > [] do_debug_exception+0x60/0xe0 > Exception stack(0xffc0ecffb820 to 0xffc0ecffb950) > b820: ffc0010a6000 0080 ffc0ecffba10 ffc0002bf020 > b840: 61c5 ffc0ecffb870 00018160 > b860: 0003 00c3 ffc000be15b9 ffc000be7053 > b880: 0005 ffc0010a6c48 ffc0ecffb930 ffc00026f8e8 > b8a0: ffc000c362ca ffc00108c000 ffc00026f880 0001 > b8c0: 0007 ffc0ecfb6600 0001 cb88537fdc8ba615 > b8e0: ffc0011b6430 0001 ffc0011b6438 > b900: 0006 ffc0010cc1c0 > b920: ffc00043eed8 7f7f7f7f 681f39616369ff46 7f7f7f7f7f7f7f7f > b940: 0101010101010101 0008 > [] el1_dbg+0x18/0x74 > [] sysrq_handle_dbg+0x54/0x5c > [] __handle_sysrq+0xa4/0x15c > [] sysrq_filter+0x11c/0x348 > [] input_to_handler+0x60/0x100 > [] input_pass_values.part.2+0x78/0x144 > [] input_handle_event+0x280/0x4d4 > [] input_event+0x70/0x8c > [...] > > It looks like (almost?) all KDB code gets run in an exception context, > so I don't see how sleeping allocations (such as those in > ring_buffer_read_prepare()) are supposed to be able to work if they > don't immediately find enough memory. > > I can't think of a great simple fix for this, other than borrowing the > hack from kdb_private.h: > > #define GFP_KDB (in_interrupt() ? GFP_ATOMIC : GFP_KERNEL) > > AFAICT, the necessary allocations are all pretty small actually, and so > GFP_ATOMIC may not be a problem, even in the non-KDB ring buffer case. > > Thoughts? I figured I'd ask questions before blindly sending patches, as > I'm not very familiar with this code. In the past some buffers had be pre-allocated outside of the exception context in order to properly dump the ftrace code. Perhaps these patches were lost or the interface changed slightly over time. Certainly we should never perform allocations while in the exception context. Cheers, Jason. -- ___ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
Re: [Kgdb-bugreport] [BUG] kgdb/ftrace - sleeping in invalid context
On Thu, 17 Nov 2016 11:16:06 -0800 Brian Norris wrote: > Hi, > > I've been poking around KGDB, and I noticed that the KDB 'ftdump' > command (to dump ftrace logs) produces warnings like this: > > (gdb) monitor ftdump > Dumping ftrace buffer: > BUG: sleeping function called from invalid context at mm/slab.h:359 > in_atomic(): 1, irqs_disabled(): 128, pid: 116, name: irq/65-chromeos > CPU: 4 PID: 116 Comm: irq/65-chromeos Not tainted 4.4.21 #575 > Call trace: > [] dump_backtrace+0x0/0x160 > [] show_stack+0x20/0x28 > [] dump_stack+0x90/0xb0 > [] ___might_sleep+0x140/0x14c > [] __might_sleep+0x80/0x90 > [] kmem_cache_alloc_trace+0x5c/0x238 > [] ring_buffer_read_prepare+0x4c/0xa4 > [] kdb_ftdump+0x200/0x3e4 > [] kdb_parse+0x548/0x628 > [] gdb_serial_stub+0x89c/0xaac > [] kgdb_cpu_enter+0x1e0/0x5b0 > [] kgdb_handle_exception+0x1a0/0x1e4 > [] kgdb_compiled_brk_fn+0x30/0x3c > [] brk_handler+0x9c/0xb0 > [] do_debug_exception+0x60/0xe0 > Exception stack(0xffc0ecffb820 to 0xffc0ecffb950) > b820: ffc0010a6000 0080 ffc0ecffba10 ffc0002bf020 > b840: 61c5 ffc0ecffb870 00018160 > b860: 0003 00c3 ffc000be15b9 ffc000be7053 > b880: 0005 ffc0010a6c48 ffc0ecffb930 ffc00026f8e8 > b8a0: ffc000c362ca ffc00108c000 ffc00026f880 0001 > b8c0: 0007 ffc0ecfb6600 0001 cb88537fdc8ba615 > b8e0: ffc0011b6430 0001 ffc0011b6438 > b900: 0006 ffc0010cc1c0 > b920: ffc00043eed8 7f7f7f7f 681f39616369ff46 7f7f7f7f7f7f7f7f > b940: 0101010101010101 0008 > [] el1_dbg+0x18/0x74 > [] sysrq_handle_dbg+0x54/0x5c > [] __handle_sysrq+0xa4/0x15c > [] sysrq_filter+0x11c/0x348 > [] input_to_handler+0x60/0x100 > [] input_pass_values.part.2+0x78/0x144 > [] input_handle_event+0x280/0x4d4 > [] input_event+0x70/0x8c > [...] > > It looks like (almost?) all KDB code gets run in an exception context, > so I don't see how sleeping allocations (such as those in > ring_buffer_read_prepare()) are supposed to be able to work if they > don't immediately find enough memory. > > I can't think of a great simple fix for this, other than borrowing the > hack from kdb_private.h: > > #define GFP_KDB (in_interrupt() ? GFP_ATOMIC : GFP_KERNEL) > > AFAICT, the necessary allocations are all pretty small actually, and so > GFP_ATOMIC may not be a problem, even in the non-KDB ring buffer case. > > Thoughts? I figured I'd ask questions before blindly sending patches, as > I'm not very familiar with this code. The better answer is to either preallocate the buffer a head of time, or follow what ftrace_dump() does, and create your own iterator. -- Steve -- ___ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
