From: Will Deacon <will.deacon@arm.com>
To: Hanjun Guo <guohanjun@huawei.com>
Cc: "Wangxuefeng (E)" <wxf.wang@hisilicon.com>,
"toshi.kani" <toshi.kani@hpe.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
cpandya <cpandya@codeaurora.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>, linux-mm <linux-mm@kvack.org>,
akpm <akpm@linux-foundation.org>,
"mark.rutland" <mark.rutland@arm.com>,
"catalin.marinas" <catalin.marinas@arm.com>,
mhocko <mhocko@suse.com>, "hanjun.guo" <hanjun.guo@linaro.org>
Subject: Re: 答复: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
Date: Mon, 26 Feb 2018 11:04:22 +0000 [thread overview]
Message-ID: <20180226110422.GD8736@arm.com> (raw)
In-Reply-To: <32c9b1c3-086b-ba54-f9e9-aefa50066730@huawei.com>
On Mon, Feb 26, 2018 at 06:57:20PM +0800, Hanjun Guo wrote:
> On 2018/2/21 19:57, Will Deacon wrote:
> > [sorry, trying to deal with top-posting here]
> >
> > On Wed, Feb 21, 2018 at 07:36:34AM +0000, Wangxuefeng (E) wrote:
> >> The old flow of reuse the 4k page as 2M page does not follow the BBM flow
> >> for page table reconstruction，not only the memory leak problems. If BBM flow
> >> is not followed，the speculative prefetch of tlb will made false tlb entries
> >> cached in MMU, the false address will be got， panic will happen.
> >
> > If I understand Toshi's suggestion correctly, he's saying that the PMD can
> > be cleared when unmapping the last PTE (like try_to_free_pte_page). In this
> > case, there's no issue with the TLB because this is exactly BBM -- the PMD
> > is cleared and TLB invalidation is issued before the PTE table is freed. A
> > subsequent 2M map request will see an empty PMD and put down a block
> > mapping.
> >
> > The downside is that freeing becomes more expensive as the last level table
> > becomes more sparsely populated and you need to ensure you don't have any
> > concurrent maps going on for the same table when you're unmapping. I also
> > can't see a neat way to fit this into the current vunmap code. Perhaps we
> > need an iounmap_page_range.
> >
> > In the meantime, the code in lib/ioremap.c looks totally broken so I think
> > we should deselect CONFIG_HAVE_ARCH_HUGE_VMAP on arm64 until it's fixed.
>
> Simply do something below at now (before the broken code is fixed)?
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b2b95f7..a86148c 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -84,7 +84,6 @@ config ARM64
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_BITREVERSE
> - select HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
> select HAVE_ARCH_KGDB
No, that actually breaks with the use of block mappings for the kernel
text. Anyway, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=15122ee2c515a253b0c66a3e618bc7ebe35105eb
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Hanjun Guo <guohanjun@huawei.com>
Cc: "Wangxuefeng (E)" <wxf.wang@hisilicon.com>,
"toshi.kani" <toshi.kani@hpe.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
cpandya <cpandya@codeaurora.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>, linux-mm <linux-mm@kvack.org>,
akpm <akpm@linux-foundation.org>,
"mark.rutland" <mark.rutland@arm.com>,
"catalin.marinas" <catalin.marinas@arm.com>,
mhocko <mhocko@suse.com>, "hanjun.guo" <hanjun.guo@linaro.org>
Subject: Re: 答复: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
Date: Mon, 26 Feb 2018 11:04:22 +0000 [thread overview]
Message-ID: <20180226110422.GD8736@arm.com> (raw)
In-Reply-To: <32c9b1c3-086b-ba54-f9e9-aefa50066730@huawei.com>
On Mon, Feb 26, 2018 at 06:57:20PM +0800, Hanjun Guo wrote:
> On 2018/2/21 19:57, Will Deacon wrote:
> > [sorry, trying to deal with top-posting here]
> >
> > On Wed, Feb 21, 2018 at 07:36:34AM +0000, Wangxuefeng (E) wrote:
> >> The old flow of reuse the 4k page as 2M page does not follow the BBM flow
> >> for page table reconstructioni 1/4 ?not only the memory leak problems. If BBM flow
> >> is not followedi 1/4 ?the speculative prefetch of tlb will made false tlb entries
> >> cached in MMU, the false address will be goti 1/4 ? panic will happen.
> >
> > If I understand Toshi's suggestion correctly, he's saying that the PMD can
> > be cleared when unmapping the last PTE (like try_to_free_pte_page). In this
> > case, there's no issue with the TLB because this is exactly BBM -- the PMD
> > is cleared and TLB invalidation is issued before the PTE table is freed. A
> > subsequent 2M map request will see an empty PMD and put down a block
> > mapping.
> >
> > The downside is that freeing becomes more expensive as the last level table
> > becomes more sparsely populated and you need to ensure you don't have any
> > concurrent maps going on for the same table when you're unmapping. I also
> > can't see a neat way to fit this into the current vunmap code. Perhaps we
> > need an iounmap_page_range.
> >
> > In the meantime, the code in lib/ioremap.c looks totally broken so I think
> > we should deselect CONFIG_HAVE_ARCH_HUGE_VMAP on arm64 until it's fixed.
>
> Simply do something below at now (before the broken code is fixed)?
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b2b95f7..a86148c 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -84,7 +84,6 @@ config ARM64
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_BITREVERSE
> - select HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
> select HAVE_ARCH_KGDB
No, that actually breaks with the use of block mappings for the kernel
text. Anyway, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=15122ee2c515a253b0c66a3e618bc7ebe35105eb
Will
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: 答复: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
Date: Mon, 26 Feb 2018 11:04:22 +0000 [thread overview]
Message-ID: <20180226110422.GD8736@arm.com> (raw)
In-Reply-To: <32c9b1c3-086b-ba54-f9e9-aefa50066730@huawei.com>
On Mon, Feb 26, 2018 at 06:57:20PM +0800, Hanjun Guo wrote:
> On 2018/2/21 19:57, Will Deacon wrote:
> > [sorry, trying to deal with top-posting here]
> >
> > On Wed, Feb 21, 2018 at 07:36:34AM +0000, Wangxuefeng (E) wrote:
> >> The old flow of reuse the 4k page as 2M page does not follow the BBM flow
> >> for page table reconstruction?not only the memory leak problems. If BBM flow
> >> is not followed?the speculative prefetch of tlb will made false tlb entries
> >> cached in MMU, the false address will be got? panic will happen.
> >
> > If I understand Toshi's suggestion correctly, he's saying that the PMD can
> > be cleared when unmapping the last PTE (like try_to_free_pte_page). In this
> > case, there's no issue with the TLB because this is exactly BBM -- the PMD
> > is cleared and TLB invalidation is issued before the PTE table is freed. A
> > subsequent 2M map request will see an empty PMD and put down a block
> > mapping.
> >
> > The downside is that freeing becomes more expensive as the last level table
> > becomes more sparsely populated and you need to ensure you don't have any
> > concurrent maps going on for the same table when you're unmapping. I also
> > can't see a neat way to fit this into the current vunmap code. Perhaps we
> > need an iounmap_page_range.
> >
> > In the meantime, the code in lib/ioremap.c looks totally broken so I think
> > we should deselect CONFIG_HAVE_ARCH_HUGE_VMAP on arm64 until it's fixed.
>
> Simply do something below at now (before the broken code is fixed)?
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b2b95f7..a86148c 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -84,7 +84,6 @@ config ARM64
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_BITREVERSE
> - select HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
> select HAVE_ARCH_KGDB
No, that actually breaks with the use of block mappings for the kernel
text. Anyway, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=15122ee2c515a253b0c66a3e618bc7ebe35105eb
Will
next prev parent reply other threads:[~2018-02-26 11:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-28 11:24 [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero Hanjun Guo
2017-12-28 11:24 ` Hanjun Guo
2017-12-28 11:24 ` Hanjun Guo
2017-12-29 8:00 ` Hanjun Guo
2017-12-29 8:00 ` Hanjun Guo
2017-12-29 8:00 ` Hanjun Guo
2018-01-05 22:15 ` Kani, Toshi
2018-01-05 22:15 ` Kani, Toshi
2018-01-05 22:15 ` Kani, Toshi
2018-01-06 9:46 ` Hanjun Guo
2018-01-06 9:46 ` Hanjun Guo
2018-01-06 9:46 ` Hanjun Guo
2018-01-08 23:36 ` Kani, Toshi
2018-01-08 23:36 ` Kani, Toshi
2018-01-08 23:36 ` Kani, Toshi
2018-02-20 9:24 ` Chintan Pandya
2018-02-20 9:24 ` Chintan Pandya
2018-02-20 9:24 ` Chintan Pandya
2018-02-21 0:34 ` Kani, Toshi
2018-02-21 0:34 ` Kani, Toshi
2018-02-21 7:36 ` 答复: " Wangxuefeng (E)
2018-02-21 11:57 ` Will Deacon
2018-02-21 11:57 ` Will Deacon
2018-02-21 11:57 ` Will Deacon
2018-02-21 12:47 ` 答复: " Wangxuefeng (E)
2018-02-26 10:57 ` Hanjun Guo
2018-02-26 10:57 ` Hanjun Guo
2018-02-26 11:04 ` Will Deacon [this message]
2018-02-26 11:04 ` Will Deacon
2018-02-26 11:04 ` Will Deacon
2018-02-26 12:53 ` Hanjun Guo
2018-02-26 12:53 ` Hanjun Guo
2018-02-27 19:49 ` Kani, Toshi
2018-02-27 19:49 ` Kani, Toshi
2018-02-27 19:59 ` Will Deacon
2018-02-27 19:59 ` Will Deacon
2018-02-27 19:59 ` Will Deacon
2018-02-27 20:02 ` Kani, Toshi
2018-02-27 20:02 ` Kani, Toshi
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=20180226110422.GD8736@arm.com \
--to=will.deacon@arm.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=cpandya@codeaurora.org \
--cc=guohanjun@huawei.com \
--cc=hanjun.guo@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=toshi.kani@hpe.com \
--cc=wxf.wang@hisilicon.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 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.