(added Tejun)
On Wed, Jan 02, 2019 at 06:18:04PM +0800, Baoquan He wrote:
> On 01/02/19 at 11:27am, Mike Rapoport wrote:
> > On Wed, Jan 02, 2019 at 02:47:34PM +0800, Pingfan Liu wrote:
> > > On Mon, Dec 31, 2018 at 4:40 PM Mike Rapoport wrote:
> > > >
> > &g
On Sat, Jan 05, 2019 at 11:44:50AM +0800, Baoquan He wrote:
> On 01/04/19 at 05:09pm, Mike Rapoport wrote:
> > On Thu, Jan 03, 2019 at 10:47:06AM -0800, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Wed, Jan 02, 2019 at 07:05:38PM +0200, Mike Rapoport w
Hi Pingfan,
On Wed, Jan 09, 2019 at 09:02:41PM +0800, Pingfan Liu wrote:
> On Tue, Jan 8, 2019 at 11:49 PM Mike Rapoport wrote:
> >
> > On Tue, Jan 08, 2019 at 05:01:38PM +0800, Baoquan He wrote:
> > > Hi Mike,
> > >
> > > On 01/08/19 at 10:05am, Mik
17-October/019571.html
> Signed-off-by: Pingfan Liu
> Cc: Tang Chen
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Michal Hocko
> Cc: Jonathan Corbet
> Cc: Yaowei Bai
> Cc: Pavel Tatashin
> Cc: Nichola
On Thu, Jan 03, 2019 at 10:47:06AM -0800, Tejun Heo wrote:
> Hello,
>
> On Wed, Jan 02, 2019 at 07:05:38PM +0200, Mike Rapoport wrote:
> > I agree that currently the bottom-up allocation after the kernel text has
> > issues with KASLR. But this issues are not necessarily rela
On Fri, Jan 04, 2019 at 01:59:46PM +0800, Pingfan Liu wrote:
> On Wed, Jan 2, 2019 at 6:18 PM Baoquan He wrote:
> >
> > On 01/02/19 at 11:27am, Mike Rapoport wrote:
> > > On Wed, Jan 02, 2019 at 02:47:34PM +0800, Pingfan Liu wrote:
> > > > On Mon, D
used to
limit memblok allocations from that particular node, even in top-down mode.
> Signed-off-by: Pingfan Liu
> Cc: Tang Chen
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Michal Hocko
> Cc: Jonathan Corbet
> Cc: Yao
17-October/019571.html
> Signed-off-by: Pingfan Liu
> Cc: Tang Chen
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Michal Hocko
> Cc: Jonathan Corbet
> Cc: Yaowei Bai
> Cc: Pavel Tatashin
> Cc: Nichola
On Tue, Jan 08, 2019 at 05:01:38PM +0800, Baoquan He wrote:
> Hi Mike,
>
> On 01/08/19 at 10:05am, Mike Rapoport wrote:
> > I'm not thrilled by duplicating this code (yet again).
> > I liked the v3 of this patch [1] more, assuming we allow bottom-up mode to
> >
On Wed, Apr 03, 2019 at 11:05:45AM +0800, Chen Zhou wrote:
> After commit (arm64: kdump: support reserving crashkernel above 4G),
> there may be two crash kernel regions, one is below 4G, the other is
> above 4G.
>
> Crash dump kernel reads more than one crash kernel regions via a dtb
> property
Hi,
On Wed, Apr 03, 2019 at 09:51:27PM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/3 19:29, Mike Rapoport wrote:
> > On Wed, Apr 03, 2019 at 11:05:45AM +0800, Chen Zhou wrote:
> >> After commit (arm64: kdump: support reserving crashkernel above 4G),
> >&
Hi,
On Wed, Apr 03, 2019 at 11:05:44AM +0800, Chen Zhou wrote:
> When crashkernel is reserved above 4G in memory, kernel should
> reserve some amount of low memory for swiotlb and some DMA buffers.
>
> Kernel would try to allocate at least 256M below 4G automatically
> as x86_64 if crashkernel
Hi,
On Fri, Apr 05, 2019 at 11:47:27AM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/5 10:17, Chen Zhou wrote:
> > Hi Mike,
> >
> > On 2019/4/4 22:44, Mike Rapoport wrote:
> >> Hi,
> >>
> >> On Wed, Apr 03, 2019 at 09:51:27PM +0800, Chen
On Mon, Apr 15, 2019 at 10:27:30AM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/14 20:13, Mike Rapoport wrote:
> > Hi,
> >
> > On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
> >> After commit (arm64: kdump: support reserving crashkernel ab
Hi,
On Mon, Apr 15, 2019 at 10:05:18AM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/14 20:10, Mike Rapoport wrote:
> >>
> >> solution A:phys_addr_t start[INIT_MEMBLOCK_RESERVED_REGIONS * 2];
> >>phys_addr_t end[INIT_MEMBLOCK_RE
for reservation of multiple regions
> for the crash kernel.
>
> Signed-off-by: Chen Zhou
> Signed-off-by: Mike Rapoport
I didn't work on this version, please drop the signed-off.
> ---
> include/linux/memblock.h | 1 +
> mm/memblock.c| 45
Hi,
On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
> After commit (arm64: kdump: support reserving crashkernel above 4G),
> there may be two crash kernel regions, one is below 4G, the other is
> above 4G.
>
> Crash dump kernel reads more than one crash kernel regions via a dtb
>
.
I didn't object to memblock_cap_memory_ranges() in general, I was worried
about it's complexity and I hoped that we could find a simpler solution.
> But there are some issues as below. After fixing this, it can work correctly.
>
> On 2019/4/10 21:09, Mike Rapoport wrote:
> > Hi,
> >
> > On Tue
mblock_region regs[CRASH_MAX_USABLE_RANGES];
I only now noticed that fdt_enforce_memory_region() uses memblock_region to
pass the ranges around. If we'd switch to memblock_type instead, the
implementation of memblock_cap_memory_ranges() would be really
straightforward. Can you check if the bel
system
initialization and skips the necessity to add ARCH_DISCARD_MEMBLOCK to the
architectures that are still missing that option.
Signed-off-by: Mike Rapoport
---
arch/arm/Kconfig | 2 +-
arch/arm64/Kconfig | 1 +
arch/hexagon/Kconfig | 1 -
arch/ia64/Kconfig| 1
On Wed, May 06, 2020 at 05:41:40PM -0700, Anthony Yznaga wrote:
> The size of the memblock reserved array may be increased while preserved
> pages are being reserved. When this happens, preserved pages that have
> not yet been reserved are at risk for being clobbered when space for a
> larger
Hi,
On Sat, Oct 31, 2020 at 03:44:30PM +0800, Chen Zhou wrote:
> Move CRASH_ALIGN to header asm/kexec.h and replace the hard-coded
> alignment with macro CRASH_ALIGN in function reserve_crashkernel().
>
> Suggested-by: Dave Young
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> ---
>
On Wed, Nov 11, 2020 at 09:54:48PM +0800, Baoquan He wrote:
> On 11/11/20 at 09:27pm, chenzhou wrote:
> > Hi Baoquan,
> ...
> > >> #ifdef CONFIG_CRASH_DUMP
> > >> static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
> > >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >
On Sat, Oct 31, 2020 at 03:44:33PM +0800, Chen Zhou wrote:
> Make the functions reserve_crashkernel[_low]() as generic.
> Arm64 will use these to reimplement crashkernel=X.
>
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> ---
> arch/x86/include/asm/kexec.h | 25 ++
>
On Tue, Jun 08, 2021 at 05:25:44PM -0700, Andrew Morton wrote:
> On Tue, 8 Jun 2021 12:13:15 +0300 Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
> > configuration options
Hi,
On Mon, Jun 07, 2021 at 10:53:08AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Fri, Jun 4, 2021 at 8:50 AM Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
> > configuration opt
From: Mike Rapoport
Arc does not use DISCONTIGMEM to implement high memory, update the comment
describing how high memory works to reflect this.
Signed-off-by: Mike Rapoport
Acked-by: Vineet Gupta
---
arch/arc/mm/init.c | 13 +
1 file changed, 5 insertions(+), 8 deletions
From: Mike Rapoport
After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
configuration options are equivalent.
Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
Done with
$ sed -i 's/CONFIG_NEED_MULTIPLE_NODES/CONFIG_NUMA/' \
$(git grep -wl
From: Mike Rapoport
There are several places that mention DISCONIGMEM in comments or have stale
code guarded by CONFIG_DISCONTIGMEM.
Remove the dead code and update the comments.
Signed-off-by: Mike Rapoport
---
arch/ia64/kernel/topology.c | 5 ++---
arch/ia64/mm/numa.c | 5
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
Acked-by: Vineet Gupta
---
arch/arc/Kconfig | 13
arch/arc/include/asm/mmzone.h | 40
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
---
arch/m68k/Kconfig.cpu | 10
From: Mike Rapoport
Remove description of DISCONTIGMEM from the "Memory Models" document and
update VM sysctl description so that it won't mention DISCONIGMEM.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/sysctl/vm.rst | 12 +++
Documentation/vm/memory-model.rst
From: Mike Rapoport
After removal of the DISCONTIGMEM memory model the FLAT_NODE_MEM_MAP
configuration option is equivalent to FLATMEM.
Drop CONFIG_FLAT_NODE_MEM_MAP and use CONFIG_FLATMEM instead.
Signed-off-by: Mike Rapoport
---
include/linux/mmzone.h | 4 ++--
kernel/crash_core.c| 2
From: Mike Rapoport
NUMA is marked broken on alpha for more than 15 years and DISCONTIGMEM was
replaced with SPARSEMEM in v5.11.
Remove both NUMA and DISCONTIGMEM support from alpha.
Signed-off-by: Mike Rapoport
---
arch/alpha/Kconfig| 22 ---
arch/alpha/include/asm
From: Mike Rapoport
Hi,
SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
(long) while ago. The last architectures that used DISCONTIGMEM were
updated to use other memory models in v5.11 and it is about the time to
entirely remove DISCONTIGMEM from the kernel.
This set
From: Mike Rapoport
There are no architectures that support DISCONTIGMEM left.
Remove the configuration option and the dead code it was guarding in the
generic memory management code.
Signed-off-by: Mike Rapoport
---
include/asm-generic/memory_model.h | 37
Hi Arnd,
On Wed, Jun 09, 2021 at 01:30:39PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 4, 2021 at 8:49 AM Mike Rapoport wrote:
> >
> > From: Mike Rapoport
> >
> > Hi,
> >
> > SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
>
On Fri, Jun 11, 2021 at 01:53:48PM -0700, Stephen Brennan wrote:
> Mike Rapoport writes:
> > From: Mike Rapoport
> >
> > There are no architectures that support DISCONTIGMEM left.
> >
> > Remove the configuration option and the dead code it was guarding in the
&
Hello Miles,
On Tue, May 18, 2021 at 05:24:44PM +0800, Miles Chen wrote:
> This patches is created to fix the __pa() warning messages when
> CONFIG_DEBUG_VIRTUAL=y by unifying the allocation of pglist_data
> instances.
>
> In current implementation of node_data, if CONFIG_NEED_MULTIPLE_NODES=y,
On Wed, May 19, 2021 at 08:12:06AM +0800, Miles Chen wrote:
> On Tue, 2021-05-18 at 19:09 +0300, Mike Rapoport wrote:
> > Hello Miles,
> >
> > On Tue, May 18, 2021 at 05:24:44PM +0800, Miles Chen wrote:
> > > This patches is created to fix th
On Mon, May 31, 2021 at 07:00:59PM +0800, lijiang wrote:
> Thank you for the information, Boris and Mike.
>
> BTW: I just noticed that Mike's patch is incorrect, maybe it's a typo:
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index 7850111008a8b..e262ca858787f
On Mon, May 31, 2021 at 12:52:06PM +0200, Borislav Petkov wrote:
> On Mon, May 31, 2021 at 12:58:40PM +0300, Mike Rapoport wrote:
> > Right, but TBH, I didn't update efi_free_boot_services() in my initial
> > version. I've added similar change there now and I'm waiting now to se
From: Mike Rapoport
Hi,
SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
(long) while ago. The last architectures that used DISCONTIGMEM were
updated to use other memory models in v5.11 and it is about the time to
entirely remove DISCONTIGMEM from the kernel.
This set
From: Mike Rapoport
NUMA is marked broken on alpha for more than 15 years and DISCONTIGMEM was
replaced with SPARSEMEM in v5.11.
Remove both NUMA and DISCONTIGMEM support from alpha.
Signed-off-by: Mike Rapoport
---
arch/alpha/Kconfig| 22 ---
arch/alpha/include/asm
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
---
arch/arc/Kconfig | 13
arch/arc/include/asm/mmzone.h | 40
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
---
arch/m68k/Kconfig.cpu | 10 --
arch/m68k/include/asm/page.h| 2 +-
arch/m68k/include
From: Mike Rapoport
After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
configuration options are equivalent.
Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
Done with
$ sed -i 's/CONFIG_NEED_MULTIPLE_NODES/CONFIG_NUMA/' \
$(git grep -wl
From: Mike Rapoport
Remove description of DISCONTIGMEM from the "Memory Models" document and
update VM sysctl description so that it won't mention DISCONIGMEM.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/sysctl/vm.rst | 12 +++
Documentation/vm/memory-model.rst
On Wed, Jun 02, 2021 at 01:25:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Wed, Jun 2, 2021 at 12:54 PM Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
> > in
From: Mike Rapoport
Arc does not use DISCONTIGMEM to implement high memory, update the comment
describing how high memory works to reflect this.
Signed-off-by: Mike Rapoport
---
arch/arc/mm/init.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arc/mm
From: Mike Rapoport
There are no architectures that support DISCONTIGMEM left.
Remove the configuration option and the dead code it was guarding in the
generic memory management code.
Signed-off-by: Mike Rapoport
---
include/asm-generic/memory_model.h | 37
From: Mike Rapoport
There are several places that mention DISCONIGMEM in comments or have stale
code guarded by CONFIG_DISCONTIGMEM.
Remove the dead code and update the comments.
Signed-off-by: Mike Rapoport
---
arch/ia64/kernel/topology.c | 5 ++---
arch/ia64/mm/numa.c | 5
From: Mike Rapoport
After removal of the DISCONTIGMEM memory model the FLAT_NODE_MEM_MAP
configuration option is equivalent to FLATMEM.
Drop CONFIG_FLAT_NODE_MEM_MAP and use CONFIG_FLATMEM instead.
Signed-off-by: Mike Rapoport
---
include/linux/mmzone.h | 4 ++--
kernel/crash_core.c| 2
From: Mike Rapoport
After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
configuration options are equivalent.
Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
Done with
$ sed -i 's/CONFIG_NEED_MULTIPLE_NODES/CONFIG_NUMA/' \
$(git grep -wl
From: Mike Rapoport
Arc does not use DISCONTIGMEM to implement high memory, update the comment
describing how high memory works to reflect this.
Signed-off-by: Mike Rapoport
---
arch/arc/mm/init.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arc/mm
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
---
arch/m68k/Kconfig.cpu | 10
From: Mike Rapoport
NUMA is marked broken on alpha for more than 15 years and DISCONTIGMEM was
replaced with SPARSEMEM in v5.11.
Remove both NUMA and DISCONTIGMEM support from alpha.
Signed-off-by: Mike Rapoport
---
arch/alpha/Kconfig| 22 ---
arch/alpha/include/asm
From: Mike Rapoport
There are several places that mention DISCONIGMEM in comments or have stale
code guarded by CONFIG_DISCONTIGMEM.
Remove the dead code and update the comments.
Signed-off-by: Mike Rapoport
---
arch/ia64/kernel/topology.c | 5 ++---
arch/ia64/mm/numa.c | 5
From: Mike Rapoport
After removal of the DISCONTIGMEM memory model the FLAT_NODE_MEM_MAP
configuration option is equivalent to FLATMEM.
Drop CONFIG_FLAT_NODE_MEM_MAP and use CONFIG_FLATMEM instead.
Signed-off-by: Mike Rapoport
---
include/linux/mmzone.h | 4 ++--
kernel/crash_core.c| 2
From: Mike Rapoport
Remove description of DISCONTIGMEM from the "Memory Models" document and
update VM sysctl description so that it won't mention DISCONIGMEM.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/sysctl/vm.rst | 12 +++
Documentation/vm/memory-model.rst
From: Mike Rapoport
Hi,
SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
(long) while ago. The last architectures that used DISCONTIGMEM were
updated to use other memory models in v5.11 and it is about the time to
entirely remove DISCONTIGMEM from the kernel.
This set
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
---
arch/arc/Kconfig | 13
arch/arc/include/asm/mmzone.h | 40
From: Mike Rapoport
There are no architectures that support DISCONTIGMEM left.
Remove the configuration option and the dead code it was guarding in the
generic memory management code.
Signed-off-by: Mike Rapoport
---
include/asm-generic/memory_model.h | 37
On Fri, Jun 04, 2021 at 02:07:39PM +, Vineet Gupta wrote:
> On 6/3/21 11:49 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
> > in v5.11.
> >
> > Remove the support fo
On Mon, May 31, 2021 at 11:08:32AM +0200, Borislav Petkov wrote:
> + Mike.
>
> On Mon, May 31, 2021 at 05:00:23PM +0800, Lianbo Jiang wrote:
> > Some sub-1MB memory regions may be reserved by EFI boot services, and the
> > memory regions will be released later in the efi_free_boot_services().
> >
b folder to use new header.
> Though for time being include new header back to kernel.h to avoid twisted
> indirected includes for existing users.
>
> Signed-off-by: Andy Shevchenko
Acked-by: Mike Rapoport
> ---
> arch/powerpc/kernel/setup-common.c | 1 +
> arch/
On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Mon, Aug 16, 2021 at 7:52 AM Mike Rapoport wrote:
> > On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> > > Prepare for early_init_fdt_scan_reserved_mem() reserving t
Hi Geert,
On Wed, Aug 11, 2021 at 10:50:59AM +0200, Geert Uytterhoeven wrote:
> Prepare for early_init_fdt_scan_reserved_mem() reserving the memory
> occupied by an elf core header described in the device tree.
> As arch_mem_init() calls early_init_fdt_scan_reserved_mem() before
>
On Mon, Aug 23, 2021 at 09:44:55AM -0500, Rob Herring wrote:
> On Mon, Aug 23, 2021 at 8:10 AM Mike Rapoport wrote:
> >
> > On Mon, Aug 23, 2021 at 12:17:50PM +0200, Geert Uytterhoeven wrote:
> > > Hi Mike,
> > >
> > > On Mon, Aug 16, 2021 at 7:52 AM Mi
On Mon, Sep 27, 2021 at 05:05:16PM +0200, David Hildenbrand wrote:
> We want to specify flags when hotplugging memory. Let's prepare to pass
> flags to memblock_add_node() by adjusting all existing users.
>
> Note that when hotplugging memory the system is already up and running
> and we don't
Hi,
On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED.
> Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory
> like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory
>
On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> On 29.09.21 18:39, Mike Rapoport wrote:
> > Hi,
> >
> > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> > > Let's add a flag that corresponds to IORESOURCE_SYSRAM
On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote:
> On 30.09.21 23:21, Mike Rapoport wrote:
> > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> > > On 29.09.21 18:39, Mike Rapoport wrote:
> > > > Hi,
> > > >
> &
; Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed
pluggable. kexec *must not* indicate this memory to
> the second kernel and *must not* place kexec-images on this memory.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> include/linux/memblock.h | 16 ++--
> kernel/kexec_file.c
t Uytterhoeven
> Acked-by: Heiko Carstens
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> arch/arc/mm/init.c | 4 ++--
> arch/ia64/mm/contig.c| 2 +-
> arch/ia64/mm/init.c | 2 +-
> arch/m68k/mm/mcfm
Hi,
On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote:
> On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote:
> > Add two global variables (cap_mem_addr and cap_mem_size) for storing a
> > base address and size, describing a limited region in which memory may
> > be
Hi Geert,
On Mon, Jul 19, 2021 at 08:59:03AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport wrote:
> > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote:
> > > On Wed, Jul 14, 2021 at 02:50:12PM +0200,
On Tue, Jan 11, 2022 at 08:44:41PM +, Frank van der Linden wrote:
> On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote:
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_
On Mon, Jan 10, 2022 at 09:08:07PM +, Frank van der Linden wrote:
> Some architectures might limit the usable memory range based
> on a firmware property, like "linux,usable-memory-range"
> for ARM crash kernels. This limit needs to be enforced after
> firmware memory map processing has been
On Tue, Jan 11, 2022 at 08:44:41PM +, Frank van der Linden wrote:
> On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote:
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_
Hi Baoquan,
On Thu, Aug 25, 2022 at 03:35:04PM +0800, Baoquan He wrote:
> Add kexec list in CC
>
> On 08/19/22 at 07:11am, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Hi,
> >
> > There were several rounds of discussion how to remap with ba
On Sun, Aug 28, 2022 at 04:37:29PM +0800, Baoquan He wrote:
> On 08/25/22 at 10:48am, Mike Rapoport wrote:
> ..
> > > > There were several rounds of discussion how to remap with base pages
> > > > only
> > > > the crash kernel area, t
On Sun, Aug 28, 2022 at 08:55:44AM +0800, Baoquan He wrote:
> Problem:
> ===
> On arm64, block and section mapping is supported to build page tables.
> However, currently it enforces to take base page mapping for the whole
> linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and
On Wed, Aug 31, 2022 at 10:29:39PM +0800, Baoquan He wrote:
> On 08/31/22 at 10:37am, Mike Rapoport wrote:
> > On Sun, Aug 28, 2022 at 08:55:44AM +0800, Baoquan He wrote:
> > >
> > > Solution:
> > > =
> > > To fix the problem, we should alway
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:
>
> stat
with disabling crash kernel protection when its memory
reservation is deferred and then Baoquan and kdump folks can take it from
here.
>From 6430407f784f3571da9b4d79340487f2647a44ab Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Wed, 21 Sep 2022 10:14:46 +0300
Subject: [PATCH] arm64/mm: don
t
> vm_flags modification attempts.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/kvm/book3s_hv_uvmem.c | 5 -
> arch/s390/mm/gmap.c| 5 -
> mm/khugepaged.c| 2 ++
> mm/ksm.c
On Wed, Jan 25, 2023 at 12:38:47AM -0800, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
&
rea_struct *vma,
> + unsigned long flags)
I'd suggest to make it vm_flags_init() etc.
Except that
Acked-by: Mike Rapoport (IBM)
> +{
> + vma->vm_flags = flags;
> +}
> +
> +/* Use when VMA is part of the VMA tree and modif
On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by:
On Wed, Jan 25, 2023 at 12:38:50AM -0800, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in
On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > vm_flags are among VMA attributes which affect decisions like VMA merging
> > and splitting. Therefore all vm_flags modifications are performed a
m() function.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> mm/debug.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/debug.c b/mm/debug.c
> index 9d3d893dc7f4..96d594e16292 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
>
clude/asm/kexec.h| 6 -
> arch/arm64/include/asm/memory.h | 5
> arch/arm64/kernel/machine_kexec.c | 20 --
> arch/arm64/mm/init.c | 6 +
> arch/arm64/mm/mmu.c | 43 ---
> 5 files changed, 1 insertion(+), 79 deletions(-)
Acked-by: Mike Rapoport (IBM)
> --
> 2.34.1
>
--
Sincerely yours,
Mike.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Hi Alex,
On Wed, Jan 17, 2024 at 02:46:56PM +, Alexander Graf wrote:
> We now have all bits in place to support KHO kexecs. This patch adds
> awareness of KHO in the kexec file as well as boot path for x86 and
> adds the respective kconfig option to the architecture so that it can
> use KHO
96 matches
Mail list logo
