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
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
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
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 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
o Kirills series.
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
is_ram(pfn) ||
+ pfn_is_unaccepted_memory(pfn)) {
if (iov_iter_zero(tsz, iter) != tsz) {
ret = -EFAULT;
goto out;
Reviewed-by: David Hildenbrand
--
Chee
On 11.09.23 12:05, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 11:50:31AM +0200, David Hildenbrand wrote:
On 11.09.23 11:27, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
On 11.09.23 10:41, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023
On 11.09.23 11:27, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:42:51AM +0200, David Hildenbrand wrote:
On 11.09.23 10:41, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:03:36AM +0200, David Hildenbrand wrote:
On 06.09.23 09:39, Adrian Hunter wrote:
Support for unaccepted
On 11.09.23 10:41, Kirill A. Shutemov wrote:
On Mon, Sep 11, 2023 at 10:03:36AM +0200, David Hildenbrand wrote:
On 06.09.23 09:39, Adrian Hunter wrote:
Support for unaccepted memory was added recently, refer commit
dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
On 07.09.23 16:46, Dave Hansen wrote:
On 9/7/23 07:25, Kirill A. Shutemov wrote:
On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote:
On 9/6/23 00:39, Adrian Hunter wrote:
Support for unaccepted memory was added recently, refer commit
dcdfdd40fa82 ("mm: Add support for unaccepted
On 06.09.23 09:39, 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 map unaccepted memory because it can cause the guest
On 26.10.22 16:48, Baoquan He wrote:
On 10/25/22 at 12:31pm, Borislav Petkov wrote:
On Thu, Oct 13, 2022 at 10:57:28AM +0800, Baoquan He wrote:
The concern to range number mainly is on Virt guest systems.
And why would virt emulate 1K hotpluggable DIMM slots and not emulate a
real machine?
On 29.08.22 05:07, Linus Torvalds wrote:
> On Sun, Aug 28, 2022 at 6:56 PM Dave Young wrote:
>>
>>> John mentioned PANIC_ON().
>>
>> I would vote for PANIC_ON(), it sounds like a good idea, because
>> BUG_ON() is not obvious and, PANIC_ON() can alert the code author that
>> this will cause a
On 26.08.22 03:43, Dave Young wrote:
> Hi David,
>
> [Added more people in cc]
>
Hi Dave,
thanks for your input!
[...]
>> Side note: especially with kdump() I feel like we might see much more
>> widespread use of panic_on_warn to be able to actually extract debug
>> information in a
On 24.08.22 23:59, John Hubbard wrote:
> On 8/24/22 09:30, David Hildenbrand wrote:
>> diff --git a/Documentation/process/coding-style.rst
>> b/Documentation/process/coding-style.rst
>> index 03eb53fd029a..a6d81ff578fe 100644
>> --- a/Documentation/process/coding-style
On 25.08.22 13:43, Jani Nikula wrote:
> On Thu, 25 Aug 2022, David Hildenbrand wrote:
>> On 24.08.22 18:52, Joe Perches wrote:
>>> On Wed, 2022-08-24 at 18:31 +0200, David Hildenbrand wrote:
>>>> checkpatch does not point out that VM_BUG_ON() and friends should b
On 24.08.22 18:52, Joe Perches wrote:
> On Wed, 2022-08-24 at 18:31 +0200, David Hildenbrand wrote:
>> checkpatch does not point out that VM_BUG_ON() and friends should be
>> avoided, however, Linus notes:
>>
>> VM_BUG_ON() has the exact same semantics
On 24.08.22 18:52, Joe Perches wrote:
> On Wed, 2022-08-24 at 18:31 +0200, David Hildenbrand wrote:
>> checkpatch does not point out that VM_BUG_ON() and friends should be
>> avoided, however, Linus notes:
>>
>> VM_BUG_ON() has the exact same semantics
Cc: Lukas Bulwahn
Cc: Baoquan He
Cc: Vivek Goyal
Cc: Dave Young
David Hildenbrand (2):
coding-style.rst: document BUG() and WARN() rules ("do not crash the
kernel")
checkpatch: warn on usage of VM_BUG_ON() and friends
Documentation/process/coding-style.rst | 27 +++
mail.com
[3]
https://lore.kernel.org/r/CAHk-=wgF7K2gSSpy=m_=k3nov4zaceux9puqf1tjktjla2x...@mail.gmail.com
Signed-off-by: David Hildenbrand
---
Documentation/process/coding-style.rst | 27 ++
1 file changed, 27 insertions(+)
diff --git a/Documentation/process/codi
l not care about them for now here.
[1]
https://lore.kernel.org/r/CAHk-=wg40eazofo16eviaj7mfqdhz2gvebvfsmf6gyzsprj...@mail.gmail.com
Signed-off-by: David Hildenbrand
---
scripts/checkpatch.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl
On 01.06.22 00:25, Eric DeVolder wrote:
>
>
> On 5/31/22 08:15, David Hildenbrand wrote:
>> On 12.05.22 18:10, Eric DeVolder wrote:
>>> David,
>>> Great questions! See inline responses below.
>>> eric
>>
>> Sorry for the late reply, tr
On 26.05.22 15:39, Sourabh Jain wrote:
> Hello Eric,
>
> On 26/05/22 18:46, Eric DeVolder wrote:
>>
>>
>> On 5/25/22 10:13, Sourabh Jain wrote:
>>> Hello Eric,
>>>
>>> On 06/05/22 00:15, Eric DeVolder wrote:
When the kdump service is loaded, if a CPU or memory is hot
un/plugged, the
On 12.05.22 18:10, Eric DeVolder wrote:
> David,
> Great questions! See inline responses below.
> eric
Sorry for the late reply, travel and vacation ...
>>
>>> +
>>> +#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG)
>>> +void __weak arch_crash_handle_hotplug_event(struct kimage
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
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 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
> --
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 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
ack 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] proc/vmcore: fix false positive lockdep wa
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_l
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
n 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 ++---
1 file ch
ol *prev, gfp_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_dma &&
+{
> + struct pglist_data *pgdat;
> +
> + for_each_online_pgdat(pgdat) {
> + struct zone *zone = >node_zones[ZONE_DMA];
> +
> + if (managed_zone(zone))
> + return true;
> + }
> + return false;
> +}
> +#endif /
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
> +#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 +
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
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
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.kernel.
> > "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
> >
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
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,
@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..948691cf4a1a 100644
--- a/fs/pr
: 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(-)
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 +22,10
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_hvm.c
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
c: 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-fsde...@vger.kernel.org
Cc: linux
" 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
---
drivers/virti
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 insertions(+), 42
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(-)
diff --git
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 insertions(+), 37
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
1 file
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 | 99
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 a/mm
ver; 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 ++--
kernel/kexec_file.c
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 ++--
arch/ia64/mm
ux-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()
memb
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/include/linux/memblock.h
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,8 +1384,11
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_MANAGED
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 memory
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 system
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
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
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
[...]
+
+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 =
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 insertions(+), 37
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 insertions(+), 42
" 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
---
drivers/virti
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(-)
diff --git
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
+++ b
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
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 | 99
ang
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.infradead.org
Cc: linux-fsde...@
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
1 file
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
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/loongson64/init.c
. 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, 23 insertions(+), 2
radead.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_hotplug
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,8 +1384,11
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 a/mm
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->node_id, (unsigned long)pgdat,
(unsigned l
e *page)
{
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
N 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
--
Thanks,
Dav
high-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
) gets
- * optimized to _page_data at compile-time.
+ * For the case of non-NUMA systems the NODE_DATA() gets optimized to
+ * _page_data at compile-time.
*/
static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
{
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
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
INITRD_SIZE);
- }
- }
-#endif /* CONFIG_BLK_DEV_INITRD */
-}
-
-void __init paging_init(void)
-{
- unsigned long max_zone_pfn[MAX_NR_ZONES] = {0, };
- unsigned long dma_local_pfn;
-
- /*
-
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 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
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 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 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
> 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
>
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 maximum nu
t;
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/kernel/r
: 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/resou
1 - 100 of 197 matches
Mail list logo
