ighly related to memory
map design document, [1], saying 1GB aligned RAM. The majority of arm64
platforms might follow the information although it is not spec. IOW,
a machine I've played was at least unusual *at that time*, so I didn't
consider upstream work.
[1]
http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf
Best Regards
Jungseok Lee
On Nov 17, 2015, at 12:55 AM, Tejun Heo wrote:
Dear Tejun,
> On Wed, Nov 04, 2015 at 01:26:07PM +0000, Jungseok Lee wrote:
>> As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
>> used any more. That is, no code refers to the definition.
>>
>>
(+ Li Bin in CC)
On Nov 10, 2015, at 11:42 AM, AKASHI Takahiro wrote:
> On 11/09/2015 11:04 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> Function graph tracer modifies a return address (LR) in a stack
On Nov 11, 2015, at 2:03 PM, AKASHI Takahiro wrote:
> Jungseok,
>
> On 11/10/2015 11:05 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> Stack tracer on arm64, check_stack(), is uniqeue in the foll
*size += -imm;
> + } else if ((ldst_type ==
> + AARCH64_INSN_LDST_STORE_PAIR) &&
> + (reg1 == AARCH64_INSN_REG_29) &&
> + (reg2 == AARCH64_INSN_REG_30) &&
@ __AARCH64_INSN_FUNCS(hint,0xF01F, 0xD503201F)
> __AARCH64_INSN_FUNCS(br, 0xFC1F, 0xD61F)
> __AARCH64_INSN_FUNCS(blr, 0xFC1F, 0xD63F)
> __AARCH64_INSN_FUNCS(ret, 0xFC1F, 0xD65F)
> +__AARCH64_INSN_FUNCS(eret, 0x, 0xD69F00E0)
Accordin
On Nov 10, 2015, at 11:58 AM, AKASHI Takahiro wrote:
Hi Akashi,
> On 11/09/2015 11:24 PM, Jungseok Lee wrote:
>> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> This is the fifth patch series for fixing stack tracer on arm64.
&g
o function_graph > /sys/kernel/debug/tracing/current_tracer
$ [ Run any workload ]
$ sudo cat /sys/kernel/debug/tracing/stack_trace
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
*trace)
>
> data.trace = trace;
> data.skip = trace->skip;
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + data.ret_stack_index = current->curr_ret_stack;
Can I get an idea on why current->curr_ret_stack is used instead of
tsk->curr_ret_stack?
Best Regards
Jungseok Lee--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Nov 4, 2015, at 2:58 AM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 03/11/15 13:49, Jungseok Lee wrote:
>> Additionally, I've been thinking of do_softirq_own_stack() which is your
>> another comment [3]. Recently, I've realized there is possibility that
>&
As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
used any more. That is, no code refers to the definition.
Acked-by: Christoph Lameter
Signed-off-by: Jungseok Lee
---
I've kept Acked-by from Christoph since there is no change in generic
percpu code between v1 and v2.
Ch
On Nov 4, 2015, at 7:07 AM, Tejun Heo wrote:
> Hello,
Hello,
> On Tue, Nov 03, 2015 at 11:12:51PM +0900, Jungseok Lee wrote:
>> On Nov 3, 2015, at 4:10 AM, Tejun Heo wrote:
>>
>> Dear Tejun,
>>
>>> On Sun, Nov 01, 2015 at 07:46:15AM +, Jungseok Lee
On Nov 3, 2015, at 4:10 AM, Tejun Heo wrote:
Dear Tejun,
> On Sun, Nov 01, 2015 at 07:46:15AM +0000, Jungseok Lee wrote:
>> As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
>> used any more. That is, no code refers to the definition.
>>
>>
On Nov 3, 2015, at 1:10 AM, Christoph Lameter wrote:
Dear Christoph,
> On Sun, 1 Nov 2015, Jungseok Lee wrote:
>
>> There is no room to adjust 'atom_size' now when a generic percpu area
>> is used. It would be redundant to write down an architecture-specific
>>
On Nov 3, 2015, at 1:22 AM, Catalin Marinas wrote:
Hi Catalin,
> On Mon, Nov 02, 2015 at 10:10:23AM -0600, Christoph Lameter wrote:
>> On Sun, 1 Nov 2015, Jungseok Lee wrote:
>>
>>> There is no room to adjust 'atom_size' now when a generic percpu area
>>&
nters.
Can I get an idea on how to test the function prologue analyzer? It pretty
tough to compare stack trace data with objdump one. Is there an easier way
to observe this enhancement without objdump?
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux
ata->ret_stack_index--].ret
> + - AARCH64_INSN_SIZE;
> + }
> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> +
This hunk would be affected as the commit, "ARM64: unwind: Fix PC calculation",
e306dfd0, has been reverted.
Best
As pure cleanup, this patch removes PERCPU_ENOUGH_ROOM which is not
used any more. That is, no code refers to the definition.
Signed-off-by: Jungseok Lee
---
include/linux/percpu.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index
are greatly welcome.
Thanks in advance!
Best Regards
Jungseok Lee
Changes since v5:
- Introduced a new definition for 'atom_size' configuration
- Used PERCPU for stack allocation, per Catalin
Changes since v4:
- Supported 64KB page system
- Introduced IRQ_STACK_* macro, per Catalin
: James Morse
Signed-off-by: Jungseok Lee
---
Note that this change has been tested with 4 different combos:
- THREAD_SIZE = 16KB, IRQ_STACK_SIZE = 16KB
- THREAD_SIZE = 16KB, IRQ_STACK_SIZE = 8KB
- THREAD_SIZE = 8KB, IRQ_STACK_SIZE = 16KB
- THREAD_SIZE = 8KB, IRQ_STACK_SIZE = 8KB
I've re
SIZE
by default. The value could be updated if needed by architecture.
Signed-off-by: Jungseok Lee
---
include/linux/percpu.h | 4
mm/percpu.c| 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index 4bc6daf..
On Oct 8, 2015, at 11:45 PM, Jungseok Lee wrote:
> On Oct 8, 2015, at 7:01 PM, AKASHI Takahiro wrote:
>
> Hi Akashi,
>
>> This is the third patch series for fixing stack tracer on arm64.
>> The original issue was reported by Jungseok[1], and then I found more
>> i
On Oct 20, 2015, at 10:08 PM, Jungseok Lee wrote:
> On Oct 20, 2015, at 1:18 AM, Catalin Marinas wrote:
>
> Hi Catalin,
>
>> On Sat, Oct 17, 2015 at 10:38:16PM +0900, Jungseok Lee wrote:
>>> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
>>>> BTW, a st
On Oct 21, 2015, at 1:04 AM, James Morse wrote:
> On 20/10/15 16:05, Jungseok Lee wrote:
>> On Oct 20, 2015, at 7:05 PM, James Morse wrote:
>>> On 17/10/15 15:27, Jungseok Lee wrote:
>>>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
>>>>
On Oct 21, 2015, at 9:14 PM, Jungseok Lee wrote:
Whoops!
> [Only Akashi and James]
>
> On Oct 21, 2015, at 3:38 PM, AKASHI Takahiro wrote:
>
> Hi Akashi and James,
>
> Am I the only person who have experienced kernel panic with this series?
> I have observed NULL point
eued into for-next/core.
Best Regards
Jungseok Lee
> On 10/20/2015 10:26 PM, Jungseok Lee wrote:
>> On Oct 20, 2015, at 5:00 PM, AKASHI Takahiro wrote:
>>> This patch allows unwind_frame() to traverse from interrupt stack
>>> to process stack correctly by having a dummy
t;", "Interrupt stack", stack,
> + stack + sizeof(struct pt_regs), false);
According to entry.S in case of \el == 1, the stack, might look as follows.
--- <- High address (x21)
| |
| |
| pt_regs |
On Oct 20, 2015, at 7:05 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 17/10/15 15:27, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
>> stack, not 8
.9.5
How about folding the following hunk into this patch?
The comment would be helpful for people to follow this code.
8<
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index f1303c5..0ff7db3 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@
On Oct 19, 2015, at 3:47 PM, AKASHI Takahiro wrote:
> Jungseok,
>
> On 10/15/2015 10:39 PM, Jungseok Lee wrote:
>> On Oct 15, 2015, at 1:19 PM, AKASHI Takahiro wrote:
>>> Jungseok,
>>
>>>>> 8<
>>>>> diff --git a/arch/arm64
On Oct 19, 2015, at 3:54 PM, AKASHI Takahiro wrote:
Hi Akashi,
> On 10/17/2015 11:27 PM, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
>> stack, not 8KB one. T
On Oct 20, 2015, at 1:18 AM, Catalin Marinas wrote:
Hi Catalin,
> On Sat, Oct 17, 2015 at 10:38:16PM +0900, Jungseok Lee wrote:
>> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
>>> BTW, a static allocation (DEFINE_PER_CPU for the whole irq stack) would
>>>
Morse
Signed-off-by: Jungseok Lee
---
I've used Cc', not Tested-by tag, from James, since there is a gap
between v4 and v5.
Changes since v4:
- Supported 64KB page system
- Introduced IRQ_STACK_* macro, per Catalin
- Rebased on top of for-next/core
Changes since v3:
- Expanded stac
Cc: James Morse
Cc: Mark Rutland
Signed-off-by: Jungseok Lee
---
Changes since v2:
- Fixed a typo and mixed data in the commit msg
Changes since v1:
- Added an example to the commit msg, per Will
- Modified a comment
arch/arm64/kernel/traps.c | 15 ++-
1 file changed, 10 inserti
On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
Hi Catalin,
> On Fri, Oct 16, 2015 at 10:01:20PM +0900, Jungseok Lee wrote:
>> On Oct 16, 2015, at 12:59 AM, James Morse wrote:
>>> My concern is there could be push-back from the maintainer of
>>> ke
Cc: James Morse
Cc: Mark Rutland
Signed-off-by: Jungseok Lee
---
Changes since v1:
- Added an example to the commit msg, per Will
- Modified a comment.
arch/arm64/kernel/traps.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/a
On Oct 16, 2015, at 1:01 AM, James Morse wrote:
> On 15/10/15 15:24, 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
On Oct 16, 2015, at 12:59 AM, James Morse wrote:
Hi James,
> On 14/10/15 13:12, Jungseok Lee wrote:
>> On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote:
>>> On Oct 13, 2015, at 8:00 PM, James Morse wrote:
>>>> On 12/10/15 23:13, Jungseok Lee wrote:
>>>>
On Oct 16, 2015, at 2:26 AM, Will Deacon wrote:
Hi Will,
> On Thu, Oct 15, 2015 at 01:21:54PM +0000, Jungseok Lee wrote:
>> dump_backtrace() has its own backtrace logic unlike perf callchain which
>> relies on walk_stackframe(). They behave differently when a symbol is
>>
sleep 10
> [1] sudo ./perf report --call-graph --stdio
> [2] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
On Oct 15, 2015, at 1:19 PM, AKASHI Takahiro wrote:
> Jungseok,
Hi Akashi,
> On 10/14/2015 09:55 PM, Jungseok Lee wrote:
>> On Oct 14, 2015, at 9:24 PM, Jungseok Lee wrote:
>>> On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
>>>> On 10/09/2015 11:24 PM, Jam
hange both head.S and unwind_frame() structure
for a few of symbols in *.S, so this hunk does not take care of the case.
Cc: AKASHI Takahiro
Cc: James Morse
Cc: Mark Rutland
Signed-off-by: Jungseok Lee
---
arch/arm64/kernel/traps.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletion
On Oct 14, 2015, at 9:24 PM, Jungseok Lee wrote:
> On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
>> On 10/09/2015 11:24 PM, James Morse wrote:
>>> Hi Jungseok,
>>>
>>> On 07/10/15 16:28, Jungseok Lee wrote:
>>>> Currently, a call trac
On Oct 14, 2015, at 4:13 PM, AKASHI Takahiro wrote:
> On 10/09/2015 11:24 PM, James Morse wrote:
>> Hi Jungseok,
>>
>> On 07/10/15 16:28, Jungseok Lee wrote:
>>> Currently, a call trace drops a process stack walk when a separate IRQ
>>> stack is used. It m
On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote:
> On Oct 13, 2015, at 8:00 PM, James Morse wrote:
>> Hi Jungseok,
>
> Hi James,
>
>> On 12/10/15 23:13, Jungseok Lee wrote:
>>> On Oct 13, 2015, at 1:34 AM, James Morse wrote:
>>>> Having two kmem_cach
rch/arm64/kernel/stacktrace.c
index 407991b..7126d4d 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -17,6 +17,7 @@
*/
#include
#include
+#include
#include
#include
----8<
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "
if (*p == (stack_dump_trace[i]
> + + FTRACE_STACK_FRAME_OFFSET)) {
> stack_dump_trace[x] = stack_dump_trace[i++];
> this_size = stack_dump_index[x++] =
> (
On Oct 13, 2015, at 8:00 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 12/10/15 23:13, Jungseok Lee wrote:
>> On Oct 13, 2015, at 1:34 AM, James Morse wrote:
>>> Having two kmem_caches for 16K stacks on a 64K page system may be wasteful
>>> (especi
On Oct 13, 2015, at 1:34 AM, James Morse wrote:
> Hi Jungseok,
Hi James,
> 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 bac
On Oct 9, 2015, at 11:24 PM, James Morse wrote:
> Hi Jungseok,
Hi James,
> On 07/10/15 16:28, Jungseok Lee wrote:
>> Currently, a call trace drops a process stack walk when a separate IRQ
>> stack is used. It makes a call trace information much less useful when
>>
il/linux-arm-kernel/2015-September/368003.html
> [4]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371451.html
The [4] is not a valid patch. I hope the test has been going with the following
one.
http://www.kernelhub.org/?msg=841034&p=2
I will leave comme
On Oct 8, 2015, at 7:25 PM, Pratyush Anand wrote:
> Hi Jungseok,
Hi Pratyush,
>
> On 07/10/2015:03:28:11 PM, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
includes stack trace support feature?
I will take the tag at that time.
I always thank you!
Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.
sp_el0 update into kernel_entry macro, per James
- Dropped S_SP removal patch, per Mark and James
Jungseok Lee (2):
arm64: Introduce IRQ stack
arm64: Expand the stack trace feature to support IRQ stack
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/irq.h | 18
: James Morse
Signed-off-by: Jungseok Lee
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/irq.h | 6 +++
arch/arm64/include/asm/thread_info.h | 10 +++-
arch/arm64/kernel/asm-offsets.c | 2 +
arch/arm64/kernel/entry.S| 41 ++--
arch
whether another stack walk is needed or not via current sp
- Loosen the frame pointer upper bound condition
Cc: AKASHI Takahiro
Cc: James Morse
Signed-off-by: Jungseok Lee
---
arch/arm64/include/asm/irq.h| 12 +++
arch/arm64/kernel/asm-offsets.c | 3 +++
arch/arm64/kernel/entry.S
On Oct 6, 2015, at 2:24 AM, James Morse wrote:
Hi James,
> On 05/10/15 07:37, AKASHI Takahiro wrote:
>> On 10/04/2015 11:32 PM, Jungseok Lee wrote:
>>> On Oct 3, 2015, at 1:23 AM, James Morse wrote:
>>>> One observed change in behaviour:
>>>> Any stack-
On Oct 3, 2015, at 1:23 AM, James Morse wrote:
> Hi,
Hi James,
>
> On 22/09/15 13:11, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces a system to use 16KB
>> stack, not 8KB
On Sep 22, 2015, at 9:11 PM, Jungseok Lee wrote:
Dear all,
I cannot reply to your feedbacks for about a week. I will answer your
emails as soon as possible after that time.
Best Regards
Jungseok Lee
> Currently, kernel context and interrupts are handled using a single
> kernel stack nav
-off-by: Jungseok Lee
---
Changes since v2:
- Optmised current_thread_info function as removing masking operation
and volatile keyword per James and Catalin
- Reworked irq re-enterance check logic using top-bit comparison of
stacks per James
- Added sp_el0 update in cpu_resume per James
- Selected
On Sep 21, 2015, at 9:19 PM, Jungseok Lee wrote:
Dear all,
Please ignore this. It won't work.
I've typed a wrong command line in a terminal.
Sorry for confusion.
Best Regards
Jungseok Lee
> Currently, kernel context and interrupts are handled using a single
> kernel stack nav
-off-by: Jungseok Lee
---
Changes since v2:
- Optmised current_thread_info function as removing masking operation
and volatile keyword per James and Catalin
- Reworked irq re-enterance check logic using top-bit comparison of
stacks per James
- Added sp_el0 update in cpu_resume per James
- Selected
On Sep 21, 2015, at 6:25 PM, Catalin Marinas wrote:
> On Sat, Sep 19, 2015 at 05:44:37PM +0900, Jungseok Lee wrote:
>> On Sep 19, 2015, at 12:31 AM, Catalin Marinas wrote:
>>> On Fri, Sep 18, 2015 at 04:03:02PM +0100, Catalin Marinas wrote:
>>>> On Fri, Sep 18, 2015
On Sep 19, 2015, at 12:31 AM, Catalin Marinas wrote:
> On Fri, Sep 18, 2015 at 04:03:02PM +0100, Catalin Marinas wrote:
>> On Fri, Sep 18, 2015 at 09:57:56PM +0900, Jungseok Lee wrote:
>>> On Sep 18, 2015, at 1:21 AM, Catalin Marinas wrote:
>>>> So, wit
On Sep 18, 2015, at 10:46 PM, James Morse wrote:
> Hi Jungseok Lee,
Hi James Morse,
> I gave this a go on a Juno board, while generating usb/network interrupts:
>
> Tested-by: James Morse
Thanks a lot!
> On 13/09/15 15:42, Jungseok Lee wrote:
>> Currently, kernel conte
On Sep 18, 2015, at 2:07 AM, Catalin Marinas wrote:
> On Thu, Sep 17, 2015 at 09:36:04PM +0900, Jungseok Lee wrote:
>> On Sep 17, 2015, at 7:33 PM, James Morse wrote:
>>> On 16/09/15 12:25, Will Deacon wrote:
>>>> On Sun, Sep 13, 2015 at 03:42:17PM +0100, Jungseok
On Sep 18, 2015, at 1:21 AM, Catalin Marinas wrote:
> On Thu, Sep 17, 2015 at 10:22:26PM +0900, Jungseok Lee wrote:
>> On Sep 17, 2015, at 10:17 PM, Jungseok Lee wrote:
>>> On Sep 17, 2015, at 8:17 PM, Catalin Marinas wrote:
>>>> On Sun, Sep 13, 2015 at 02:42:
On Sep 17, 2015, at 10:17 PM, Jungseok Lee wrote:
> On Sep 17, 2015, at 8:17 PM, Catalin Marinas wrote:
>
> Hi Catalin,
>
>> On Sun, Sep 13, 2015 at 02:42:17PM +, Jungseok Lee wrote:
>>> Currently, kernel context and interrupts are handled using a single
>>&
On Sep 17, 2015, at 8:17 PM, Catalin Marinas wrote:
Hi Catalin,
> On Sun, Sep 13, 2015 at 02:42:17PM +0000, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces many systems to use
>> 16
On Sep 17, 2015, at 7:33 PM, James Morse wrote:
Hi James and Will,
> Hi Will,
>
> On 16/09/15 12:25, Will Deacon wrote:
>> On Sun, Sep 13, 2015 at 03:42:17PM +0100, Jungseok Lee wrote:
>>> diff --git a/arch/arm64/include/asm/thread_info.h
>>> b/arch/arm64/in
. This approach helps arm64 align with other architectures
regarding object_is_on_stack() without additional complexity.
Cc: James Morse
Signed-off-by: Jungseok Lee
---
Changes since v1:
- Rebased on top of v4.3-rc1
- Removed Kconfig about IRQ stack, per James
- Used PERCPU for IRQ stack, per James
On Sep 10, 2015, at 3:13 AM, James Morse wrote:
> On 09/09/15 14:22, Jungseok Lee wrote:
>> On Sep 9, 2015, at 1:47 AM, James Morse wrote:
>>> On 08/09/15 15:54, Jungseok Lee wrote:
>>>> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>>>>> diff --git
On Sep 9, 2015, at 1:47 AM, James Morse wrote:
> On 08/09/15 15:54, Jungseok Lee wrote:
>> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>>
>> Hi James,
>>
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index e16351819
On Sep 8, 2015, at 10:45 AM, AKASHI Takahiro wrote:
> Jungseok,
Hi Akashi,
> On 09/08/2015 01:34 AM, Jungseok Lee wrote:
>> On Sep 8, 2015, at 1:06 AM, James Morse wrote:
>>> On 07/09/15 16:48, Jungseok Lee wrote:
>>>> On Sep 7, 2015, at 11:36 PM, James
gt;task->stack to find the old thread_info
> when
> + * setting flags like TIF_NEED_RESCHED...
> + */
> +asmlinkage int irq_copy_thread_info(unsigned long dst_sp, unsigned long
> src_sp)
> +{
> + struct thread_info *src = get_thread_info(src_sp);
> + struct thread_i
On Sep 7, 2015, at 11:48 PM, James Morse wrote:
Hi James,
> On 04/09/15 15:23, Jungseok Lee wrote:
>> Currently, kernel context and interrupts are handled using a single
>> kernel stack navigated by sp_el1. This forces many systems to use
>> 16KB stack, not 8KB one.
On Sep 8, 2015, at 1:06 AM, James Morse wrote:
> On 07/09/15 16:48, Jungseok Lee wrote:
>> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>>
>> Hi James,
>>
>>> Having to handle interrupts on top of an existing kernel stack means the
>>> kernel stac
On Sep 7, 2015, at 11:56 PM, Mark Rutland wrote:
Hi Mark,
> On Fri, Sep 04, 2015 at 03:23:05PM +0100, Jungseok Lee wrote:
>> Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation
>> is not needed in kernel_entry. Currently, S_SP information is vaild only
>>
the max stack depth.
AFAIK, a stack tracer on ftrace does not work well. Did you dump a stack
region and find or track down an untouched region?
I will leave comments after reading and playing with this change carefully.
Best Regards
Jungseok Lee
> Signed-off-by: James Morse
> ---
> arc
On Sep 7, 2015, at 11:33 PM, James Morse wrote:
> On 04/09/15 15:23, Jungseok Lee wrote:
>> ARM64 kernel allocates 16KB kernel stack when creating a process. In case
>> of low memory platforms with tough workloads on userland, this order-2
>> allocation request reaches t
On Sep 5, 2015, at 2:12 AM, Alexnader Kuleshov wrote:
> Hello Jungseok,
Hello Alexnader,
> On 09-04-15, Jungseok Lee wrote:
>> +config IRQ_STACK
>> +bool "Use separate kernel stack when handling interrupts"
>> +depends on ARM64_4K_PAGES
>> +
t; VA_BITS)
> +#define __VIRTUAL_MASK ((1UL << VA_BITS) - 1)
According to Catalin's comment, [1], it might need to be rewritten using
VA_START
in the KASan patches, [2], after this merge window.
[1] https://lkml.org/lkml/2015/9/4/529
[2] git://github.com/aryabinin/
Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation
is not needed in kernel_entry. Currently, S_SP information is vaild only
when sp_el0 is used.
Signed-off-by: Jungseok Lee
---
arch/arm64/kernel/entry.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/kernel
board, and it has
been validated with two different tracks: 4.2-rc5 + Linaro Ubuntu 15.04 and
3.10 + Android.
After this merge window, I will rebase this series and resend it.
Any comments or feedbacks are always welcome.
Thanks in advance!
[1]: https://lkml.org/lkml/2015/7/13/29
Jungseok
It is a principal objective of IRQ stack feature to reduce kernel
stack size. Therefore, the size is set to 8KB when a separate IRQ
stack is active.
Signed-off-by: Jungseok Lee
---
arch/arm64/include/asm/thread_info.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64
thread_info can be tracked easily using sp_el0, not sp_el1 when
this feature is enabled.
Signed-off-by: Jungseok Lee
---
arch/arm64/Kconfig.debug | 10 ++
arch/arm64/include/asm/irq.h | 8 ++
arch/arm64/include/asm/thread_info.h | 11 ++
arch/arm64/kernel/asm-offsets.c | 8
On Aug 17, 2015, at 1:50 PM, AKASHI Takahiro wrote:
> Hi
Hi Akashi,
> On 08/11/2015 11:52 PM, Jungseok Lee wrote:
>> On Aug 4, 2015, at 4:44 PM, AKASHI Takahiro wrote:
>>
>> Hi Akashi,
>>
>>> See the following threads [1],[2] for the background.
>>
On Aug 13, 2015, at 12:02 AM, Will Deacon wrote:
Hi Will,
> On Wed, Aug 12, 2015 at 03:16:19PM +0100, Jungseok Lee wrote:
>> The gic_handle_irq() is defined with __exception_irq_entry attribute.
>> A single remaining work is to add its definition as ARM did. Below
>> sho
nt
Cc: Steven Rostedt
Signed-off-by: Jungseok Lee
---
arch/arm64/include/asm/exception.h | 6 +
arch/arm64/include/asm/traps.h | 23 --
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/exception.h
b/arch/arm64/include/asm/exception.h
l1
since this is an exception?
> +
> + return 0;
> + }
> +
> frame->sp = fp + 0x10;
I'm just curious about this constant, 0x10. Do you have an idea on this value?
As reviewing objdump of vmlinux, it looks needed to analyze the first store-pair
instr
+---+ <-- p0 (*p0 == stack_dump_trace[i+1] == lr0)
| lr0 |
+---+
| |
| func-1's local variables
| |
sp0 +---+ <- func-0(lr0)'s stackframe
| | (stack_dump_index[i+1] = top - p0)
| |
On Aug 4, 2015, at 1:57 AM, Steven Rostedt wrote:
> On Tue, 4 Aug 2015 01:30:50 +0900
> Jungseok Lee wrote:
>
>
>> There are two issues in the current version.
>> 1) The change does not work correctly when function_graph feature is enabled.
>> 2) Akashi have rais
On Aug 3, 2015, at 6:09 PM, Will Deacon wrote:
> Hi guys,
Hi Will,
> On Mon, Jul 20, 2015 at 05:20:04PM +0100, Will Deacon wrote:
>> On Fri, Jul 17, 2015 at 04:34:21PM +0100, Jungseok Lee wrote:
>>> On Jul 17, 2015, at 11:59 PM, Jungseok Lee wrote:
>>>> On
On Jul 22, 2015, at 12:09 AM, Steven Rostedt wrote:
> On Tue, 21 Jul 2015 23:56:31 +0900
> Jungseok Lee wrote:
>
>
>
>> Recently, I've noticed that there is a minor, not logical, flaw in the
>> above hunk as reviewing patches which do not get any signals yet. I
On Jul 11, 2015, at 11:51 PM, Jungseok Lee wrote:
> A fine granulity support for delay would be very useful when profiling
> VM logics, such as page allocation including page reclaim and memory
> compaction with function graph.
>
> Thus, this patch adds two additional marks w
uch special cases
> in save_stack_trace() or check_stack() as x86 does in
> print_ftrace_graph_addr().
I should have run it with function_graph. The issue is reproduced easily
on my environment. I don't see other issues yet when enabling other tracers.
Best Regards
Jungseok Lee
--
To u
On Jul 17, 2015, at 10:44 AM, Steven Rostedt wrote:
Hi, Steve
Thanks for caring about this!
> On Sat, 11 Jul 2015 14:51:39 +
> Jungseok Lee wrote:
>
>> diff --git a/kernel/trace/trace_functions_graph.c
>> b/kernel/trace/trace_functions_graph.c
>> index 8968b
On Jul 17, 2015, at 11:59 PM, Jungseok Lee wrote:
> On Jul 17, 2015, at 11:41 PM, Steven Rostedt wrote:
>> On Fri, 17 Jul 2015 23:28:13 +0900
>> Jungseok Lee wrote:
>>
>>
>>>
>>> I have reviewed and tested the kernel including this patch and only
On Jul 17, 2015, at 11:41 PM, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 23:28:13 +0900
> Jungseok Lee wrote:
>
>
>>
>> I have reviewed and tested the kernel including this patch and only [RFC
>> 1/3].
>
> Thanks! Can you repost patch 1 with the changes I
On Jul 17, 2015, at 11:04 AM, AKASHI Takahiro wrote:
> Jungseok,
>
> Thank you for your testing and reviews.
You're welcome.
> On 07/16/2015 10:29 PM, Jungseok Lee wrote:
>> On Jul 16, 2015, at 10:08 AM, AKASHI Takahiro wrote:
>>
>> Hi, AKASHI
>>
&g
1 - 100 of 203 matches
Mail list logo
