linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
To: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	Xuefeng Li <lixuefeng@loongson.cn>,
	Juxin Gao <gaojuxin@loongson.cn>
Subject: Re: [PATCH 3/3] MIPS: Reduce possibility of kernel panic under CONFIG_SWIOTLB
Date: Tue, 21 Apr 2020 17:35:25 +0800	[thread overview]
Message-ID: <20200421173525.460949b0@flygoat-x1e> (raw)
In-Reply-To: <1587459869-12183-4-git-send-email-yangtiezhu@loongson.cn>

On Tue, 21 Apr 2020 17:04:29 +0800
Tiezhu Yang <yangtiezhu@loongson.cn> wrote:

> In the current code, if CONFIG_SWIOTLB is set, when failed to get IO
> TLB memory from the low pages by plat_swiotlb_setup(), it may lead to
> the boot process failed with kernel panic.

Hi Tiezhu,

Thanks for you patch.

Firstly, your commit message should be more straight forward. Please
describe what you have changed (e.g. MIPS: Set memblock bottom up)
instead of what you solved.

> 
> (1) On the Loongson and SiByte platform
> arch/mips/loongson64/dma.c
> arch/mips/sibyte/common/dma.c
> void __init plat_swiotlb_setup(void)
> {
> 	swiotlb_init(1);
> }
> 

> kernel/dma/swiotlb.c
> void  __init
> swiotlb_init(int verbose)
> {
> ...
> 	vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
> 	if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs,
> verbose)) return;
> ...
> 	pr_warn("Cannot allocate buffer");
> 	no_iotlb_memory = true;
> }
> 
> phys_addr_t swiotlb_tbl_map_single()
> {
> ...
> 	if (no_iotlb_memory)
> 		panic("Can not allocate SWIOTLB buffer earlier ...");
> ...
> }
> 
> (2) On the Cavium OCTEON platform
> arch/mips/cavium-octeon/dma-octeon.c
> void __init plat_swiotlb_setup(void)
> {
> ...
> 	octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE);
> 	if (!octeon_swiotlb)
> 		panic("%s: Failed to allocate %zu bytes align=%lx\n",
> 		      __func__, swiotlbsize, PAGE_SIZE);
> ...
> }
> 
> Because IO_TLB_DEFAULT_SIZE is 64M, if the rest size of low memory is
> less than 64M when call plat_swiotlb_setup(), we can easily reproduce
> the panic case.
> 
> In order to reduce the possibility of kernel panic when failed to get
> IO TLB memory under CONFIG_SWIOTLB, it is better to allocate low
> memory as small as possible before plat_swiotlb_setup(), so make
> sparse_init() using top-down allocation.

AFAIK there are some reasons that we set it to bottom_up.
On some platforms, bootloader won't place cmdline & devicetree into
reserved memory but place them just after kernel in memory. That means
if you set it as bottom up, then early allocate memory might collide
with these boot arguments.

I'm not even sure if it works fine on Loongson with early PMON.

I had met that issue before, the solution for me is to reduce SWIOTLB
size.

> 
> Reported-by: Juxin Gao <gaojuxin@loongson.cn>
> Co-developed-by: Juxin Gao <gaojuxin@loongson.cn>
> Signed-off-by: Juxin Gao <gaojuxin@loongson.cn>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
>  arch/mips/kernel/setup.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 5481a0c..8db533c 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -700,7 +700,17 @@ static void __init arch_mem_init(char
> **cmdline_p) memblock_reserve(crashk_res.start,
> resource_size(&crashk_res)); #endif
>  	device_tree_init();
> +
> +	/*
> +	 * In order to reduce the possibility of kernel panic when
> failed to
> +	 * get IO TLB memory under CONFIG_SWIOTLB, it is better to
> allocate
> +	 * low memory as small as possible before
> plat_swiotlb_setup(), so
> +	 * make sparse_init() using top-down allocation.
> +	 */
> +	memblock_set_bottom_up(false);
>  	sparse_init();
> +	memblock_set_bottom_up(true);
> +
>  	plat_swiotlb_setup();
>  
>  	dma_contiguous_reserve(PFN_PHYS(max_low_pfn));

--
Jiaxun Yang


  reply	other threads:[~2020-04-21  9:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  9:04 [PATCH 0/3] MIPS: Fix some issues about arch_mem_init() Tiezhu Yang
2020-04-21  9:04 ` [PATCH 1/3] MIPS: Do not initialise globals to 0 Tiezhu Yang
2020-04-21  9:04 ` [PATCH 2/3] MIPS: Cleanup code about plat_mem_setup() Tiezhu Yang
2020-04-21  9:04 ` [PATCH 3/3] MIPS: Reduce possibility of kernel panic under CONFIG_SWIOTLB Tiezhu Yang
2020-04-21  9:35   ` Jiaxun Yang [this message]
2020-04-21 10:45     ` Jiaxun Yang
2020-04-21 11:13     ` Tiezhu Yang

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=20200421173525.460949b0@flygoat-x1e \
    --to=jiaxun.yang@flygoat.com \
    --cc=gaojuxin@loongson.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    --cc=tsbogend@alpha.franken.de \
    --cc=yangtiezhu@loongson.cn \
    /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).