All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	ardb@kernel.org, guanghuifeng@linux.alibaba.com,
	mark.rutland@arm.com, will@kernel.org, linux-mm@kvack.org,
	thunder.leizhen@huawei.com, wangkefeng.wang@huawei.com,
	kexec@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end
Date: Mon, 5 Sep 2022 13:28:58 +0300	[thread overview]
Message-ID: <YxXPannyTqBZInAt@kernel.org> (raw)
In-Reply-To: <YxCk0mX5IzhvK9Pv@MiWiFi-R3L-srv>

On Thu, Sep 01, 2022 at 08:25:54PM +0800, Baoquan He wrote:
> On 09/01/22 at 10:24am, Mike Rapoport wrote:
> 
> max_zone_phys() only handles cases when CONFIG_ZONE_DMA/DMA32 enabled,
> the disabledCONFIG_ZONE_DMA/DMA32 case is not included. I can change
> it like:
> 
> static phys_addr_t __init crash_addr_low_max(void)
> {
>         phys_addr_t low_mem_mask = U32_MAX;
>         phys_addr_t phys_start = memblock_start_of_DRAM();
> 
>         if ((!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32)) ||
>              (phys_start > U32_MAX))
>                 low_mem_mask = PHYS_ADDR_MAX;
> 
>         return low_mem_mast + 1;
> }
> 
> or add the disabled CONFIG_ZONE_DMA/DMA32 case into crash_addr_low_max()
> as you suggested. Which one do you like better?
> 
> static phys_addr_t __init crash_addr_low_max(void)
> {
>         if (!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32))
> 		return PHYS_ADDR_MAX + 1;
> 
>         return max_zone_phys(32);
> }
 
I like the second variant better.

-- 
Sincerely yours,
Mike.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	ardb@kernel.org, guanghuifeng@linux.alibaba.com,
	mark.rutland@arm.com, will@kernel.org, linux-mm@kvack.org,
	thunder.leizhen@huawei.com, wangkefeng.wang@huawei.com,
	kexec@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end
Date: Mon, 5 Sep 2022 13:28:58 +0300	[thread overview]
Message-ID: <YxXPannyTqBZInAt@kernel.org> (raw)
In-Reply-To: <YxCk0mX5IzhvK9Pv@MiWiFi-R3L-srv>

On Thu, Sep 01, 2022 at 08:25:54PM +0800, Baoquan He wrote:
> On 09/01/22 at 10:24am, Mike Rapoport wrote:
> 
> max_zone_phys() only handles cases when CONFIG_ZONE_DMA/DMA32 enabled,
> the disabledCONFIG_ZONE_DMA/DMA32 case is not included. I can change
> it like:
> 
> static phys_addr_t __init crash_addr_low_max(void)
> {
>         phys_addr_t low_mem_mask = U32_MAX;
>         phys_addr_t phys_start = memblock_start_of_DRAM();
> 
>         if ((!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32)) ||
>              (phys_start > U32_MAX))
>                 low_mem_mask = PHYS_ADDR_MAX;
> 
>         return low_mem_mast + 1;
> }
> 
> or add the disabled CONFIG_ZONE_DMA/DMA32 case into crash_addr_low_max()
> as you suggested. Which one do you like better?
> 
> static phys_addr_t __init crash_addr_low_max(void)
> {
>         if (!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32))
> 		return PHYS_ADDR_MAX + 1;
> 
>         return max_zone_phys(32);
> }
 
I like the second variant better.

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	ardb@kernel.org, guanghuifeng@linux.alibaba.com,
	mark.rutland@arm.com, will@kernel.org, linux-mm@kvack.org,
	thunder.leizhen@huawei.com, wangkefeng.wang@huawei.com,
	kexec@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end
Date: Mon, 5 Sep 2022 13:28:58 +0300	[thread overview]
Message-ID: <YxXPannyTqBZInAt@kernel.org> (raw)
In-Reply-To: <YxCk0mX5IzhvK9Pv@MiWiFi-R3L-srv>

On Thu, Sep 01, 2022 at 08:25:54PM +0800, Baoquan He wrote:
> On 09/01/22 at 10:24am, Mike Rapoport wrote:
> 
> max_zone_phys() only handles cases when CONFIG_ZONE_DMA/DMA32 enabled,
> the disabledCONFIG_ZONE_DMA/DMA32 case is not included. I can change
> it like:
> 
> static phys_addr_t __init crash_addr_low_max(void)
> {
>         phys_addr_t low_mem_mask = U32_MAX;
>         phys_addr_t phys_start = memblock_start_of_DRAM();
> 
>         if ((!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32)) ||
>              (phys_start > U32_MAX))
>                 low_mem_mask = PHYS_ADDR_MAX;
> 
>         return low_mem_mast + 1;
> }
> 
> or add the disabled CONFIG_ZONE_DMA/DMA32 case into crash_addr_low_max()
> as you suggested. Which one do you like better?
> 
> static phys_addr_t __init crash_addr_low_max(void)
> {
>         if (!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32))
> 		return PHYS_ADDR_MAX + 1;
> 
>         return max_zone_phys(32);
> }
 
I like the second variant better.

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2022-09-05 17:41 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-28  0:55 [PATCH 0/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end Baoquan He
2022-08-28  0:55 ` Baoquan He
2022-08-28  0:55 ` Baoquan He
2022-08-28  0:55 ` [PATCH 1/2] " Baoquan He
2022-08-28  0:55   ` Baoquan He
2022-08-28  0:55   ` Baoquan He
2022-08-31  1:50   ` Leizhen (ThunderTown)
2022-08-31  1:50     ` Leizhen (ThunderTown)
2022-08-31  1:50     ` Leizhen (ThunderTown)
2022-08-31  7:37   ` Mike Rapoport
2022-08-31  7:37     ` Mike Rapoport
2022-08-31  7:37     ` Mike Rapoport
2022-08-31 14:29     ` Baoquan He
2022-08-31 14:29       ` Baoquan He
2022-08-31 14:29       ` Baoquan He
2022-09-01  7:24       ` Mike Rapoport
2022-09-01  7:24         ` Mike Rapoport
2022-09-01  7:24         ` Mike Rapoport
2022-09-01 12:25         ` Baoquan He
2022-09-01 12:25           ` Baoquan He
2022-09-01 12:25           ` Baoquan He
2022-09-05 10:28           ` Mike Rapoport [this message]
2022-09-05 10:28             ` Mike Rapoport
2022-09-05 10:28             ` Mike Rapoport
2022-09-05 12:08             ` Baoquan He
2022-09-05 12:08               ` Baoquan He
2022-09-05 12:08               ` Baoquan He
2022-09-06 13:05               ` Ard Biesheuvel
2022-09-06 13:05                 ` Ard Biesheuvel
2022-09-06 13:05                 ` Ard Biesheuvel
2022-09-08 13:33                 ` Baoquan He
2022-09-08 13:33                   ` Baoquan He
2022-09-08 13:33                   ` Baoquan He
2022-09-08 22:55                   ` Baoquan He
2022-09-08 22:55                     ` Baoquan He
2022-09-08 22:55                     ` Baoquan He
2022-09-21  7:45                 ` Mike Rapoport
2022-09-21  7:45                   ` Mike Rapoport
2022-09-21  7:45                   ` Mike Rapoport
2022-09-30  7:04                   ` Baoquan He
2022-09-30  7:04                     ` Baoquan He
2022-09-30  7:04                     ` Baoquan He
2022-09-30  9:24                     ` Baoquan He
2022-09-30  9:24                       ` Baoquan He
2022-09-30  9:24                       ` Baoquan He
2022-08-28  0:55 ` [PATCH 2/2] arm64: remove unneed defer_reserve_crashkernel() and crash_mem_map Baoquan He
2022-08-28  0:55   ` Baoquan He
2022-08-28  0:55   ` Baoquan He
2022-08-31  1:51   ` Leizhen (ThunderTown)
2022-08-31  1:51     ` Leizhen (ThunderTown)
2022-08-31  1:51     ` Leizhen (ThunderTown)
2022-08-28  1:57 ` [PATCH 0/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end Baoquan He
2022-08-28  1:57   ` Baoquan He
2022-08-28  1:57   ` Baoquan He

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=YxXPannyTqBZInAt@kernel.org \
    --to=rppt@kernel.org \
    --cc=ardb@kernel.org \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=guanghuifeng@linux.alibaba.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=thunder.leizhen@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.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.