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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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.
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
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
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
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
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/
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
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
> 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
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
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
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
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
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, };
-
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
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
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
-
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
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
page)
{
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
_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
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
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,
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
_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,
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
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
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 ++
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
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
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
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
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
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
---
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
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
[...]
+
+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
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
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
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
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
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
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
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,
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
: 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
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 ++-
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 +
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
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
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 ++
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
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
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
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
---
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
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
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_
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 +
: 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(-)
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
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,
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
> > "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
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
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
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
> +#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
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
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;
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_
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
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
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);
>
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
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
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:
>>>>>
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
> --
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
__
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
101 - 198 of 198 matches
Mail list logo
