All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] tracing: use GFP_ATOMIC in graph_trace_open()
@ 2015-04-13 19:35 Rabin Vincent
  2015-04-13 20:07 ` Steven Rostedt
  0 siblings, 1 reply; 3+ messages in thread
From: Rabin Vincent @ 2015-04-13 19:35 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: linux-kernel, Rabin Vincent

graph_trace_open() can be called in atomic context from ftrace_dump().
Use GFP_ATOMIC to avoid the following splat when that happens.

 BUG: sleeping function called from invalid context at mm/slab.c:2849
 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
 Backtrace:
 ..
 [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238)
  r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0
 [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0)
  r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8
  r4:810d16f0
 [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c)
  r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30
 [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec)
  r4:810d2580 r3:00000000
 [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20)
  r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a
  r4:808d5394
 [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18)
 [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
  r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210
 [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
 [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18)
  r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60
  r4:8454fe00
 [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c)
  r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60
  r4:84f01e00
 [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac)
  r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000
 [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c)
  r6:00000026 r5:00000000 r4:00000026 r3:8007a938
 [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc)
  r4:808c1e38 r3:0000002e
 [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c)
  r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015
  r4:8880210c r3:808c7ef0
 [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c)

Signed-off-by: Rabin Vincent <rabin@rab.in>
---
 kernel/trace/trace_functions_graph.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index 2d25ad1..a610872 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -1313,11 +1313,11 @@ void graph_trace_open(struct trace_iterator *iter)
 
 	iter->private = NULL;
 
-	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	data = kzalloc(sizeof(*data), GFP_ATOMIC);
 	if (!data)
 		goto out_err;
 
-	data->cpu_data = alloc_percpu(struct fgraph_cpu_data);
+	data->cpu_data = alloc_percpu_gfp(struct fgraph_cpu_data, GFP_ATOMIC);
 	if (!data->cpu_data)
 		goto out_err_free;
 
-- 
2.1.4


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] tracing: use GFP_ATOMIC in graph_trace_open()
  2015-04-13 19:35 [PATCH] tracing: use GFP_ATOMIC in graph_trace_open() Rabin Vincent
@ 2015-04-13 20:07 ` Steven Rostedt
  2015-04-13 20:30   ` [PATCHv2] tracing: handle atomic context " Rabin Vincent
  0 siblings, 1 reply; 3+ messages in thread
From: Steven Rostedt @ 2015-04-13 20:07 UTC (permalink / raw)
  To: Rabin Vincent; +Cc: linux-kernel

On Mon, 13 Apr 2015 21:35:21 +0200
Rabin Vincent <rabin@rab.in> wrote:

> graph_trace_open() can be called in atomic context from ftrace_dump().
> Use GFP_ATOMIC to avoid the following splat when that happens.
> 
>  BUG: sleeping function called from invalid context at mm/slab.c:2849
>  in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
>  Backtrace:

Interesting.

>  ..
>  [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238)
>   r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0
>  [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0)
>   r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8
>   r4:810d16f0
>  [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c)
>   r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30
>  [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec)
>   r4:810d2580 r3:00000000
>  [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20)
>   r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a
>   r4:808d5394
>  [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18)
>  [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
>   r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210
>  [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
>  [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18)
>   r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60
>   r4:8454fe00
>  [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c)
>   r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60
>   r4:84f01e00
>  [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac)
>   r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000
>  [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c)
>   r6:00000026 r5:00000000 r4:00000026 r3:8007a938
>  [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc)
>   r4:808c1e38 r3:0000002e
>  [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c)
>   r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015
>   r4:8880210c r3:808c7ef0
>  [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c)
> 
> Signed-off-by: Rabin Vincent <rabin@rab.in>
> ---
>  kernel/trace/trace_functions_graph.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
> index 2d25ad1..a610872 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -1313,11 +1313,11 @@ void graph_trace_open(struct trace_iterator *iter)
>  
>  	iter->private = NULL;
>  
> -	data = kzalloc(sizeof(*data), GFP_KERNEL);
> +	data = kzalloc(sizeof(*data), GFP_ATOMIC);
>  	if (!data)
>  		goto out_err;
>  
> -	data->cpu_data = alloc_percpu(struct fgraph_cpu_data);
> +	data->cpu_data = alloc_percpu_gfp(struct fgraph_cpu_data, GFP_ATOMIC);
>  	if (!data->cpu_data)
>  		goto out_err_free;
>  

Couple of things. First, this deserves a comment, because I can see
someone looking at this in 5 years and saying, WTF is this ATOMIC, and
converting it back to GFP_KERNEL.

Also, since this is really the rare case, and memory may still be freed
in the normal case for this, we should have both. That is, something
like:

	/* This can be called by ftrace_dump() in an atomic location. */
	data = kzalloc(sizeof(*data), GFP_ATOMIC);
	if (unlikely(!data)) {
		/* Try the normal case */
		if (in_atomic() || irqs_disabled())
			goto out_err;
		/* Try the normal case */
		data = kzalloc(sizeof(*data), GPF_KERNEL);
		if (!data)
			goto out_err;
	}

The same for the per_cpu alloc.

I did it that way to avoid doing the in_atomic() calls, but really,
this is not a fast path. We could also just do:

	data = (in_atomic() || irqs_disabled()) ?
		kzalloc(sizeof(*data), GFP_ATOMIC) :
		kzalloc(sizeof(*data), GPF_KERNEL);

Yeah, that way looks better.

But it definitely needs a comment.

-- Steve



^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCHv2] tracing: handle atomic context in graph_trace_open()
  2015-04-13 20:07 ` Steven Rostedt
@ 2015-04-13 20:30   ` Rabin Vincent
  0 siblings, 0 replies; 3+ messages in thread
From: Rabin Vincent @ 2015-04-13 20:30 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: linux-kernel, Rabin Vincent

graph_trace_open() can be called in atomic context from ftrace_dump().
Use GFP_ATOMIC for the memory allocations when that's the case, in order
to avoid the following splat.

 BUG: sleeping function called from invalid context at mm/slab.c:2849
 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
 Backtrace:
 ..
 [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238)
  r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0
 [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0)
  r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8
  r4:810d16f0
 [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c)
  r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30
 [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec)
  r4:810d2580 r3:00000000
 [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20)
  r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a
  r4:808d5394
 [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18)
 [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
  r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210
 [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
 [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18)
  r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60
  r4:8454fe00
 [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c)
  r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60
  r4:84f01e00
 [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac)
  r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000
 [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c)
  r6:00000026 r5:00000000 r4:00000026 r3:8007a938
 [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc)
  r4:808c1e38 r3:0000002e
 [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c)
  r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015
  r4:8880210c r3:808c7ef0
 [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c)

Signed-off-by: Rabin Vincent <rabin@rab.in>
---
v2: add comment, use appropriate gfp depending on context

 kernel/trace/trace_functions_graph.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index 2d25ad1..b6fce36 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -1309,15 +1309,19 @@ void graph_trace_open(struct trace_iterator *iter)
 {
 	/* pid and depth on the last trace processed */
 	struct fgraph_data *data;
+	gfp_t gfpflags;
 	int cpu;
 
 	iter->private = NULL;
 
-	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	/* We can be called in atomic context via ftrace_dump() */
+	gfpflags = (in_atomic() || irqs_disabled()) ? GFP_ATOMIC : GFP_KERNEL;
+
+	data = kzalloc(sizeof(*data), gfpflags);
 	if (!data)
 		goto out_err;
 
-	data->cpu_data = alloc_percpu(struct fgraph_cpu_data);
+	data->cpu_data = alloc_percpu_gfp(struct fgraph_cpu_data, gfpflags);
 	if (!data->cpu_data)
 		goto out_err_free;
 
-- 
2.1.4


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-04-13 20:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-13 19:35 [PATCH] tracing: use GFP_ATOMIC in graph_trace_open() Rabin Vincent
2015-04-13 20:07 ` Steven Rostedt
2015-04-13 20:30   ` [PATCHv2] tracing: handle atomic context " Rabin Vincent

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.