From: James Morse <james.morse@arm.com> To: Jungseok Lee <jungseoklee85@gmail.com> Cc: takahiro.akashi@linaro.org, catalin.marinas@arm.com, will.deacon@arm.com, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, barami97@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack Date: Mon, 12 Oct 2015 17:34:25 +0100 [thread overview] Message-ID: <561BE111.7@arm.com> (raw) In-Reply-To: <07A53E87-C562-48D1-86DF-A373EAAA73F9@gmail.com> Hi Jungseok, On 12/10/15 15:53, Jungseok Lee wrote: > On Oct 9, 2015, at 11:24 PM, James Morse wrote: >> I think unwind_frame() needs to walk the irq stack too. [2] is an example >> of perf tracing back to userspace, (and there are patches on the list to >> do/fix this), so we need to walk back to the start of the first stack for >> the perf accounting to be correct. > > Frankly, I missed the case where perf does backtrace to userspace. > > IMO, this statement supports why the stack trace feature commit should be > written independently. The [1/2] patch would be pretty stable if 64KB page > is supported. If this hasn't been started yet, here is a build-test-only first-pass at the 64K page support - based on the code in kernel/fork.c: ==================%<================== diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c index a6bdf4d3a57c..deb057a735ad 100644 --- a/arch/arm64/kernel/irq.c +++ b/arch/arm64/kernel/irq.c @@ -27,8 +27,22 @@ #include <linux/init.h> #include <linux/irqchip.h> #include <linux/seq_file.h> +#include <linux/slab.h> +#include <linux/topology.h> #include <linux/ratelimit.h> +#if THREAD_SIZE >= PAGE_SIZE +#define __alloc_irq_stack(x) (void *)__get_free_pages(THREADINFO_GFP, \ + THREAD_SIZE_ORDER) + +extern struct kmem_cache *irq_stack_cache; /* dummy declaration */ +#else +#define __alloc_irq_stack(cpu) (void *)kmem_cache_alloc_node(irq_stack_cache, \ + THREADINFO_GFP, cpu_to_node(cpu)) + +static struct kmem_cache *irq_stack_cache; +#endif /* THREAD_SIZE >= PAGE_SIZE */ unsigned long irq_err_count; DEFINE_PER_CPU(struct irq_stack, irq_stacks); @@ -128,7 +142,17 @@ int alloc_irq_stack(unsigned int cpu) if (per_cpu(irq_stacks, cpu).stack) return 0; - stack = (void *)__get_free_pages(THREADINFO_GFP, THREAD_SIZE_ORDER); + if (THREAD_SIZE < PAGE_SIZE) { + if (!irq_stack_cache) { + irq_stack_cache = kmem_cache_create("irq_stack", + THREAD_SIZE, + THREAD_SIZE, 0, + NULL); + BUG_ON(!irq_stack_cache); + } + } + + stack = __alloc_irq_stack(cpu); if (!stack) return -ENOMEM; ==================%<================== (my mail client will almost certainly mangle that) Having two kmem_caches for 16K stacks on a 64K page system may be wasteful (especially for systems with few cpus)... The alternative is to defining CONFIG_ARCH_THREAD_INFO_ALLOCATOR and allocate all stack memory from arch code. (Largely copied code, prevents irq stacks being a different size, and nothing uses that define today!) Thoughts? > >>> + */ >>> + if (fp < low || fp > high - 0x10 || fp & 0xf) >>> return -EINVAL; >>> >>> frame->sp = fp + 0x10; >>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c >>> index f93aae5..44b2f828 100644 >>> --- a/arch/arm64/kernel/traps.c >>> +++ b/arch/arm64/kernel/traps.c >>> @@ -146,6 +146,8 @@ static void dump_instr(const char *lvl, struct pt_regs *regs) >>> static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk) >>> { >>> struct stackframe frame; >>> + unsigned int cpu = smp_processor_id(); >> >> I wonder if there is any case where dump_backtrace() is called on another cpu? >> >> Setting the cpu value from task_thread_info(tsk)->cpu would protect against >> this. > > IMO, no, but your suggestion makes sense. I will update it. > >>> + bool in_irq = in_irq_stack(cpu); >>> >>> pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk); >>> >>> @@ -170,6 +172,10 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk) >>> } >>> >>> pr_emerg("Call trace:\n"); >>> +repeat: >>> + if (in_irq) >>> + pr_emerg("<IRQ>\n"); >> >> Do we need these? 'el1_irq()' in the trace is a giveaway… > > I borrow this idea from x86 implementation in order to show a separate stack > explicitly. There is no issue to remove these tags, <IRQ> and <EOI>. Ah okay - if its done elsewhere, its better to be consistent. Thanks, James
WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack Date: Mon, 12 Oct 2015 17:34:25 +0100 [thread overview] Message-ID: <561BE111.7@arm.com> (raw) In-Reply-To: <07A53E87-C562-48D1-86DF-A373EAAA73F9@gmail.com> Hi Jungseok, On 12/10/15 15:53, Jungseok Lee wrote: > On Oct 9, 2015, at 11:24 PM, James Morse wrote: >> I think unwind_frame() needs to walk the irq stack too. [2] is an example >> of perf tracing back to userspace, (and there are patches on the list to >> do/fix this), so we need to walk back to the start of the first stack for >> the perf accounting to be correct. > > Frankly, I missed the case where perf does backtrace to userspace. > > IMO, this statement supports why the stack trace feature commit should be > written independently. The [1/2] patch would be pretty stable if 64KB page > is supported. If this hasn't been started yet, here is a build-test-only first-pass at the 64K page support - based on the code in kernel/fork.c: ==================%<================== diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c index a6bdf4d3a57c..deb057a735ad 100644 --- a/arch/arm64/kernel/irq.c +++ b/arch/arm64/kernel/irq.c @@ -27,8 +27,22 @@ #include <linux/init.h> #include <linux/irqchip.h> #include <linux/seq_file.h> +#include <linux/slab.h> +#include <linux/topology.h> #include <linux/ratelimit.h> +#if THREAD_SIZE >= PAGE_SIZE +#define __alloc_irq_stack(x) (void *)__get_free_pages(THREADINFO_GFP, \ + THREAD_SIZE_ORDER) + +extern struct kmem_cache *irq_stack_cache; /* dummy declaration */ +#else +#define __alloc_irq_stack(cpu) (void *)kmem_cache_alloc_node(irq_stack_cache, \ + THREADINFO_GFP, cpu_to_node(cpu)) + +static struct kmem_cache *irq_stack_cache; +#endif /* THREAD_SIZE >= PAGE_SIZE */ unsigned long irq_err_count; DEFINE_PER_CPU(struct irq_stack, irq_stacks); @@ -128,7 +142,17 @@ int alloc_irq_stack(unsigned int cpu) if (per_cpu(irq_stacks, cpu).stack) return 0; - stack = (void *)__get_free_pages(THREADINFO_GFP, THREAD_SIZE_ORDER); + if (THREAD_SIZE < PAGE_SIZE) { + if (!irq_stack_cache) { + irq_stack_cache = kmem_cache_create("irq_stack", + THREAD_SIZE, + THREAD_SIZE, 0, + NULL); + BUG_ON(!irq_stack_cache); + } + } + + stack = __alloc_irq_stack(cpu); if (!stack) return -ENOMEM; ==================%<================== (my mail client will almost certainly mangle that) Having two kmem_caches for 16K stacks on a 64K page system may be wasteful (especially for systems with few cpus)... The alternative is to defining CONFIG_ARCH_THREAD_INFO_ALLOCATOR and allocate all stack memory from arch code. (Largely copied code, prevents irq stacks being a different size, and nothing uses that define today!) Thoughts? > >>> + */ >>> + if (fp < low || fp > high - 0x10 || fp & 0xf) >>> return -EINVAL; >>> >>> frame->sp = fp + 0x10; >>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c >>> index f93aae5..44b2f828 100644 >>> --- a/arch/arm64/kernel/traps.c >>> +++ b/arch/arm64/kernel/traps.c >>> @@ -146,6 +146,8 @@ static void dump_instr(const char *lvl, struct pt_regs *regs) >>> static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk) >>> { >>> struct stackframe frame; >>> + unsigned int cpu = smp_processor_id(); >> >> I wonder if there is any case where dump_backtrace() is called on another cpu? >> >> Setting the cpu value from task_thread_info(tsk)->cpu would protect against >> this. > > IMO, no, but your suggestion makes sense. I will update it. > >>> + bool in_irq = in_irq_stack(cpu); >>> >>> pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk); >>> >>> @@ -170,6 +172,10 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk) >>> } >>> >>> pr_emerg("Call trace:\n"); >>> +repeat: >>> + if (in_irq) >>> + pr_emerg("<IRQ>\n"); >> >> Do we need these? 'el1_irq()' in the trace is a giveaway? > > I borrow this idea from x86 implementation in order to show a separate stack > explicitly. There is no issue to remove these tags, <IRQ> and <EOI>. Ah okay - if its done elsewhere, its better to be consistent. Thanks, James
next prev parent reply other threads:[~2015-10-12 16:35 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-07 15:28 [PATCH v4 0/2] arm64: Introduce IRQ stack Jungseok Lee 2015-10-07 15:28 ` Jungseok Lee 2015-10-07 15:28 ` [PATCH v4 1/2] " Jungseok Lee 2015-10-07 15:28 ` Jungseok Lee 2015-10-08 10:25 ` Pratyush Anand 2015-10-08 10:25 ` Pratyush Anand 2015-10-08 14:32 ` Jungseok Lee 2015-10-08 14:32 ` Jungseok Lee 2015-10-08 16:51 ` Pratyush Anand 2015-10-08 16:51 ` Pratyush Anand 2015-10-07 15:28 ` [PATCH v4 2/2] arm64: Expand the stack trace feature to support " Jungseok Lee 2015-10-07 15:28 ` Jungseok Lee 2015-10-09 14:24 ` James Morse 2015-10-09 14:24 ` James Morse 2015-10-12 14:53 ` Jungseok Lee 2015-10-12 14:53 ` Jungseok Lee 2015-10-12 16:34 ` James Morse [this message] 2015-10-12 16:34 ` James Morse 2015-10-12 22:13 ` Jungseok Lee 2015-10-12 22:13 ` Jungseok Lee 2015-10-13 11:00 ` James Morse 2015-10-13 11:00 ` James Morse 2015-10-13 15:00 ` Jungseok Lee 2015-10-13 15:00 ` Jungseok Lee 2015-10-14 12:12 ` Jungseok Lee 2015-10-14 12:12 ` Jungseok Lee 2015-10-15 15:59 ` James Morse 2015-10-15 15:59 ` James Morse 2015-10-16 13:01 ` Jungseok Lee 2015-10-16 13:01 ` Jungseok Lee 2015-10-16 16:06 ` Catalin Marinas 2015-10-16 16:06 ` Catalin Marinas 2015-10-17 13:38 ` Jungseok Lee 2015-10-17 13:38 ` Jungseok Lee 2015-10-19 16:18 ` Catalin Marinas 2015-10-19 16:18 ` Catalin Marinas 2015-10-20 13:08 ` Jungseok Lee 2015-10-20 13:08 ` Jungseok Lee 2015-10-21 15:14 ` Jungseok Lee 2015-10-21 15:14 ` Jungseok Lee 2015-10-14 7:13 ` AKASHI Takahiro 2015-10-14 7:13 ` AKASHI Takahiro 2015-10-14 12:24 ` Jungseok Lee 2015-10-14 12:24 ` Jungseok Lee 2015-10-14 12:55 ` Jungseok Lee 2015-10-14 12:55 ` Jungseok Lee 2015-10-15 4:19 ` AKASHI Takahiro 2015-10-15 4:19 ` AKASHI Takahiro 2015-10-15 13:39 ` Jungseok Lee 2015-10-15 13:39 ` Jungseok Lee 2015-10-19 6:47 ` AKASHI Takahiro 2015-10-19 6:47 ` AKASHI Takahiro 2015-10-20 13:19 ` Jungseok Lee 2015-10-20 13:19 ` Jungseok Lee 2015-10-15 14:24 ` Jungseok Lee 2015-10-15 14:24 ` Jungseok Lee 2015-10-15 16:01 ` James Morse 2015-10-15 16:01 ` James Morse 2015-10-16 13:02 ` Jungseok Lee 2015-10-16 13:02 ` Jungseok Lee
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=561BE111.7@arm.com \ --to=james.morse@arm.com \ --cc=barami97@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=jungseoklee85@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=takahiro.akashi@linaro.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.