[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54900D5D.4060509@imgtec.com>
Date: Tue, 16 Dec 2014 10:45:49 +0000
From: James Hogan <james.hogan@...tec.com>
To: Guenter Roeck <linux@...ck-us.net>,
Andrew Morton <akpm@...ux-foundation.org>
CC: Stephen Rothwell <sfr@...b.auug.org.au>,
<linux-next@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
<linux-metag@...r.kernel.org>
Subject: Re: linux-next: Tree for Dec 16
On 16/12/14 09:42, James Hogan wrote:
> On 16/12/14 06:55, Guenter Roeck wrote:
>> On 12/15/2014 10:44 PM, Andrew Morton wrote:
>>> On Mon, 15 Dec 2014 22:35:49 -0800 Guenter Roeck <linux@...ck-us.net>
>>> wrote:
>>>
>>>> On Tue, Dec 16, 2014 at 03:46:22PM +1100, Stephen Rothwell wrote:
>>>>> Hi all,
>>>>>
>>>>> Please do not add any code destined for v3.20 to your linux-next
>>>>> included
>>>>> trees/branches until after v3.19-rc1 is released.
>>>>>
>>>>> Changes since 20141215:
>>>>>
>>>>> The infiniband tree gained a conflict against Linus' tree and a build
>>>>> failure so I used the version from next-20141215.
>>>>>
>>>>> The userns tree gained a conflict against the vfs tree.
>>>>>
>>>>> The clk tree gained a build failure so I used the version from
>>>>> next-20141215.
>>>>>
>>>>> Non-merge commits (relative to Linus' tree): 3588
>>>>> 2582 files changed, 123494 insertions(+), 135748 deletions(-)
>>>>>
>>>>
>>>> My metag buildbot test fails with this kernel.
>>>
>>> Thanks. What are the error messages?
>>>
>>>
>> Nothing. It just hangs until killed.
>>
>> qemu log:
>> char device redirected to /dev/pts/5
>> Unable to load ROM!
>> qemu: terminating on signal 15 from pid 17843
>>
>> http://server.roeck-us.net:8010/builders/qemu-metag-next/builds/60/steps/qemubuildcommand/logs/stdio
>
> Thanks a lot Guenter for report and bisection. I've confirmed on real
> hardware too. I'll try debugging it.
The fmt in the first printk gets corrupted and causes a memory fault
because the stack isn't 64-bit aligned. The args get saved with a 64-bit
store (but unaligned access checking isn't turned on yet so this
silently does the wrong thing), and then read as 1 with a 32-bit load.
Enabling unaligned access checking from boot makes it fail at
metag_start_kernel, immediately after stack pointer is set to
init_thread_union + THREAD_INFO_SIZE. Basically the restart_block was
the only thing keeping the struct thread_info as a whole 64-bit aligned
on Meta.
The patch below fixes it. Please can it be squashed into commit "all
arches, signal: move restart_block to struct task_struct".
Thanks
James
From 3ec117304ebde939fd181129227de28c068e7fa2 Mon Sep 17 00:00:00 2001
From: James Hogan <james.hogan@...tec.com>
Date: Tue, 16 Dec 2014 10:15:33 +0000
Subject: [PATCH] metag: Align thread_info::supervisor_stack
Commit a82be12232dc ("all arches, signal: move restart_block to struct
task_struct") removed restart_block from struct thread_info which was
the only thing keeping supervisor_stack and the struct as a whole 64-bit
aligned. This resulted in the initial stack pointer not being 64-bit
aligned, so when arguments are saved to the stack with a 64-bit SETL
instruction the values are corrupted resulting in a pretty early
unserviced memory fault in printk.
This is fixed by explicitly aligning supervisor_stack to 8 bytes.
Fixes: a82be12232dc ("all arches, signal: move restart_block to struct task_struct")
Reported-by: Guenter Roeck <linux@...ck-us.net>
Signed-off-by: James Hogan <james.hogan@...tec.com>
Cc: Andy Lutomirski <luto@...capital.net>
Cc: Andrew Morton <akpm@...ux-foundation.org>
---
arch/metag/include/asm/thread_info.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/metag/include/asm/thread_info.h b/arch/metag/include/asm/thread_info.h
index ff4332435d15..afb3ca4776d1 100644
--- a/arch/metag/include/asm/thread_info.h
+++ b/arch/metag/include/asm/thread_info.h
@@ -36,7 +36,7 @@ struct thread_info {
mm_segment_t addr_limit; /* thread address space */
- u8 supervisor_stack[0];
+ u8 supervisor_stack[0] __aligned(8);
};
#else /* !__ASSEMBLY__ */
--
2.0.4
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists