634920 to exclude the region from /proc/vmcore.
Passing the information via an iomem_resource (or by reserving the range
in the e820, which would propagate into an iomem_resource) would
reintroduce bko#72201.
Signed-off-by: Jiri Bohac
Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into re
4e0274000-4e03c8fff : Kernel bss
83100-8374f : Crash kernel
Sorry for the confusion!
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
roc/vmcore by makedumpfile. kexec would only operate
within the preallocated crashkernel area, right?
Regards,
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Tue, Nov 07, 2017 at 02:42:12PM +0100, Jiri Bohac wrote:
> On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote:
> > don't worry about the user space kexec utility either.
>
> What's the problem with the userspace kexec? The bug is in
> reading /proc/vmcore
Hi Baoquan,
On Mon, Nov 06, 2017 at 10:41:43AM +0800, Baoquan He wrote:
> Is this reproduced on a machine with GART existing and passing test with
> this patch applied? Do you have a /proc/iomem printing about the machine
> you are testing on?
I've seen this on at least three different machines.
e visible in /proc/iomem but would allow
other resources to be requested even when overlapping the region of this
special resource? This way, we could insert the "GART" resource
when allocating the hole but later, when an actual AGP driver
requests the range during PCI enumeration, the
On Wed, Nov 29, 2017 at 10:43:07AM +0800, Baoquan He wrote:
> On 11/28/17 at 10:58pm, Jiri Bohac wrote:
> > On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote:
> > > Solution:
> > > 1) Remove the code which support GART IOMMU when it's not enabled in
>
other future user of
register_oldmem_pfn_is_ram were to step on each other's toes.
Signed-off-by: Jiri Bohac
Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map")
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index f5d92bc3b884..837efa
I have a machine right here in our
lab that has this issue. It has no "enable GART" setting in BIOS. It has a
"enable IOMMU" setting. The bug stays there regardless of the setting.
It's old. Noone will fix the firmware. The patch fixes it.
Thanks,
--
Jiri Bohac
SUSE Labs, P
checks the return value. Now that we have more than
one user, I added a WARN_ON just in case agp, XEN, or any other future user of
register_oldmem_pfn_is_ram were to step on each other's toes.
Signed-off-by: Jiri Bohac
Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into reso
n case verification is not enforced and the failure is
ignored, KERN_DEBUG seems reasonable.
Regards,
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
; */
> if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
> security_locked_down(LOCKDOWN_KEXEC))
> return -EPERM;
>
> pr_debug("kernel signature verification failed (%d).\n&qu
> Signed-off-by: Lianbo Jiang
Reviewed-by: Jiri Bohac
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
and initrd.
An additional 1G will be reserved from CMA, still usable by the
production system. The crash kernel will have 1.1G memory
available. The 100M can be reliably predicted based on the size
of the kernel and initrd.
When no crashkernel=size,cma is specified, everything works as
before.
--
NULL in all calls to parse_crashkernel().
Signed-off-by: Jiri Bohac
---
arch/arm/kernel/setup.c | 2 +-
arch/arm64/mm/init.c | 2 +-
arch/loongarch/kernel/setup.c| 2 +-
arch/mips/kernel/setup.c | 2 +-
arch/powerpc/kernel/fadump.c | 2 +-
reserve_crashkernel_cma() reserves CMA ranges for the
crash kernel. If allocating the requested size fails,
try to reserve in smaller pieces.
Store the reserved ranges in the crashk_cma_ranges array
and the number of ranges in crashk_cma_cnt.
Signed-off-by: Jiri Bohac
---
include/linux
, is still needed to hold the crash
+ kernel and initrd.
cryptomgr.notests
[KNL] Disable crypto self-tests
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec mailing list
kexec
Implement the crashkernel CMA reservation for x86:
- enable parsing of the cma suffix by parse_crashkernel()
- reserve memory with reserve_crashkernel_cma()
- add the CMA-reserved ranges to the e820 map for the crash kernel
- exclude the CMA-reserved ranges from vmcore
Signed-off-by: Jiri Bohac
that DMA to user pages pinned without
FOLL_LONGTERM would still be possible. Would this be a problem in
practice? Do you see any way around it?
Thanks,
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec mailing list
kexec@lists.infradead.org
http://list
ttle memory, so the ~256 MB can be a huge part of
that. And while it's theoretically better to dump from the
hypervisor, users still often prefer kdump because the hypervisor
may not be under their control. Also, in a VM it should be much
easier to be sure the machine is safe WRT the potential DMA
corruption as it has less HW drivers. So I actually thought the
CMA reservation could be most useful on VMs.
Thanks,
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Thu, Nov 30, 2023 at 12:01:36PM +0800, Baoquan He wrote:
> On 11/29/23 at 11:51am, Jiri Bohac wrote:
> > We get a lot of problems reported by partners testing kdump on
> > their setups prior to release. But even if we tune the reserved
> > size up, OOM is still the most co
allback to kexec_file.
Without -p kexec_file_load actualy leads to a kernel oops on v6.4.0
(needs to be dubugged separately).
Signed-off-by: Jiri Bohac
Fixes: 29fe5067ed07 ("kexec: make -a the default")
---
kexec/kexec.8 | 1 +
kexec/kexec.c | 4
2 files changed, 5 insertions(+)
diff
E820_TYPE_RAM,
> E820_TYPE_RESERVED_KERN);
> -
Your tree is missing this recent commit:
7fd817c906503b6813ea3b41f5fdf4192449a707 ("x86/e820: Don't
reserve SETUP_RNG_SEED in e820").
Wouldn't this fix [/paper over] your problem as well? I.e., isn't
S
ng nr_segments,
unsigned long flags)
{
...
if (nr_segments > KEXEC_SEGMENT_MAX)
return -EINVAL;
}
Thanks,
--
Jiri Bohac
SUSE Labs, Prague, Czechia
___
kexec m
d return SIZE_MAX
on
overflow, making the kmalloc inside memdup_user cleanly fail with
-ENOMEM.
> I'll go revoke this, thanks for the review!
could you check and revoke all the above as well?
Thanks,
--
Jiri Bohac
SUSE Labs, Prague, Czechia
__
On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote:
> On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote:
> > Nice, but then why was this commit worded this way? Now we check twice?
> > Double safe? Should it be reverted?
>
> double safe's good;
the file instead of the actual ELF
header located near the end of the flattened file.
Fixes: e39216fce9f73759509ec158e39c289e6c211125 ("Make the incomplete dumpfile
generated by ENOSPC error analyzable.")
Signed-off-by: Jiri Bohac
---
makedumpfile.c | 3 +++
1 file changed, 3 insertion
On Mon, Mar 03, 2025 at 10:02:38AM +0800, Baoquan He wrote:
> On 02/20/25 at 05:55pm, Jiri Bohac wrote:
> > +static void crash_cma_clear_pending_dma(void)
> > +{
> > + if (!crashk_cma_cnt)
> > + return;
> > +
> > + mdelay(CMA_DMA_TIMEOUT
On Mon, Mar 03, 2025 at 09:25:30AM +0100, David Hildenbrand wrote:
> On 20.02.25 17:48, Jiri Bohac wrote:
> >
> > By reserving additional crashkernel memory from CMA, the main
> > crashkernel reservation can be just large enough to fit the
> > kernel and initrd image,
when the CMA reservation is
used, giving potential pending DMA transfers time to finish.
Other minor changes since v1:
- updated for 6.14-rc2
- moved #ifdefs and #defines to header files
- added __always_unused in parse_crashkernel() to silence a false
unused variable warning
--
Jiri Bohac
SUSE Labs, Prague, Czechia
DMA transfer, yet not increasing the kdump time
significantly.
Signed-off-by: Jiri Bohac
---
include/linux/crash_core.h | 5 +
kernel/crash_core.c| 10 ++
2 files changed, 15 insertions(+)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index
Describe the new crashkernel ",cma" suffix in Documentation/
Signed-off-by: Jiri Bohac
---
Documentation/admin-guide/kdump/kdump.rst | 24 +--
.../admin-guide/kernel-parameters.txt | 22 +
2 files changed, 44 insertions(+), 2 deletions(-)
Implement the crashkernel CMA reservation for x86:
- enable parsing of the cma suffix by parse_crashkernel()
- reserve memory with reserve_crashkernel_cma()
- add the CMA-reserved ranges to the e820 map for the crash kernel
- exclude the CMA-reserved ranges from vmcore
Signed-off-by: Jiri Bohac
Add a new cma_size parameter to parse_crashkernel().
When not NULL, call __parse_crashkernel to parse the CMA
reservation size from "crashkernel=size,cma" and store it
in cma_size.
Set cma_size to NULL in all calls to parse_crashkernel().
Signed-off-by: Jiri Bohac
---
arch/arm/kern
reserve_crashkernel_cma() reserves CMA ranges for the
crash kernel. If allocating the requested size fails,
try to reserve in smaller blocks.
Store the reserved ranges in the crashk_cma_ranges array
and the number of ranges in crashk_cma_cnt.
Signed-off-by: Jiri Bohac
---
include/linux
ma_size)
+{
+ if (cma_size)
+ pr_warn("crashkernel CMA reservation not supported\n");
+}
+#endif
+
#ifndef HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY
static __init int insert_crashkernel_resources(void)
{
--
Jiri Bohac
SUSE Labs, Prague, Czechia
Add a new cma_size parameter to parse_crashkernel().
When not NULL, call __parse_crashkernel to parse the CMA
reservation size from "crashkernel=size,cma" and store it
in cma_size.
Set cma_size to NULL in all calls to parse_crashkernel().
Signed-off-by: Jiri Bohac
---
arch/arm/kern
DMA transfer, yet not increasing the kdump time
significantly.
Signed-off-by: Jiri Bohac
---
include/linux/crash_core.h | 5 +
kernel/crash_core.c| 10 ++
2 files changed, 15 insertions(+)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index
Implement the crashkernel CMA reservation for x86:
- enable parsing of the cma suffix by parse_crashkernel()
- reserve memory with reserve_crashkernel_cma()
- add the CMA-reserved ranges to the e820 map for the crash kernel
- exclude the CMA-reserved ranges from vmcore
Signed-off-by: Jiri Bohac
ilence a false
unused variable warning
--
Jiri Bohac
SUSE Labs, Prague, Czechia
reservation and where less reliable kdump is
preferrable
+ to no kdump at all.
cryptomgr.notests
[KNL] Disable crypto self-tests
--
Jiri Bohac
SUSE Labs, Prague, Czechia
st setting
the fixed/default delay to 10s. Which would you prefer?
Would you prefer a command-line option, config option or a sysfs
file?
Thanks!
[1] https://lore.kernel.org/lkml/z9h10pyiflbhn...@dwarf.suse.cz/
[2] https://lore.kernel.org/lkml/z9h4e82eslkgr...@dwarf.suse.cz/
--
Jiri Bohac
SUSE Labs, Prague, Czechia
On Tue, Jun 03, 2025 at 07:02:06PM +0800, Baoquan He wrote:
> On 05/30/25 at 10:31pm, Jiri Bohac wrote:
> ..snip..
> > @@ -582,7 +582,7 @@ static void __init arch_reserve_crashkernel(void)
> >
> > ret = parse_crashkernel(boot_command_line
ivially make this configurable or
think of other improvements.
[1]
https://lore.kernel.org/lkml/a1a5af90-bc8a-448a-81fa-485624d59...@redhat.com/
--
Jiri Bohac
SUSE Labs, Prague, Czechia
On Tue, Jun 03, 2025 at 03:15:03PM +0200, David Hildenbrand wrote:
> On 30.05.25 22:29, Jiri Bohac wrote:
> > When re-using the CMA area for kdump there is a risk of pending DMA into
> > pinned user pages in the CMA area.
> >
> > Pages that are pinned long-term are
On Tue, Jun 03, 2025 at 06:25:57PM +0200, David Hildenbrand wrote:
> On 03.06.25 17:59, Jiri Bohac wrote:
> I'd phrase it more like "Pages residing in CMA areas can usually not get
> long-term pinned, so long-term pinning is typically not a concern. BUGs in
> the kernel mi
transfers time to finish before
the CMA memory is re-used by the kdump kernel.
Set CMA_DMA_TIMEOUT_SEC to 10 seconds - chosen arbitrarily as both
a huge margin for a DMA transfer, yet not increasing the kdump time
too significantly.
Signed-off-by: Jiri Bohac
Acked-by: David Hildenbrand
---
Changes
kdump)
may want to decide if the hardware is sane using its own
whitelist/blacklist...
> > I am inclined to just setting the fixed delay to 10s for now and
> > adding a sysfs knob later if someone asks for it.
> >
> > Would that work for you?
>
> Sure. We could always add such a flag later if it's really a problem for
> someone.
OK, thanks! Will post the v4 shortly.
--
Jiri Bohac
SUSE Labs, Prague, Czechia
delay to 10s for now and
adding a sysfs knob later if someone asks for it.
Would that work for you?
If you don't have other objections to the v3 series,
I'll just update it for v6.15 and post again a v4
with the 10s timeout...
Thanks for your input!
--
Jiri Bohac
SUSE Labs, Prague, Czechia
DMA transfers.
Delay the boot of the kdump kernel when the CMA reservation is
used, giving potential pending DMA transfers time to finish.
Other minor changes since v1:
- updated for 6.14-rc2
- moved #ifdefs and #defines to header files
- added __always_unused in parse_crashkernel() to silence
Add a new cma_size parameter to parse_crashkernel().
When not NULL, call __parse_crashkernel to parse the CMA
reservation size from "crashkernel=size,cma" and store it
in cma_size.
Set cma_size to NULL in all calls to parse_crashkernel().
Signed-off-by: Jiri Bohac
---
arch/arm/kern
Describe the new crashkernel ",cma" suffix in Documentation/
Signed-off-by: Jiri Bohac
---
Documentation/admin-guide/kdump/kdump.rst | 21 ++
.../admin-guide/kernel-parameters.txt | 22 +++
2 files changed, 43 insertions(+)
diff --git a/Doc
reserve_crashkernel_cma() reserves CMA ranges for the
crash kernel. If allocating the requested size fails,
try to reserve in smaller blocks.
Store the reserved ranges in the crashk_cma_ranges array
and the number of ranges in crashk_cma_cnt.
Signed-off-by: Jiri Bohac
---
Changes since v3
, yet not increasing the kdump time
too significantly.
Signed-off-by: Jiri Bohac
---
Changes since v3:
- renamed CMA_DMA_TIMEOUT_SEC to CMA_DMA_TIMEOUT_MSEC, change delay to 10
seconds
- introduce a cma_dma_timeout_sec initialized to CMA_DMA_TIMEOUT_SEC
to make the timeout trivially tunable if
Implement the crashkernel CMA reservation for x86:
- enable parsing of the cma suffix by parse_crashkernel()
- reserve memory with reserve_crashkernel_cma()
- add the CMA-reserved ranges to the e820 map for the crash kernel
- exclude the CMA-reserved ranges from vmcore
Signed-off-by: Jiri Bohac
Implement the crashkernel CMA reservation for x86:
- enable parsing of the cma suffix by parse_crashkernel()
- reserve memory with reserve_crashkernel_cma()
- add the CMA-reserved ranges to the e820 map for the crash kernel
- exclude the CMA-reserved ranges from vmcore
Signed-off-by: Jiri Bohac
Describe the new crashkernel ",cma" suffix in Documentation/
Signed-off-by: Jiri Bohac
---
Documentation/admin-guide/kdump/kdump.rst | 21 ++
.../admin-guide/kernel-parameters.txt | 22 +++
2 files changed, 43 insertions(+)
diff --git a/Doc
transfers time to finish before
the CMA memory is re-used by the kdump kernel.
Set CMA_DMA_TIMEOUT_SEC to 10 seconds - chosen arbitrarily as both
a huge margin for a DMA transfer, yet not increasing the kdump time
too significantly.
Signed-off-by: Jiri Bohac
Acked-by: David Hildenbrand
---
Changes
Add a new cma_size parameter to parse_crashkernel().
When not NULL, call __parse_crashkernel to parse the CMA
reservation size from "crashkernel=size,cma" and store it
in cma_size.
Set cma_size to NULL in all calls to parse_crashkernel().
Signed-off-by: Jiri Bohac
---
arch/arm/kern
reserve_crashkernel_cma() reserves CMA ranges for the
crash kernel. If allocating the requested size fails,
try to reserve in smaller blocks.
Store the reserved ranges in the crashk_cma_ranges array
and the number of ranges in crashk_cma_cnt.
Signed-off-by: Jiri Bohac
---
Changes since v3
nges since v1:
- updated for 6.14-rc2
- moved #ifdefs and #defines to header files
- added __always_unused in parse_crashkernel() to silence a false
unused variable warning
--
Jiri Bohac
SUSE Labs, Prague, Czechia
--
Jiri Bohac
SUSE Labs, Prague, Czechia
61 matches
Mail list logo
