linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: James Hogan <james.hogan@imgtec.com>,
	Guenter Roeck <linux@roeck-us.net>, <linux-next@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	<linux-metag@vger.kernel.org>
Subject: Re: linux-next: Tree for Dec 16
Date: Wed, 17 Dec 2014 10:57:22 +1100	[thread overview]
Message-ID: <20141217105722.3ec1fcf5@canb.auug.org.au> (raw)
In-Reply-To: <54900D5D.4060509@imgtec.com>

[-- Attachment #1: Type: text/plain, Size: 3457 bytes --]

Hi Andrew,

On Tue, 16 Dec 2014 10:45:49 +0000 James Hogan <james.hogan@imgtec.com> wrote:
>
> 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@roeck-us.net>
> >>> wrote:
> >>>
> >>>> 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@imgtec.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@roeck-us.net>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Andrew Morton <akpm@linux-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

So should I just dump that patch into my copy of your tree?  (it seems
harmless and lets people get onto other stuff)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-12-16 23:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16  4:46 linux-next: Tree for Dec 16 Stephen Rothwell
2014-12-16  6:35 ` Guenter Roeck
2014-12-16  6:44   ` Andrew Morton
2014-12-16  6:55     ` Guenter Roeck
2014-12-16  9:42       ` James Hogan
2014-12-16 10:45         ` James Hogan
2014-12-16 23:57           ` Stephen Rothwell [this message]
2014-12-17  0:08             ` Andrew Morton
2014-12-17  0:23               ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-12-16  1:46 Stephen Rothwell
2020-12-16  9:40 Stephen Rothwell
2019-12-16  5:22 Stephen Rothwell
2016-12-16  3:49 Stephen Rothwell
2015-12-16  5:43 Stephen Rothwell
2013-12-16  5:59 Stephen Rothwell
2011-12-16  6:00 Stephen Rothwell

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=20141217105722.3ec1fcf5@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=akpm@linux-foundation.org \
    --cc=james.hogan@imgtec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luto@amacapital.net \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).