linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hauke Mehrtens <hauke@hauke-m.de>
To: Lucas Stach <l.stach@pengutronix.de>,
	Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>,
	Tony Lindgren <tony@atomide.com>,
	patchwork-lst@pengutronix.de,
	Gregory Clement <gregory.clement@free-electrons.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] ARM: catch pending imprecise abort on unmask
Date: Wed, 14 Oct 2015 23:51:21 +0200	[thread overview]
Message-ID: <561ECE59.6010205@hauke-m.de> (raw)
In-Reply-To: <1444834113-18122-2-git-send-email-l.stach@pengutronix.de>

On 10/14/2015 04:48 PM, Lucas Stach wrote:
> Install a non-faulting handler just before unmasking imprecise aborts
> and switch back to the regular one after unmasking is done.
> 
> This catches any pending imprecise abort that the firmware/bootloader
> may have left behind that would normally crash the kernel at that point.
> As there are apparently a lot of bootlaoders out there that do such a
> thing it makes sense to handle it in the common startup code.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
>  arch/arm/mm/fault.c | 15 +++++++++++++++
>  arch/arm/mm/fault.h |  2 ++
>  arch/arm/mm/mmu.c   | 19 ++++++++++++++++++-
>  3 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 0d629b8f973f..519f694ec9db 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -538,6 +538,21 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *)
>  	fsr_info[nr].name = name;
>  }
>  
> +void * __init
> +swap_fault_function(int nr,
> +		    int (*fn)(unsigned long, unsigned int, struct pt_regs *))
> +{
> +	void *old_fn;
> +
> +	if (nr < 0 || nr >= ARRAY_SIZE(fsr_info))
> +		BUG();
> +
> +	old_fn = fsr_info[nr].fn;
> +	fsr_info[nr].fn = fn;
> +
> +	return old_fn;
> +}
> +
>  /*
>   * Dispatch a data abort to the relevant handler.
>   */
> diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
> index cf08bdfbe0d6..2deb7494d84f 100644
> --- a/arch/arm/mm/fault.h
> +++ b/arch/arm/mm/fault.h
> @@ -24,5 +24,7 @@ static inline int fsr_fs(unsigned int fsr)
>  
>  void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs);
>  unsigned long search_exception_table(unsigned long addr);
> +void *swap_fault_function(int nr,
> +		int (*fn)(unsigned long, unsigned int, struct pt_regs *));
>  
>  #endif	/* __ARCH_ARM_FAULT_H */
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index f65a6f344b6d..78c420776f4c 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -38,6 +38,7 @@
>  #include <asm/mach/pci.h>
>  #include <asm/fixmap.h>
>  
> +#include "fault.h"
>  #include "mm.h"
>  #include "tcm.h"
>  
> @@ -1259,6 +1260,20 @@ void __init arm_mm_memblock_reserve(void)
>  }
>  
>  /*
> + * Abort handler to be used only during unmasking of imprecise aborts. This
> + * makes sure that the machine will not die if the firmware/bootloader left an
> + * imprecise abort pending for us to trip over.
> + */
> +static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
> +				      struct pt_regs *regs)
> +{
> +	pr_warn("Hit pending imprecise external abort during first unmask, "
> +		"this is most likely caused by a firmware/bootloader bug.\n");

Why don't you add the fsr value into the print, so it is easier to debug.

Otherwise:

Acked-by: Hauke Mehrtens <hauke@hauke-m.de>

> +
> +	return 0;
> +}
> +
> +/*
>   * Set up the device mappings.  Since we clear out the page tables for all
>   * mappings above VMALLOC_START, except early fixmap, we might remove debug
>   * device mappings.  This means earlycon can be used to debug this function
> @@ -1269,7 +1284,7 @@ static void __init devicemaps_init(const struct machine_desc *mdesc)
>  {
>  	struct map_desc map;
>  	unsigned long addr;
> -	void *vectors;
> +	void *vectors, *saved_fault_fn;
>  
>  	/*
>  	 * Allocate the vector page early.
> @@ -1365,7 +1380,9 @@ static void __init devicemaps_init(const struct machine_desc *mdesc)
>  	flush_cache_all();
>  
>  	/* Enable asynchronous aborts */
> +	saved_fault_fn = swap_fault_function(22, early_abort_handler);
>  	local_abt_enable();
> +	swap_fault_function(22, saved_fault_fn);
>  }
>  
>  static void __init kmap_init(void)
> 

  reply	other threads:[~2015-10-14 21:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14 14:48 [PATCH 0/4] ARM: handle imprecise aborts from firmware in common code Lucas Stach
2015-10-14 14:48 ` [PATCH 1/4] ARM: catch pending imprecise abort on unmask Lucas Stach
2015-10-14 21:51   ` Hauke Mehrtens [this message]
2015-10-15  7:21   ` Russell King - ARM Linux
2015-10-14 14:48 ` [PATCH 2/4] ARM: OMAP2+: remove custom abort handler for t410 Lucas Stach
2015-10-14 16:53   ` Tony Lindgren
2015-10-14 14:48 ` [PATCH 3/4] ARM: mvebu: remove the workaround imprecise abort fault handler Lucas Stach
2015-10-14 20:58   ` Thomas Petazzoni
2015-10-15  7:31     ` Gregory CLEMENT
2015-10-14 14:48 ` [PATCH 4/4] ARM: BCM5301X: remove " Lucas Stach
2015-10-14 21:48   ` Hauke Mehrtens

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=561ECE59.6010205@hauke-m.de \
    --to=hauke@hauke-m.de \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=patchwork-lst@pengutronix.de \
    --cc=tony@atomide.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: 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).