All of lore.kernel.org
 help / color / mirror / Atom feed
From: xuwei5@hisilicon.com (Wei Xu)
To: linux-arm-kernel@lists.infradead.org
Subject: KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
Date: Thu, 21 Jun 2018 11:14:28 +0100	[thread overview]
Message-ID: <5B2B7A84.8090309@hisilicon.com> (raw)
In-Reply-To: <20180621091850.GA22505@arm.com>

Hi Will,

On 2018/6/21 10:18, Will Deacon wrote:
> On Thu, Jun 21, 2018 at 09:38:53AM +0100, James Morse wrote:
>> On 20/06/18 17:25, Wei Xu wrote:
>>>     [    0.042421] Insufficient stack space to handle exception!
>>>     [    0.042423] ESR: 0x96000046 -- DABT (current EL)
>>>     [    0.043730] FAR: 0xffff0000093a80e0
>>>     [    0.044714] Task stack: [0xffff0000093a8000..0xffff0000093ac000]
>>
>> This was a level 2 translation fault on a write, to an address that is within
>> the stack....
>>
>>
>>>     [    0.051113] IRQ stack: [0xffff000008000000..0xffff000008004000]
>>>     [    0.057610] Overflow stack: [0xffff80003efce2f0..0xffff80003efcf2f0]
>>>     [    0.064003] CPU: 0 PID: 12 Comm: migration/0 Not tainted
>>> 4.17.0-45865-g2b31fe7-dirty #10
>>>     [    0.072201] Hardware name: linux,dummy-virt (DT)
>>
>>>     [    0.076797] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
>>>     [    0.081727] pc : el1_sync+0x0/0xb0
>>
>> ... from the vectors.
>>
>>
>>>     [    0.085217] lr : kpti_install_ng_mappings+0x120/0x214
>>
>> What I think is happening is: we come out of the kpti idmap with the stack
>> unmapped. Shortly after we access the stack, which faults. el1_sync faults as
>> well when it tries to push the registers to the stack, and we keep going until
>> we overflow the stack.
>>
>> I can't reproduce this with kvmtool or qemu in the model.
> 
> Hmm, one thing that occurs to me is that the kpti_install_ng_mappings()
> code leaves the nG bit set in table entries, which is actually IGNORED in
> the architecture.
> 
> Wei -- does the diff below help at all? Make sure you disable CONFIG_KASAN,
> otherwise your kernel will take an age to boot.

Yes, amazing! This patch resolved the issue.
I have tested 50 times and can not reproduce the issue any more.
Could you please tell more why this patch works?
Thanks!

Best Regards,
Wei

> 
> Will
> 
> --->8
> 
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 5f9a73a4452c..70d9e98467ca 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -272,8 +272,8 @@ ENTRY(idmap_kpti_install_ng_mappings)
>  	add	end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8)
>  do_pgd:	__idmap_kpti_get_pgtable_ent	pgd
>  	tbnz	pgd, #1, walk_puds
> -next_pgd:
>  	__idmap_kpti_put_pgtable_ent_ng	pgd
> +next_pgd:
>  skip_pgd:
>  	add	cur_pgdp, cur_pgdp, #8
>  	cmp	cur_pgdp, end_pgdp
> @@ -302,8 +302,8 @@ walk_puds:
>  	add	end_pudp, cur_pudp, #(PTRS_PER_PUD * 8)
>  do_pud:	__idmap_kpti_get_pgtable_ent	pud
>  	tbnz	pud, #1, walk_pmds
> -next_pud:
>  	__idmap_kpti_put_pgtable_ent_ng	pud
> +next_pud:
>  skip_pud:
>  	add	cur_pudp, cur_pudp, 8
>  	cmp	cur_pudp, end_pudp
> @@ -323,8 +323,8 @@ walk_pmds:
>  	add	end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8)
>  do_pmd:	__idmap_kpti_get_pgtable_ent	pmd
>  	tbnz	pmd, #1, walk_ptes
> -next_pmd:
>  	__idmap_kpti_put_pgtable_ent_ng	pmd
> +next_pmd:
>  skip_pmd:
>  	add	cur_pmdp, cur_pmdp, #8
>  	cmp	cur_pmdp, end_pmdp
> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: Wei Xu <xuwei5@hisilicon.com>
To: Will Deacon <will.deacon@arm.com>, James Morse <james.morse@arm.com>
Cc: <catalin.marinas@arm.com>, <suzuki.poulose@arm.com>,
	<dave.martin@arm.com>, <mark.rutland@arm.com>,
	<marc.zyngier@arm.com>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, Linuxarm <linuxarm@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>, <xiexiuqi@huawei.com>,
	huangdaode <huangdaode@hisilicon.com>,
	"Chenxin (Charles)" <charles.chenxin@huawei.com>,
	"Xiongfanggou (James)" <james.xiong@huawei.com>,
	"Liguozhu (Kenneth)" <liguozhu@hisilicon.com>,
	Zhangyi ac <zhangyi.ac@huawei.com>, <jonathan.cameron@huawei.com>,
	"Shameerali Kolothum Thodi"
	<shameerali.kolothum.thodi@huawei.com>,
	John Garry <john.garry@huawei.com>,
	Salil Mehta <salil.mehta@huawei.com>,
	Shiju Jose <shiju.jose@huawei.com>,
	"Zhuangyuzeng (Yisen)" <yisen.zhuang@huawei.com>,
	"Wangzhou (B)" <wangzhou1@hisilicon.com>,
	"kongxinwei (A)" <kong.kongxinwei@hisilicon.com>,
	"Liyuan (Larry, Turing Solution)" <Larry.T@huawei.com>,
	<libeijian@hisilicon.com>
Subject: Re: KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
Date: Thu, 21 Jun 2018 11:14:28 +0100	[thread overview]
Message-ID: <5B2B7A84.8090309@hisilicon.com> (raw)
In-Reply-To: <20180621091850.GA22505@arm.com>

Hi Will,

On 2018/6/21 10:18, Will Deacon wrote:
> On Thu, Jun 21, 2018 at 09:38:53AM +0100, James Morse wrote:
>> On 20/06/18 17:25, Wei Xu wrote:
>>>     [    0.042421] Insufficient stack space to handle exception!
>>>     [    0.042423] ESR: 0x96000046 -- DABT (current EL)
>>>     [    0.043730] FAR: 0xffff0000093a80e0
>>>     [    0.044714] Task stack: [0xffff0000093a8000..0xffff0000093ac000]
>>
>> This was a level 2 translation fault on a write, to an address that is within
>> the stack....
>>
>>
>>>     [    0.051113] IRQ stack: [0xffff000008000000..0xffff000008004000]
>>>     [    0.057610] Overflow stack: [0xffff80003efce2f0..0xffff80003efcf2f0]
>>>     [    0.064003] CPU: 0 PID: 12 Comm: migration/0 Not tainted
>>> 4.17.0-45865-g2b31fe7-dirty #10
>>>     [    0.072201] Hardware name: linux,dummy-virt (DT)
>>
>>>     [    0.076797] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
>>>     [    0.081727] pc : el1_sync+0x0/0xb0
>>
>> ... from the vectors.
>>
>>
>>>     [    0.085217] lr : kpti_install_ng_mappings+0x120/0x214
>>
>> What I think is happening is: we come out of the kpti idmap with the stack
>> unmapped. Shortly after we access the stack, which faults. el1_sync faults as
>> well when it tries to push the registers to the stack, and we keep going until
>> we overflow the stack.
>>
>> I can't reproduce this with kvmtool or qemu in the model.
> 
> Hmm, one thing that occurs to me is that the kpti_install_ng_mappings()
> code leaves the nG bit set in table entries, which is actually IGNORED in
> the architecture.
> 
> Wei -- does the diff below help at all? Make sure you disable CONFIG_KASAN,
> otherwise your kernel will take an age to boot.

Yes, amazing! This patch resolved the issue.
I have tested 50 times and can not reproduce the issue any more.
Could you please tell more why this patch works?
Thanks!

Best Regards,
Wei

> 
> Will
> 
> --->8
> 
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 5f9a73a4452c..70d9e98467ca 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -272,8 +272,8 @@ ENTRY(idmap_kpti_install_ng_mappings)
>  	add	end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8)
>  do_pgd:	__idmap_kpti_get_pgtable_ent	pgd
>  	tbnz	pgd, #1, walk_puds
> -next_pgd:
>  	__idmap_kpti_put_pgtable_ent_ng	pgd
> +next_pgd:
>  skip_pgd:
>  	add	cur_pgdp, cur_pgdp, #8
>  	cmp	cur_pgdp, end_pgdp
> @@ -302,8 +302,8 @@ walk_puds:
>  	add	end_pudp, cur_pudp, #(PTRS_PER_PUD * 8)
>  do_pud:	__idmap_kpti_get_pgtable_ent	pud
>  	tbnz	pud, #1, walk_pmds
> -next_pud:
>  	__idmap_kpti_put_pgtable_ent_ng	pud
> +next_pud:
>  skip_pud:
>  	add	cur_pudp, cur_pudp, 8
>  	cmp	cur_pudp, end_pudp
> @@ -323,8 +323,8 @@ walk_pmds:
>  	add	end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8)
>  do_pmd:	__idmap_kpti_get_pgtable_ent	pmd
>  	tbnz	pmd, #1, walk_ptes
> -next_pmd:
>  	__idmap_kpti_put_pgtable_ent_ng	pmd
> +next_pmd:
>  skip_pmd:
>  	add	cur_pmdp, cur_pmdp, #8
>  	cmp	cur_pmdp, end_pmdp
> 
> .
> 


  reply	other threads:[~2018-06-21 10:14 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 14:18 KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform Wei Xu
2018-06-20 14:18 ` Wei Xu
2018-06-20 14:42 ` Will Deacon
2018-06-20 14:42   ` Will Deacon
2018-06-20 15:52   ` Wei Xu
2018-06-20 15:52     ` Wei Xu
2018-06-20 15:54     ` James Morse
2018-06-20 15:54       ` James Morse
2018-06-20 16:25       ` Wei Xu
2018-06-20 16:25         ` Wei Xu
2018-06-20 16:28         ` Will Deacon
2018-06-20 16:28           ` Will Deacon
2018-06-20 16:33           ` Wei Xu
2018-06-20 16:33             ` Wei Xu
2018-06-21  8:38         ` James Morse
2018-06-21  8:38           ` James Morse
2018-06-21  9:00           ` Marc Zyngier
2018-06-21  9:00             ` Marc Zyngier
2018-06-21  9:18           ` Will Deacon
2018-06-21  9:18             ` Will Deacon
2018-06-21 10:14             ` Wei Xu [this message]
2018-06-21 10:14               ` Wei Xu
2018-06-21 10:54               ` Will Deacon
2018-06-21 10:54                 ` Will Deacon
2018-06-22  8:33                 ` Wei Xu
2018-06-22  8:33                   ` Wei Xu
2018-06-22  9:23                   ` Will Deacon
2018-06-22  9:23                     ` Will Deacon
2018-06-22 10:45                     ` Wei Xu
2018-06-22 10:45                       ` Wei Xu
2018-06-22 11:16                       ` Will Deacon
2018-06-22 11:16                         ` Will Deacon
2018-06-22 13:18                         ` Wei Xu
2018-06-22 13:18                           ` Wei Xu
2018-06-22 13:31                           ` Will Deacon
2018-06-22 13:31                             ` Will Deacon
2018-06-22 13:46                             ` Wei Xu
2018-06-22 13:46                               ` Wei Xu
2018-06-22 14:43                               ` Will Deacon
2018-06-22 14:43                                 ` Will Deacon
2018-06-22 15:26                                 ` Wei Xu
2018-06-22 15:26                                   ` Wei Xu
2018-06-22 14:28                           ` Mark Rutland
2018-06-22 14:28                             ` Mark Rutland
2018-06-22 15:28                             ` Wei Xu
2018-06-22 15:28                               ` Wei Xu
2018-06-22 15:41                               ` Will Deacon
2018-06-22 15:41                                 ` Will Deacon
2018-06-22 16:02                                 ` Wei Xu
2018-06-22 16:02                                   ` Wei Xu
2018-06-21  9:20           ` Wei Xu
2018-06-21  9:20             ` Wei Xu
2018-06-26 17:16             ` Wei Xu
2018-06-26 17:16               ` Wei Xu
2018-06-26 17:47               ` Will Deacon
2018-06-26 17:47                 ` Will Deacon
2018-06-27  8:39                 ` James Morse
2018-06-27  8:39                   ` James Morse
2018-06-27 13:26                   ` Wei Xu
2018-06-27 13:26                     ` Wei Xu
2018-06-28  8:45                     ` James Morse
2018-06-28  8:45                       ` James Morse
2018-06-28 10:20                       ` Wei Xu
2018-06-28 10:20                         ` Wei Xu
2018-06-27 13:22                 ` Wei Xu
2018-06-27 13:22                   ` Wei Xu
2018-06-27 13:28                   ` Will Deacon
2018-06-27 13:28                     ` Will Deacon
2018-06-27 13:32                     ` Wei Xu
2018-06-27 13:32                       ` Wei Xu
2018-06-28 14:50                     ` Wei Xu
2018-06-28 14:50                       ` Wei Xu
2018-06-28 15:34                       ` Mark Rutland
2018-06-28 15:34                         ` Mark Rutland
     [not found]                         ` <etPan.5b3507f7.914aa16.1d6b@localhost>
2018-06-28 16:24                           ` 答复: " Mark Rutland
2018-06-28 16:24                             ` Mark Rutland
2018-06-29  9:59                             ` Mark Rutland
2018-06-29  9:59                               ` Mark Rutland
2018-06-29  8:47                           ` Marc Zyngier

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=5B2B7A84.8090309@hisilicon.com \
    --to=xuwei5@hisilicon.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.