public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, LTP List <ltp@lists.linux.it>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	open list <linux-kernel@vger.kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	lkft-triage@lists.linaro.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [LTP] qemu-arm64: handle_futex_death - kernel/futex/core.c:661 - Unable to handle kernel unknown 43 at virtual address
Date: Tue, 31 Oct 2023 16:27:35 +0000	[thread overview]
Message-ID: <ZUEq9_0vJzmnW5ed@FVFF77S0Q05N> (raw)
In-Reply-To: <CAMj1kXE9c3YVbiuwB6cQnWsmUu_kh=vnipJgitYcUh_HWeS=OA@mail.gmail.com>

On Mon, Oct 30, 2023 at 09:14:56AM +0100, Ard Biesheuvel wrote:
> From 97dea432bceadfcece84484609374c277afc2c81 Mon Sep 17 00:00:00 2001
> From: Ard Biesheuvel <ardb@kernel.org>
> Date: Sat, 28 Oct 2023 09:40:29 +0200
> Subject: [PATCH v2] Add missing ESR decoding for level -1 translation faults
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

As a heads-up, looking at this some more we'll also need to rework the usage of
of ESR_ELx_FSC_TYPE and ESR_ELx_FSC_LEVEL, since those no longer work correctly
Level -1 xFSC value. ESR_ELx_FSC_TYPE is 0x3c and ESR_ELx_FSC_LEVEL is 0x3, and
work on the basis that the xFSC fault types are encoded as xxxxyy, where the
xxxx is the type and the yy is the level (0 to 3).

That didn't expand naturally to level -1. For example, Level {0,1,2,3}
translation faults get reported as 0b0001xx, where the xx encodes the level,
while Level -1 translation faults get reported as 0b101011.

That ends up affecting:

* All the is_${FOO}_fault() predicat functions, e.g. is_translation_fault(),
  is_el1_permission_fault() and is_spurious_el1_translation_fault().

* Places where we synthesize an xFSC value, e.g. set_thread_esr()

* A bunch of KVM due to the use of kvm_vcpu_trap_get_fault_type()

... and we probably need to remove ESR_ELx_FSC_TYPE and ESR_ELx_FSC_LEVEL
entirely to avoid the possiblity of misuse.

Mark.

> ---
>  arch/arm64/mm/fault.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 2e5d1e238af9..13f192691060 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -780,18 +780,18 @@ static const struct fault_info fault_info[] = {
>  	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 1 translation fault"	},
>  	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 2 translation fault"	},
>  	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 3 translation fault"	},
> -	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 8"			},
> +	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 0 access flag fault"	},
>  	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 1 access flag fault"	},
>  	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 access flag fault"	},
>  	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 3 access flag fault"	},
> -	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 12"			},
> +	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 0 permission fault"	},
>  	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 1 permission fault"	},
>  	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 permission fault"	},
>  	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 3 permission fault"	},
>  	{ do_sea,		SIGBUS,  BUS_OBJERR,	"synchronous external abort"	},
>  	{ do_tag_check_fault,	SIGSEGV, SEGV_MTESERR,	"synchronous tag check fault"	},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 18"			},
> -	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 19"			},
> +	{ do_sea,		SIGKILL, SI_KERNEL,	"level -1 (translation table walk)"	},
>  	{ do_sea,		SIGKILL, SI_KERNEL,	"level 0 (translation table walk)"	},
>  	{ do_sea,		SIGKILL, SI_KERNEL,	"level 1 (translation table walk)"	},
>  	{ do_sea,		SIGKILL, SI_KERNEL,	"level 2 (translation table walk)"	},
> @@ -799,7 +799,7 @@ static const struct fault_info fault_info[] = {
>  	{ do_sea,		SIGBUS,  BUS_OBJERR,	"synchronous parity or ECC error" },	// Reserved when RAS is implemented
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 25"			},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 26"			},
> -	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 27"			},
> +	{ do_sea,		SIGKILL, SI_KERNEL,	"level -1 synchronous parity error (translation table walk)"	},	// Reserved when RAS is implemented
>  	{ do_sea,		SIGKILL, SI_KERNEL,	"level 0 synchronous parity error (translation table walk)"	},	// Reserved when RAS is implemented
>  	{ do_sea,		SIGKILL, SI_KERNEL,	"level 1 synchronous parity error (translation table walk)"	},	// Reserved when RAS is implemented
>  	{ do_sea,		SIGKILL, SI_KERNEL,	"level 2 synchronous parity error (translation table walk)"	},	// Reserved when RAS is implemented
> @@ -813,9 +813,9 @@ static const struct fault_info fault_info[] = {
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 38"			},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 39"			},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 40"			},
> -	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 41"			},
> +	{ do_bad,		SIGKILL, SI_KERNEL,	"level -1 address size fault"	},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 42"			},
> -	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 43"			},
> +	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level -1 translation fault"	},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 44"			},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 45"			},
>  	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 46"			},
> -- 
> 2.42.0.820.g83a721a137-goog
> 


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  parent reply	other threads:[~2023-10-31 16:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26 14:41 [LTP] qemu-arm64: handle_futex_death - kernel/futex/core.c:661 - Unable to handle kernel unknown 43 at virtual address Naresh Kamboju
2023-10-26 15:30 ` Mark Rutland
2023-10-26 15:39   ` Ard Biesheuvel
2023-10-27 10:57     ` Naresh Kamboju
2023-10-28  7:42       ` Ard Biesheuvel
2023-10-30  8:07         ` Naresh Kamboju
2023-10-30  8:14           ` Ard Biesheuvel
2023-10-30 11:50             ` Naresh Kamboju
2023-10-31  7:43               ` Naresh Kamboju
2023-10-31 16:27             ` Mark Rutland [this message]
2023-10-31 16:32     ` Mark Rutland

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=ZUEq9_0vJzmnW5ed@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=dan.carpenter@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=ltp@lists.linux.it \
    --cc=mingo@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=tglx@linutronix.de \
    --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: 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