Re: [PATCH V2 1/2] efi/unaccepted: Do not let /proc/vmcore try to access unaccepted memory

2023-09-12 Thread David Hildenbrand
On 11.09.23 13:21, Adrian Hunter wrote: Support for unaccepted memory was added recently, refer commit dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby a virtual machine may need to accept memory before it can be used. Do not let /proc/vmcore try to access unaccepted memory becaus

Re: [PATCH V2 1/2] efi/unaccepted: Do not let /proc/vmcore try to access unaccepted memory

2023-09-12 Thread David Hildenbrand
On 12.09.23 09:47, Adrian Hunter wrote: On 12/09/23 10:19, David Hildenbrand wrote: On 11.09.23 13:21, Adrian Hunter wrote: Support for unaccepted memory was added recently, refer commit dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby a virtual machine may need to acc

Re: [RFC PATCH v2 0/7] Introduce persistent memory pool

2023-09-28 Thread David Hildenbrand
On 28.09.23 12:25, Baoquan He wrote: On 09/27/23 at 09:13am, Stanislav Kinsburskii wrote: On Wed, Sep 27, 2023 at 01:44:38PM +0800, Baoquan He wrote: Hi Stanislav, On 09/25/23 at 02:27pm, Stanislav Kinsburskii wrote: This patch introduces a memory allocator specifically tailored for persisten

Re: [RFC PATCH v2 0/7] Introduce persistent memory pool

2023-09-28 Thread David Hildenbrand
On 28.09.23 15:22, Dave Hansen wrote: On 9/27/23 09:13, Stanislav Kinsburskii wrote: Once deposited, these pages can't be accessed by Linux anymore and thus must be preserved in "used" state across kexec, as hypervisor state is unware of kexec. If Linux can't access them, they're not RAM any m

Re: [PATCH 0/4] kdump: crashkernel reservation from CMA

2023-12-06 Thread David Hildenbrand
On 06.12.23 12:08, Philipp Rudo wrote: On Fri, 1 Dec 2023 17:59:02 +0100 Michal Hocko wrote: On Fri 01-12-23 16:51:13, Philipp Rudo wrote: On Fri, 1 Dec 2023 12:55:52 +0100 Michal Hocko wrote: On Fri 01-12-23 12:33:53, Philipp Rudo wrote: [...] And yes, those are all what-if concerns b

[PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

2020-09-08 Thread David Hildenbrand
iederman Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: kexec@lists.infradead.org Signed-off-by: David Hildenbrand --- include/linux/ioport.h | 4 +++- kernel/kexec_file.c| 2 +- mm/memory_hotplug.c| 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/include/linux/iopo

Re: [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

2020-09-09 Thread David Hildenbrand
On 09.09.20 09:16, Greg Kroah-Hartman wrote: > On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote: >> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is >> always set to 0 by hardware. This is far from beautiful (and confusing), >> and th

[PATCH v3 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

2020-09-10 Thread David Hildenbrand
iederman Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: kexec@lists.infradead.org Signed-off-by: David Hildenbrand --- include/linux/ioport.h | 4 +++- kernel/kexec_file.c| 2 +- mm/memory_hotplug.c| 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/include/linux/iopo

[PATCH v4 2/8] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

2020-09-11 Thread David Hildenbrand
iederman Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: kexec@lists.infradead.org Signed-off-by: David Hildenbrand --- include/linux/ioport.h | 4 +++- kernel/kexec_file.c| 2 +- mm/memory_hotplug.c| 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/include/linux/iopo

Re: [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

2020-09-15 Thread David Hildenbrand
On 15.09.20 04:20, Wei Yang wrote: > On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote: >> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is >> always set to 0 by hardware. This is far from beautiful (and confusing), >> and the bit only

[PATCH v1 3/3] kernel/resource: remove first_lvl / siblings_only logic

2021-03-22 Thread David Hildenbrand
ently. Cc: Andrew Morton Cc: Greg Kroah-Hartman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Signed-off-by: David Hildenbrand Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Hansen Cc: Keith Busch Cc: Michal Hocko Cc: Qian Cai Cc:

[PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources

2021-03-22 Thread David Hildenbrand
artman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Signed-off-by: David Hildenbrand Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Hansen Cc: Keith Busch Cc: Michal Hocko Cc: Qian Cai Cc: Oscar Salvador Cc: Eric Biederman Cc: Thomas Gleixner

[PATCH v1 2/3] kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources

2021-03-22 Thread David Hildenbrand
unction behave similar to walk_system_ram_res(). Cc: Andrew Morton Cc: Greg Kroah-Hartman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Signed-off-by: David Hildenbrand Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Hansen Cc: Keith Busch Cc: Michal Hocko

Re: [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources

2021-03-23 Thread David Hildenbrand
On 22.03.21 17:01, David Hildenbrand wrote: It used to be true that we can have busy system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels. We have two

[PATCH v1 1/3] crashdump/x86: dump any kind of "System RAM"

2021-03-23 Thread David Hildenbrand
ystem RAM now. Note: We only want to dump this memory, we don't want to add this memory to the memmap of an ordinary kexec'ed kernel ("fast system reboot"). [1] https://lkml.kernel.org/r/20210322160200.19633-1-da...@redhat.com Cc: Dan Williams Cc: Dave Hansen Cc: Baoquan He

[PATCH v1 3/3] crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k

2021-03-23 Thread David Hildenbrand
kexec, we must not expose these ranges in the firmware-provided memmap. Cc: Simon Horman Signed-off-by: David Hildenbrand --- kexec/arch/i386/crashdump-x86.c | 6 -- kexec/arch/i386/crashdump-x86.h | 3 ++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/kexec/arch/i386/cr

[PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM

2021-03-23 Thread David Hildenbrand
virtio-mem even in corner cases where we end up with a lot of individual memory ranges. David Hildenbrand (3): crashdump/x86: dump any kind of "System RAM" crashdump/x86: iterate only over actual crash memory ranges crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k k

[PATCH v1 2/3] crashdump/x86: iterate only over actual crash memory ranges

2021-03-23 Thread David Hildenbrand
No need to iterate over empty entries. Cc: Simon Horman Signed-off-by: David Hildenbrand --- kexec/arch/i386/crashdump-x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c index a301ac8..43e830a 100644 --- a

Re: [PATCH v1 3/3] kernel/resource: remove first_lvl / siblings_only logic

2021-03-23 Thread David Hildenbrand
On 23.03.21 12:11, Andy Shevchenko wrote: On Mon, Mar 22, 2021 at 05:02:00PM +0100, David Hildenbrand wrote: All IORESOURCE_SYSTEM_RAM and IORESOURCE_MEM now properly consider the whole resource tree, not just the first level. Let's drop the unused first_lvl / siblings_only logic.

Re: [PATCH v1 2/3] kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources

2021-03-23 Thread David Hildenbrand
On 23.03.21 12:08, Andy Shevchenko wrote: On Mon, Mar 22, 2021 at 05:01:59PM +0100, David Hildenbrand wrote: It used to be true that we can have system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., dax/kmem and virtio-mem

Re: [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources

2021-03-23 Thread David Hildenbrand
On 23.03.21 12:06, Andy Shevchenko wrote: On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote: It used to be true that we can have busy system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem

Re: [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources

2021-03-24 Thread David Hildenbrand
On 24.03.21 12:18, Oscar Salvador wrote: On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote: It used to be true that we can have busy system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem

[PATCH v2 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources

2021-03-25 Thread David Hildenbrand
omas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Tom Lendacky Cc: Brijesh Singh Cc: x...@kernel.org Cc: kexec@lists.infradead.org Signed-off-by: David Hildenbrand --- kernel/resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v2 3/3] kernel/resource: remove first_lvl / siblings_only logic

2021-03-25 Thread David Hildenbrand
h Cc: Michal Hocko Cc: Qian Cai Cc: Oscar Salvador Cc: Eric Biederman Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Tom Lendacky Cc: Brijesh Singh Cc: x...@kernel.org Cc: kexec@lists.infradead.org Signed-off-by: David Hildenbrand --- kernel/

[PATCH v2 2/3] kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources

2021-03-25 Thread David Hildenbrand
n" Cc: Tom Lendacky Cc: Brijesh Singh Cc: x...@kernel.org Cc: kexec@lists.infradead.org Signed-off-by: David Hildenbrand --- kernel/resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/resource.c b/kernel/resource.c index 4efd6e912279..16e0c7e8ed24 100644 --- a/ker

Re: [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM

2021-03-30 Thread David Hildenbrand
On 23.03.21 11:01, David Hildenbrand wrote: Let's properly support dumping any kind of "System RAM" that is not on the top level of the kernel resource tree in /proc/iomem, processing any /proc/iomem entry that contains "System RAM". In addition, increase the maxim

Re: [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM

2021-04-02 Thread David Hildenbrand
> Am 02.04.2021 um 12:16 schrieb Simon Horman : > > On Tue, Mar 30, 2021 at 10:58:28AM +0200, David Hildenbrand wrote: >>> On 23.03.21 11:01, David Hildenbrand wrote: >>> Let's properly support dumping any kind of "System RAM" that is not on the &g

Re: kexec-starting-kernel-problem-on-vm

2021-04-19 Thread David Hildenbrand
On 19.04.21 10:26, Baoquan He wrote: Hi Jingxian, On 04/14/21 at 03:04pm, Jingxian He wrote: We use ‘kexec –l’ and ‘kexec –e’ on our virtual machine to upgrade the linux kernel. We find that the new kernel may start fail due to checking the sha256 sum of the initrd segment checking fail with lo

Re: [PATCH 4/5] mm: rename the global section array to mem_sections

2021-05-25 Thread David Hildenbrand
On 17.05.21 13:20, Dong Aisheng wrote: In order to distinguish the struct mem_section for a better code readability and align with kernel doc [1] name below, change the global mem section name to 'mem_sections' from 'mem_section'. [1] Documentation/vm/memory-model.rst "The `mem_section` objects

Re: [PATCH V2 4/6] mm: rename the global section array to mem_sections

2021-06-01 Thread David Hildenbrand
On 31.05.21 11:19, Dong Aisheng wrote: In order to distinguish the struct mem_section for a better code readability and align with kernel doc [1] name below, change the global mem section name to 'mem_sections' from 'mem_section'. [1] Documentation/vm/memory-model.rst "The `mem_section` objects

Re: [PATCH V2 4/6] mm: rename the global section array to mem_sections

2021-06-01 Thread David Hildenbrand
On 01.06.21 10:37, Dong Aisheng wrote: On Tue, Jun 1, 2021 at 4:22 PM David Hildenbrand wrote: On 31.05.21 11:19, Dong Aisheng wrote: In order to distinguish the struct mem_section for a better code readability and align with kernel doc [1] name below, change the global mem section name to

Re: [PATCH 1/9] alpha: remove DISCONTIGMEM and NUMA

2021-06-09 Thread David Hildenbrand
memblock_reserve(virt_to_phys((void *)initrd_start), -INITRD_SIZE); - } - } -#endif /* CONFIG_BLK_DEV_INITRD */ -} - -void __init paging_init(void) -{ - unsigned long max_zone_pfn[MAX_NR_ZONES] = {0, }; -

Re: [PATCH 2/9] arc: update comment about HIGHMEM implementation

2021-06-09 Thread David Hildenbrand
node_set_online(1); Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 3/9] arc: remove support for DISCONTIGMEM

2021-06-09 Thread David Hildenbrand
On 02.06.21 12:53, Mike Rapoport wrote: 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: David Hildenbrand -- Thanks, David / dhildenb

Re: [PATCH 6/9] arch, mm: remove stale mentions of DISCONIGMEM

2021-06-09 Thread David Hildenbrand
TA() gets - * optimized to &contig_page_data at compile-time. + * For the case of non-NUMA systems the NODE_DATA() gets optimized to + * &contig_page_data at compile-time. */ static inline struct zonelist *node_zonelist(int nid, gfp_t flags) { Reviewed-by: David Hildenbrand -

Re: [PATCH 5/9] mm: remove CONFIG_DISCONTIGMEM

2021-06-09 Thread David Hildenbrand
h-order allocations like THP are likely to be - * unsupported and the premature reclaim offsets the advantage of long-term - * fragmentation avoidance. - */ -int watermark_boost_factor __read_mostly; -#else int watermark_boost_factor __read_mostly = 15000; -#endif int watermark_scale_facto

Re: [PATCH 7/9] docs: remove description of DISCONTIGMEM

2021-06-09 Thread David Hildenbrand
nown, the PFN can be used to index -appropriate `node_mem_map` array to access the `struct page` and -the offset of the `struct page` from the `node_mem_map` plus -`node_start_pfn` is the PFN of that page. - SPARSEMEM ===== Reviewed-by: David Hildenbrand

Re: [PATCH 9/9] mm: replace CONFIG_FLAT_NODE_MEM_MAP with CONFIG_FLATMEM

2021-06-09 Thread David Hildenbrand
page) { Acked-by: David Hildenbrand -- Thanks, David / dhildenb ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 8/9] mm: replace CONFIG_NEED_MULTIPLE_NODES with CONFIG_NUMA

2021-06-09 Thread David Hildenbrand
_pages(struct page *page, unsigned long pfn, unsigned int order) @@ -7276,7 +7276,7 @@ static void __ref alloc_node_mem_map(struct pglist_data *pgdat) pr_debug("%s: node %d, pgdat %08lx, node_mem_map %08lx\n", __func__, pgdat->nod

[PATCH v1 4/4] mm/memory_hotplug: indicate MEMBLOCK_DRIVER_MANAGED with IORESOURCE_SYSRAM_DRIVER_MANAGED

2021-09-27 Thread David Hildenbrand
Let's communicate driver-managed regions to memblock, to properly teach kexec_file with CONFIG_ARCH_KEEP_MEMBLOCK to not place images on these memory regions. Signed-off-by: David Hildenbrand --- mm/memory_hotplug.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v1 1/4] mm/memory_hotplug: handle memblock_add_node() failures in add_memory_resource()

2021-09-27 Thread David Hildenbrand
y ignoring the error. Signed-off-by: David Hildenbrand --- mm/memory_hotplug.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 9fd0be32a281..917b3528636d 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1384,

[PATCH v1 0/4] mm/memory_hotplug: full support for

2021-09-27 Thread David Hildenbrand
s.infradead.org David Hildenbrand (4): mm/memory_hotplug: handle memblock_add_node() failures in add_memory_resource() memblock: allow to specify flags with memblock_add_node() memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED mm/memory_ho

[PATCH v1 3/4] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED

2021-09-27 Thread David Hildenbrand
_MANAGED) next. This prepares architectures that need CONFIG_ARCH_KEEP_MEMBLOCK, such as arm64, for virtio-mem support. Signed-off-by: David Hildenbrand --- include/linux/memblock.h | 16 ++-- kernel/kexec_file.c | 5 + mm/memblock.c| 4 3 files changed,

[PATCH v1 2/4] memblock: allow to specify flags with memblock_add_node()

2021-09-27 Thread David Hildenbrand
within one memblock call. Signed-off-by: David Hildenbrand --- arch/arc/mm/init.c | 4 ++-- arch/ia64/mm/contig.c| 2 +- arch/ia64/mm/init.c | 2 +- arch/m68k/mm/mcfmmu.c| 3 ++- arch/m68k/mm/motorola.c | 6 -- arch/mips/loongso

Re: [PATCH v1 0/4] mm/memory_hotplug: full support for

2021-09-27 Thread David Hildenbrand
Intended subject was "[PATCH v1 0/4] mm/memory_hotplug: full support for add_memory_driver_managed() with CONFIG_ARCH_KEEP_MEMBLOCK" -- Thanks, David / dhildenb ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/list

[PATCH v1 3/8] proc/vmcore: let pfn_is_ram() return a bool

2021-09-28 Thread David Hildenbrand
The callback should deal with errors internally, it doesn't make sense to expose these via pfn_is_ram(). We'll rework the callbacks next. Right now we consider errors as if "it's RAM"; no functional change. Signed-off-by: David Hildenbrand --- fs/proc/vmcore.c | 8 ++

[PATCH v1 0/8] proc/vmcore: sanitize access to virtio-mem memory

2021-09-28 Thread David Hildenbrand
S. Tsirkin" Cc: Jason Wang Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Michal Hocko Cc: Oscar Salvador Cc: Mike Rapoport Cc: "Rafael J. Wysocki" Cc: x...@kernel.org Cc: xen-de...@lists.xenproject.org Cc: virtualizat...@lists.linux-foundation.org Cc: kexec@lists.in

[PATCH v1 4/8] proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks

2021-09-28 Thread David Hildenbrand
istering a callback after the vmcore has already been opened (warn and essentially read only zeroes from that point on). Signed-off-by: David Hildenbrand --- arch/x86/kernel/aperture_64.c | 13 - arch/x86/xen/mmu_hvm.c| 15 +++--- fs/proc/vmcore.c

[PATCH v1 1/8] x86/xen: update xen_oldmem_pfn_is_ram() documentation

2021-09-28 Thread David Hildenbrand
The callback is only used for the vmcore nowadays. Signed-off-by: David Hildenbrand --- arch/x86/xen/mmu_hvm.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c index 57409373750f..b242d1f4b426 100644 --- a/arch/x86/xen

[PATCH v1 2/8] x86/xen: simplify xen_oldmem_pfn_is_ram()

2021-09-28 Thread David Hildenbrand
Let's simplify return handling. Signed-off-by: David Hildenbrand --- arch/x86/xen/mmu_hvm.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c index b242d1f4b426..eb61622df75b 100644 --- a/arch/x86/xen/mmu_hvm.c

[PATCH v1 7/8] virtio-mem: factor out hotplug specifics from virtio_mem_remove() into virtio_mem_deinit_hotplug()

2021-09-28 Thread David Hildenbrand
Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) di

[PATCH v1 8/8] virtio-mem: kdump mode to sanitize /proc/vmcore access

2021-09-28 Thread David Hildenbrand
virtio_mem)" when creating the vmcore header) and a recent dracut version (including the virtio_mem module in the kdump initrd). [1] https://lkml.kernel.org/r/20210526093041.8800-1-da...@redhat.com [2] https://github.com/dracutdevs/dracut/pull/1157 Signed-off-by: David Hildenbrand ---

[PATCH v1 6/8] virtio-mem: factor out hotplug specifics from virtio_mem_probe() into virtio_mem_init_hotplug()

2021-09-28 Thread David Hildenbrand
Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 87 +++-- 1 file changed, 45 inserti

[PATCH v1 5/8] virtio-mem: factor out hotplug specifics from virtio_mem_init() into virtio_mem_init_hotplug()

2021-09-28 Thread David Hildenbrand
Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 81 - 1 file changed, 44 inserti

Re: [PATCH v1 8/8] virtio-mem: kdump mode to sanitize /proc/vmcore access

2021-09-29 Thread David Hildenbrand
[...] + +static bool virtio_mem_vmcore_pfn_is_ram(struct vmcore_cb *cb, +unsigned long pfn) +{ + struct virtio_mem *vm = container_of(cb, struct virtio_mem, +vmcore_cb); + uint64_t addr = PFN_PHYS(pfn

Re: [PATCH v1 2/8] x86/xen: simplify xen_oldmem_pfn_is_ram()

2021-09-29 Thread David Hildenbrand
How about     return a.mem_type != HVMMEM_mmio_dm; Ha, how could I have missed that :) Result should be promoted to int and this has added benefit of not requiring changes in patch 4. Can we go one step further and do @@ -20,24 +20,11 @@ static int xen_oldmem_pfn_is_ram(unsigned lon

Re: [PATCH v1 2/8] x86/xen: simplify xen_oldmem_pfn_is_ram()

2021-09-29 Thread David Hildenbrand
On 29.09.21 10:45, David Hildenbrand wrote: How about     return a.mem_type != HVMMEM_mmio_dm; Ha, how could I have missed that :) Result should be promoted to int and this has added benefit of not requiring changes in patch 4. Can we go one step further and do @@ -20,24 +20,11

Re: [PATCH v1 2/8] x86/xen: simplify xen_oldmem_pfn_is_ram()

2021-09-29 Thread David Hildenbrand
On 29.09.21 16:22, Boris Ostrovsky wrote: On 9/29/21 5:03 AM, David Hildenbrand wrote: On 29.09.21 10:45, David Hildenbrand wrote: Can we go one step further and do @@ -20,24 +20,11 @@ static int xen_oldmem_pfn_is_ram(unsigned long pfn)   struct xen_hvm_get_mem_type a

Re: [PATCH v1 2/4] memblock: allow to specify flags with memblock_add_node()

2021-09-29 Thread David Hildenbrand
On 29.09.21 18:25, Mike Rapoport wrote: 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 syst

Re: [PATCH v1 3/4] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED

2021-09-29 Thread David Hildenbrand
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_DRIVER_MANAGED. Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory like ordinary MEMBLOCK_NONE m

Re: [PATCH v1 3/4] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED

2021-10-01 Thread David Hildenbrand
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, On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote: Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MA

[PATCH v2 1/5] mm/memory_hotplug: handle memblock_add_node() failures in add_memory_resource()

2021-10-04 Thread David Hildenbrand
y ignoring the error. Signed-off-by: David Hildenbrand --- mm/memory_hotplug.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 9fd0be32a281..917b3528636d 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1384,

[PATCH v2 2/5] memblock: improve MEMBLOCK_HOTPLUG documentation

2021-10-04 Thread David Hildenbrand
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-off-by: David Hildenbrand --- include/linux/memblock.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/linux/memblock.h b/inclu

[PATCH v2 0/5] mm/memory_hotplug: full support for add_memory_driver_managed() with CONFIG_ARCH_KEEP_MEMBLOCK

2021-10-04 Thread David Hildenbrand
: linux-s...@vger.kernel.org Cc: linux...@kvack.org Cc: kexec@lists.infradead.org David Hildenbrand (5): mm/memory_hotplug: handle memblock_add_node() failures in add_memory_resource() memblock: improve MEMBLOCK_HOTPLUG documentation memblock: allow to specify flags with memblock_add_node() me

[PATCH v2 3/5] memblock: allow to specify flags with memblock_add_node()

2021-10-04 Thread David Hildenbrand
ly stumble over memblocks with wrong flags, which will be important in a follow-up patch that introduces a new flag to properly handle add_memory_driver_managed(). Acked-by: Geert Uytterhoeven Acked-by: Heiko Carstens Signed-off-by: David Hildenbrand --- arch/arc/mm/init.c | 4 ++-

[PATCH v2 4/5] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED

2021-10-04 Thread David Hildenbrand
to the system by a driver; memory might not actually be physically hotunpluggable. kexec *must not* indicate this memory to the second kernel and *must not* place kexec-images on this memory. Signed-off-by: David Hildenbrand --- include/linux/memblock.h | 16 +

[PATCH v2 5/5] mm/memory_hotplug: indicate MEMBLOCK_DRIVER_MANAGED with IORESOURCE_SYSRAM_DRIVER_MANAGED

2021-10-04 Thread David Hildenbrand
Let's communicate driver-managed regions to memblock, to properly teach kexec_file with CONFIG_ARCH_KEEP_MEMBLOCK to not place images on these memory regions. Signed-off-by: David Hildenbrand --- mm/memory_hotplug.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v2 5/9] proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks

2021-10-05 Thread David Hildenbrand
istering a callback after the vmcore has already been opened (warn and essentially read only zeroes from that point on). Signed-off-by: David Hildenbrand --- arch/x86/kernel/aperture_64.c | 13 - arch/x86/xen/mmu_hvm.c| 11 ++-- fs/proc/vmcore.c

[PATCH v2 4/9] proc/vmcore: let pfn_is_ram() return a bool

2021-10-05 Thread David Hildenbrand
The callback should deal with errors internally, it doesn't make sense to expose these via pfn_is_ram(). We'll rework the callbacks next. Right now we consider errors as if "it's RAM"; no functional change. Signed-off-by: David Hildenbrand --- fs/proc/vmcore.c | 8 ++

[PATCH v2 6/9] virtio-mem: factor out hotplug specifics from virtio_mem_init() into virtio_mem_init_hotplug()

2021-10-05 Thread David Hildenbrand
Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 81 - 1 file changed, 44 inserti

[PATCH v2 8/9] virtio-mem: factor out hotplug specifics from virtio_mem_remove() into virtio_mem_deinit_hotplug()

2021-10-05 Thread David Hildenbrand
Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) di

[PATCH v2 7/9] virtio-mem: factor out hotplug specifics from virtio_mem_probe() into virtio_mem_init_hotplug()

2021-10-05 Thread David Hildenbrand
Let's prepare for a new virtio-mem kdump mode in which we don't actually hot(un)plug any memory but only observe the state of device blocks. Signed-off-by: David Hildenbrand --- drivers/virtio/virtio_mem.c | 87 +++-- 1 file changed, 45 inserti

[PATCH v2 9/9] virtio-mem: kdump mode to sanitize /proc/vmcore access

2021-10-05 Thread David Hildenbrand
virtio_mem)" when creating the vmcore header) and a recent dracut version (including the virtio_mem module in the kdump initrd). [1] https://lkml.kernel.org/r/20210526093041.8800-1-da...@redhat.com [2] https://github.com/dracutdevs/dracut/pull/1157 Signed-off-by: David Hildenbrand ---

[PATCH v2 0/9] proc/vmcore: sanitize access to virtio-mem memory

2021-10-05 Thread David Hildenbrand
Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Michal Hocko Cc: Oscar Salvador Cc: Mike Rapoport Cc: "Rafael J. Wysocki" Cc: x...@kernel.org Cc: xen-de...@lists.xenproject.org Cc: virtualizat...@lists.linux-foundation.org Cc: kexec@lists.infradead.org Cc: linux-fsd

[PATCH v2 1/9] x86/xen: update xen_oldmem_pfn_is_ram() documentation

2021-10-05 Thread David Hildenbrand
The callback is only used for the vmcore nowadays. Reviewed-by: Boris Ostrovsky Signed-off-by: David Hildenbrand --- arch/x86/xen/mmu_hvm.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c index 57409373750f

[PATCH v2 2/9] x86/xen: simplify xen_oldmem_pfn_is_ram()

2021-10-05 Thread David Hildenbrand
Let's simplify return handling. Signed-off-by: David Hildenbrand --- arch/x86/xen/mmu_hvm.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c index b242d1f4b426..d1b38c77352b 100644 --- a/arch/x86/xen/mmu_

[PATCH v2 3/9] x86/xen: print a warning when HVMOP_get_mem_type fails

2021-10-05 Thread David Hildenbrand
Boris Ostrovsky Signed-off-by: David Hildenbrand --- arch/x86/xen/mmu_hvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/mmu_hvm.c b/arch/x86/xen/mmu_hvm.c index d1b38c77352b..6ba8826dcdcc 100644 --- a/arch/x86/xen/mmu_hvm.c +++ b/arch/x86/xen/mmu_hvm.c @@ -22,8 +

[PATCH v1] proc/vmcore: fix clearing user buffer by properly using clear_user()

2021-11-11 Thread David Hildenbrand
: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Andrew Morton Cc: Philipp Rudo Cc: kexec@lists.infradead.org Cc: linux...@kvack.org Cc: linux-fsde...@vger.kernel.org Signed-off-by: David Hildenbrand --- fs/proc/vmcore.c | 20 1 file changed, 12 insertions(+), 8 deletions(-)

[PATCH v1] proc/vmcore: don't fake reading zeroes on surprise vmcore_cb unregistration

2021-11-11 Thread David Hildenbrand
n Cc: Philipp Rudo Cc: kexec@lists.infradead.org Cc: linux...@kvack.org Cc: linux-fsde...@vger.kernel.org Signed-off-by: David Hildenbrand --- fs/proc/vmcore.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c index 30a3b66f475a..9

Re: [PATCH v1] proc/vmcore: fix clearing user buffer by properly using clear_user()

2021-11-12 Thread David Hildenbrand
On 12.11.21 08:01, Baoquan He wrote: > On 11/11/21 at 08:18pm, David Hildenbrand wrote: >> To clear a user buffer we cannot simply use memset, we have to use >> clear_user(). Using a kernel config based on rawhide Fedora and a >> virtio-mem device that registers a vmcore_cb,

Re: [PATCH v1] proc/vmcore: don't fake reading zeroes on surprise vmcore_cb unregistration

2021-11-12 Thread David Hildenbrand
On 12.11.21 04:30, Baoquan He wrote: > On 11/11/21 at 08:22pm, David Hildenbrand wrote: >> In commit cc5f2704c934 ("proc/vmcore: convert oldmem_pfn_is_ram callback >> to more generic vmcore callbacks"), we added detection of surprise >> vmcore_cb unregistration afte

Re: [PATCH v1] proc/vmcore: fix clearing user buffer by properly using clear_user()

2021-11-12 Thread David Hildenbrand
> > "that allows supervisor mode programs to optionally set user-space > > memory mappings so that access to those mappings from supervisor mode > > will cause a trap. This makes it harder for malicious programs to > > "trick" the kernel into using instructions or data from a user-space > > program

[PATCH v2] proc/vmcore: fix clearing user buffer by properly using clear_user()

2021-11-12 Thread David Hildenbrand
ffer. Fixes: 997c136f518c ("fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages") Acked-by: Baoquan He Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Andrew Morton Cc: Philipp Rudo Cc: kexec@lists.infradead.org Cc: linux...@kvack.org Cc: linux-fsde...@vger.ke

Re: [PATCH v2] proc/vmcore: fix clearing user buffer by properly using clear_user()

2021-11-16 Thread David Hildenbrand
On 15.11.21 23:04, Andrew Morton wrote: > On Fri, 12 Nov 2021 10:27:50 +0100 David Hildenbrand wrote: > >> To clear a user buffer we cannot simply use memset, we have to use >> clear_user(). With a virtio-mem device that registers a vmcore_cb and has >> some logically un

Re: [PATCH RESEND v2 3/5] mm_zone: add function to check if managed dma zone exists

2021-12-07 Thread David Hildenbrand
On 07.12.21 04:07, Baoquan He wrote: > In some places of the current kernel, it assumes that dma zone must have > managed pages if CONFIG_ZONE_DMA is enabled. While this is not always true. > E.g in kdump kernel of x86_64, only low 1M is presented and locked down > at very early stage of boot, so t

Re: [RFC v2 4/6] crash hp: generic crash hotplug support infrastructure

2021-12-08 Thread David Hildenbrand
> +#if defined(CONFIG_MEMORY_HOTPLUG) > +static int crash_memhp_notifier(struct notifier_block *nb, > + unsigned long val, void *v) > +{ > + struct memory_notify *mhp = v; > + unsigned long start, end; > + > + start = mhp->start_pfn << PAGE_SHIFT; > + end = ((mhp->start_pfn + mh

Re: [PATCH RESEND v2 3/5] mm_zone: add function to check if managed dma zone exists

2021-12-09 Thread David Hildenbrand
On 09.12.21 14:02, Baoquan He wrote: > On 12/07/21 at 12:23pm, David Hildenbrand wrote: >> On 07.12.21 04:07, Baoquan He wrote: >>> In some places of the current kernel, it assumes that dma zone must have >>> managed pages if CONFIG_ZONE_DMA is enabled. While this is

Re: [PATCH v3 3/5] mm_zone: add function to check if managed dma zone exists

2021-12-16 Thread David Hildenbrand
t; +{ > + struct pglist_data *pgdat; > + > + for_each_online_pgdat(pgdat) { > + struct zone *zone = &pgdat->node_zones[ZONE_DMA]; > + > + if (managed_zone(zone)) > + return true; > + } > + return false;

Re: [PATCH v4 2/3] dma/pool: create dma atomic pool only if dma zone has managed pages

2022-01-03 Thread David Hildenbrand
fp_t gfp) > if (prev == NULL) { > if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32)) > return atomic_pool_dma32; > - if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA)) > + if (atomic_pool_

[PATCH v1] proc/vmcore: fix false positive lockdep warning

2022-01-19 Thread David Hildenbrand
00 [6.436887] Reported-by: Baoquan He Cc: Andrew Morton Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Young Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Peter Zijlstra Cc: Boqun Feng Signed-off-by: David Hildenbrand --- Based on next-20220118 --- fs/proc/vmcore.c | 41

Re: [PATCH v1] proc/vmcore: fix false positive lockdep warning

2022-01-19 Thread David Hildenbrand
On 19.01.22 16:08, Boqun Feng wrote: > Hi, > > On Wed, Jan 19, 2022 at 12:37:02PM +0100, David Hildenbrand wrote: >> Lockdep complains that we do during mmap of the vmcore: >> down_write(mmap_lock); >> down_read(vmcore_cb_rwsem); >> And during read

Re: [PATCH v1] proc/vmcore: fix false positive lockdep warning

2022-01-19 Thread David Hildenbrand
On 19.01.22 16:15, David Hildenbrand wrote: > On 19.01.22 16:08, Boqun Feng wrote: >> Hi, >> >> On Wed, Jan 19, 2022 at 12:37:02PM +0100, David Hildenbrand wrote: >>> Lockdep complains that we do during mmap of the vmcore: >>> down_write(mmap_lock); >

[PATCH v2] proc/vmcore: fix possible deadlock on concurrent mmap and read

2022-01-19 Thread David Hildenbrand
oc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks") Cc: Andrew Morton Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Young Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Peter Zijlstra Cc: Boqun Feng Signed-off-by: David Hildenbrand --- Was: [PATCH v1

Re: [PATCH v4 02/10] crash hp: Introduce CRASH_HOTPLUG configuration options

2022-03-02 Thread David Hildenbrand
On 01.03.22 21:04, Eric DeVolder wrote: > > > On 2/22/22 21:25, Baoquan He wrote: >> On 02/09/22 at 02:56pm, Eric DeVolder wrote: >>> Support for CPU and memory hotplug for crash is controlled by the >>> CRASH_HOTPLUG configuration option, introduced by this patch. >>> >>> The CRASH_HOTPLUG_ELFCO

Re: [PATCH v4 02/10] crash hp: Introduce CRASH_HOTPLUG configuration options

2022-03-03 Thread David Hildenbrand
On 03.03.22 11:22, Baoquan He wrote: > On 03/02/22 at 10:20am, David Hildenbrand wrote: >> On 01.03.22 21:04, Eric DeVolder wrote: >>> >>> >>> On 2/22/22 21:25, Baoquan He wrote: >>>> On 02/09/22 at 02:56pm, Eric DeVolder wrote: >>>>>

Re: [PATCH v7 1/8] x86/crash: fix minor typo/bug in debug message

2022-04-28 Thread David Hildenbrand
On 13.04.22 18:42, Eric DeVolder wrote: > The pr_debug() intends to display the memsz member, but the > parameter is actually the bufsz member (which is already > displayed). Correct this to display memsz value. > > Signed-off-by: Eric DeVolder > Acked-by: Baoquan He > --

Re: [PATCH v8 2/7] crash: prototype change for crash_prepare_elf64_headers

2022-05-12 Thread David Hildenbrand
the hotplug members will be added by successive patches. > > This is preparation for later patch, no functionality change. > > Signed-off-by: Eric DeVolder > Acked-by: Baoquan He Acked-by: David Hildenbrand -- Thanks, David / dhildenb __

Re: [PATCH v8 3/7] crash: add generic infrastructure for crash hotplug support

2022-05-12 Thread David Hildenbrand
On 05.05.22 20:45, Eric DeVolder wrote: > CPU and memory change notifications are received in order to > regenerate the elfcorehdr. > > To support cpu hotplug, a callback is registered to capture the > CPUHP_AP_ONLINE_DYN online and offline events via > cpuhp_setup_state_nocalls(). > > To support

<    1   2