Re: [PATCH] aarch64: kern_paddr_start calculation makes more accurate legacy check
On Sun, Aug 27, 2023 at 4:23 AM Alexander Kamensky
wrote:
>
> Hi Pingfan,
>
> Please see inline
>
> On Thu, Aug 24, 2023 at 11:17 PM Pingfan Liu wrote:
> >
> > On Sun, Aug 20, 2023 at 3:16 AM Alexander Kamensky
> > wrote:
> > >
> > > In the latest openembedded with aarch64 image that uses 6.4.3 kernel on
> > > qemu I
> > > tried to run makedumpfile in secondary kernel with /proc/vmcore. It
> > > failed as
> > > follows:
> > >
> > > > root@qemuarm64:~# makedumpfile -c -F /proc/vmcore > /dev/null
> > > > read_from_vmcore: Can't seek the dump memory(/proc/vmcore). (offset:
> > > > ffc0123fa000) Invalid argument
> > > > readpage_elf: Can't read the dump memory(/proc/vmcore).
> > > >
> > >
> > > It turns out that not all parts for /proc/vmcore are readable:
> > >
> > > > root@qemuarm64:~# cat /proc/vmcore > /dev/null
> > > > [ 136.394931] Internal error: synchronous external abort:
> > > > 9610 [#1] PREEMPT SMP
> > > > [ 136.422434] Modules linked in:
> > > >
> > >
> > > Binary search of different kernel versions I found that the issue goes
> > > back to
> > > 5.11. It works fine with 5.10 version of the kernel.
> > >
> > > After running secondary kernel under qemu gdb, I've found that the
> > > primary kernel
> > > main memory segment in elfcorehdr has wrong address and size.
> > >
> > > Looking at kexec output with debug enabled at the time when it loads
> > > secondary
> > > crash kernel I saw the following:
> > >
> > > > Kernel text Elf header: p_type = 1, p_offset = 0x403020 p_paddr =
> > > > 0x403020 p_vaddr = 0x p_filesz = 0xffc01141
> > > > p_memsz = 0xffc01141
> > >
> > > These values come from elf_info variable and are set in
> > > iomem_range_callback
> > > function. The function gets the following input on my system:
> > >
> > > root@qemuarm64:~# cat /proc/iomem | grep "Kernel code"
> > > 4021-40fe : Kernel code
> > > root@qemuarm64:~# cat /proc/kallsyms | grep -e ' _text$'
> >
> > This is the crux of the problem. Could you say something about how it
> > disappeared?
>
> Here is what I found:
>
> * in kallsyms .tmp_vmlinux.kallsyms1.syms _text I have this:
>
> ffc00800 T _text
> ffc00801 T __irqentry_text_start
> ffc00801 T _stext
>
> * in scripts/kallsyms.c ranges defined as
>
> static struct addr_range text_ranges[] = {
> { "_stext", "_etext" },
> { "_sinittext", "_einittext" },
> };
>
> * as a result _text fails check_symbol_range function its not included in
> kallsyms
>
> * from 'gdb vmlinux'
>
> (gdb) p _text
> $1 = 0xffc00800 <_text> "MZ@\372'd>\024"
> (gdb) p _stext
> $2 = 0xffc00801 <_stext> "\037 \003\325\037 \003\325\037
> \003\325\037 \003\325?#\003\325\375{\273\251\375\003"
>
> * from kernel linker script ./arch/arm64/kernel/vmlinux.lds, note
> _stext follows _text and aligned by 0x0001
>
> OUTPUT_ARCH(aarch64)
> ENTRY(_text)
> jiffies = jiffies_64;
> PECOFF_FILE_ALIGNMENT = 0x200;
> SECTIONS
> {
> /DISCARD/ : { *(.exitcall.exit) *(.discard) *(.discard.*) *(.modinfo)
> *(.gnu.version*) }
> /DISCARD/ : {
> *(.interp .dynamic)
> *(.dynsym .dynstr .hash .gnu.hash)
> }
> . = -(((1)) << 39))) - 1 + (0x0800)));
> .head.text : {
> _text = .; // <
> KEEP(*(.head.text))
> }
> .text : ALIGN(0x0001) { // <
> _stext = .; // <---
>. = ALIGN(8); __irqentry_text_start = .; *(.irqentry.text)
> __irqentry_text_end = .;
>. = ALIGN(8); __softirqentry_text_start = .; *(.softirqentry.text)
> __softirqentry_text_end = .;
>
> * ./arch/arm64/kernel/vmlinux.lds is preproccessed file from
> arch/arm64/kernel/vmlinux.lds.S, here are relevant snippets:
>
> .head.text : {
> _text = .;
> HEAD_TEXT
> }
> .text : ALIGN(SEGMENT_ALIGN) {/* Real text segment*/
> _stext = .;/* Text and read-only data*/
> IRQENTRY_TEXT
> SOFTIRQENTRY_TEXT
>
> * and SEGMENT_ALIGN defined in
>
> arch/arm64/include/asm/memory.h:#define SEGMENT_ALIGN SZ_64K
>
> * symbol_valid function from scripts/kallsyms.c will ignore range
> check if --all-symbols option is passed
>
> * from scripts/link-vmlinux.sh one can see that --all-symbols will be
> added only if CONFIG_KALLSYMS_ALL is enabled
>
> kallsyms()
> {
> local kallsymopt;
>
> if is_enabled CONFIG_KALLSYMS_ALL; then
> kallsymopt="${kallsymopt} --all-symbols"
> fi
>
> * in my kernel CONFIG_KALLSYMS_ALL is not set
>
> * I've checked aarch64 fedora 38 kernel config in there
> CONFIG_KALLSYMS_ALL is enabled that explains why you see this _text in
> kallsyms of fedora
>
> * so far it seems that _text address cannot be part of kallsyms unless
> CONFIG_KALLSYMS_ALL is enabled or original _text is 64k aligned so it
> will coincide with _stext
>
> * in all my
Re: [RFC PATCH] Introduce persistent memory pool
+kexec, iommu, kvm On 23.08.23 04:45, Stanislav Kinsburskii wrote: +akpm, +linux-mm On Fri, Aug 25, 2023 at 01:32:40PM +, Gowans, James wrote: On Fri, 2023-08-25 at 10:05 +0200, Greg Kroah-Hartman wrote: Thanks for adding me to this thread Greg! On Tue, Aug 22, 2023 at 11:34:34AM -0700, Stanislav Kinsburskii wrote: This patch addresses the need for a memory allocator dedicated to persistent memory within the kernel. This allocator will preserve kernel-specific states like DMA passthrough device states, IOMMU state, and more across kexec. The proposed solution offers a foundational implementation for potential custom solutions that might follow. Though the implementation is intentionally kept concise and straightforward to foster discussion and feedback, it's fully functional in its current state. Hi Stanislav, it looks like we're working on similar things. I'm looking to develop a mechanism to support hypervisor live update for when KVM is running VMs with PCI device passthrough. VMs with device passthrough also necessitates passing and re-hydrating IOMMU state so that DMA can continue during live update. Planning on having an LPC session on this topic: https://lpc.events/event/17/abstracts/1629/ (currently it's only a submitted abstract so not sure if visible, hopefully it will be soon). We are looking at implementing persistence across kexec via an in-memory filesystem on top of reserved memory. This would have files for anything that needs to be persisted. That includes files for IOMMU pgtables, for guest memory or userspace-accessible memory. It may be nice to solve all kexec persistence requirements with one solution, but we can consider IOMMU separately. There are at least three ways that this can be done: a) carving out reserved memory for pgtables. This is done by your proposal here, as well as my suggestion of a filesystem. b) pre/post kexec hooks for drivers to serialise state and pass it across in a structured format from old to new kernel. c) Reconstructing IOMMU state in the new kernel by starting at the hardware registers and walking the page tables. No state passing needed. Have you considered option (b) and (c) here? One of the implications of (b) and (c) are that they would need to hook into the buddy allocator really early to be able to carve out the reconstructed page tables before the allocator is used. Similar to how pkram [0] hooks in early to carve out pages used for its filesystem. Hi James, We are indeed working on similar things, so thanks for chiming in. I've seen pkram proposal as well as your comments there. I think (b) will need some persistent-over-kexec memory to pass the state across kexec as well as some key-value store persisted as well. And the proposed persistent memory pool is aimed exactly for this purpose. Or do you imply some other way to pass driver's data accross kexec? If I had to build this, I'd probably do it just like device tree passing on ARM. It's a single, physically contiguous blob of data whose entry point you pass to the target kernel. IIRC ACPI passing works similarly. This would just be one more opaque data structure that then needs very strict versioning and forward/backward compat guarantees. I dind't consider (c) yet, thanks for for the pointer. I have a question in this scope: how is PCI devices registers state is persisted across kexec with the files system you are working on? I.e. how does driver know, that the device shouldn't not be reinitialized? The easiest way to do it initially would be kernel command line options that hack up the drivers. But I suppose depending on the option we go with, you can also use the respective "natural" path: (a) A special metadata file that explains the state to the driver (b) An entry in the structured file format that explains the state to the target driver (c) Compatible target drivers try to enumerate state from the target device's register file Potential applications include: 1. Allowing various in-kernel entities to allocate persistent pages from a singular memory pool, eliminating the need for multiple region reservations. 2. For in-kernel components that require the allocation address to be available on kernel kexec, this address can be exposed to user space and then passed via the command line. Do you have specific examples of other state that needs to be passed across? Trying to see whether tailoring specifically to the IOMMU case is okay. Conceptually IOMMU state can be reconstructed starting with hardware registers, not needing reserved memory. Other use-cases may not have this option. Well, basically it's IOMMU state and PCI devices to skip/avoid initializing. I bet there can be other misc (and unrelated things) like persistent filesystems, block devices, etc. But I don't have a solid set of use cases to present. Would be great if you could think through the problem space until LPC so we can have a solid
RE: kexec reports "Cannot get kernel _text symbol address" on arm64 platform
> -Original Message- > From: Alexander Kamensky > Sent: Thursday, August 24, 2023 8:35 PM > To: Pandey, Radhey Shyam > Cc: b...@redhat.com; pi...@redhat.com; kexec@lists.infradead.org; linux- > ker...@vger.kernel.org; Sarangi, Anirudha > Subject: Re: kexec reports "Cannot get kernel _text symbol address" on > arm64 platform > > On Wed, Aug 23, 2023 at 12:09 PM Pandey, Radhey Shyam > wrote: > > > > > -Original Message- > > > From: Alexander Kamensky > > > Sent: Tuesday, August 22, 2023 9:24 AM > > > To: Pandey, Radhey Shyam > > > Cc: b...@redhat.com; pi...@redhat.com; kexec@lists.infradead.org; > > > linux- ker...@vger.kernel.org; Sarangi, Anirudha > > > > > > Subject: Re: kexec reports "Cannot get kernel _text symbol address" > > > on > > > arm64 platform > > > > > > Hi All, > > > > > > Sorry for the top post, but I believe that I might have posted a fix > > > for this issue a couple days ago. > > > > > > Please check and see if it helps > > > https://lore.kernel.org/kexec/20230819191119.975299-1- > > > alexander.kamensk...@gmail.com/T/#u > > > > > > Explanation for the issue I observed with a similar secondary kernel > > > traceback on arm64 is in the commit message. > > > > I fetched latest kexec sources > > (777ca453ca69e46f7376b07ba6727bd261ec97ef) > > and applied above patch, a bit improved but still vmcore size is huge. > > > > / # ls -lrth /proc/vmcore > > -r1 root root 15.5G Aug 23 18:55 /proc/vmcore > > > How big is your system memory? If it is 16G then the above is normal. Yes, it's 16G. > > The most important thing is can your secondary kernel read it? For example > > cat /proc/vmcore > /dev/null This runs fine and I can read /proc/vmcore > > If you want to capture only kernel core out of /proc/vmcore you need to use > makedumpfile to filter out the rest of the memory. Thanks for the pointers. I could use makedumpfile to extract dmesg dump and it pointed to system Kernel dump correctly also compress dump data. Further exploring on it and will report how the analysis goes. xilinx-vck190-20232:/run/media/mmcblk0p1# makedumpfile -c --split -d 3 /proc/vmcore dumpfile1 dumpfile2 The kernel version is not supported. The makedumpfile operation may be incomplete. Checking for memory holes : [100.0 %] | Checking for memory holes : [100.0 %] | Checking for memory holes : [100.0 %] / Checking for memory holes : [100.0 %] / Checking for memory holes : [100.0 %] | Checking for memory holes : [100.0 %] | Checking for memory holes : [100.0 %] \ Checking for memory holes : [100.0 %] \ Checking for memory holes : [100.0 %] | Checking for memory holes : [100.0 %] | Checking for memory holes : [100.0 %] - Checking for memory holes : [100.0 %] - Copying data : [ 45.7 %] -eta: 6m13s Copying data : [ 54.1 %] - eta: 1s The dumpfiles are saved to dumpfile1, and dumpfile2. makedumpfile Completed. > > Thanks, > Alexander > > > Thanks, > > Radhey ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 5/8] crash_core: add generic function to do reservation
On 08/27/23 at 09:53pm, kernel test robot wrote: > Hi Baoquan, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on tip/x86/core] > [also build test ERROR on powerpc/next powerpc/fixes linus/master v6.5-rc7] > [cannot apply to arm64/for-next/core next-20230825] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: > https://github.com/intel-lab-lkp/linux/commits/Baoquan-He/crash_core-c-remove-unnecessary-parameter-of-function/20230827-181555 > base: tip/x86/core > patch link: > https://lore.kernel.org/r/20230827101128.70931-6-bhe%40redhat.com > patch subject: [PATCH 5/8] crash_core: add generic function to do reservation > config: csky-defconfig > (https://download.01.org/0day-ci/archive/20230827/202308272150.p3krkmof-...@intel.com/config) > compiler: csky-linux-gcc (GCC) 13.2.0 > reproduce: > (https://download.01.org/0day-ci/archive/20230827/202308272150.p3krkmof-...@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version > of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: > https://lore.kernel.org/oe-kbuild-all/202308272150.p3krkmof-...@intel.com/ Thanks for reporting this. The error is caused by patch 3: [PATCH 3/8] include/linux/kexec.h: move down crash_core.h including In this lkp's config, CONFIG_CRASH_CORE=y and CONFIG_KEXEC_CORE=n, the moving down of crash_core.h including will triger the error. I will think of another way to fix this. > > All errors (new ones prefixed by >>): > > 537 | void __weak arch_crash_save_vmcoreinfo(void) > | ^~ >kernel/crash_core.c:540:20: warning: no previous prototype for > 'paddr_vmcoreinfo_note' [-Wmissing-prototypes] > 540 | phys_addr_t __weak paddr_vmcoreinfo_note(void) > |^ >kernel/crash_core.c: In function 'crash_save_vmcoreinfo_init': >kernel/crash_core.c:554:45: error: 'VMCOREINFO_NOTE_SIZE' undeclared > (first use in this function) > 554 | vmcoreinfo_note = alloc_pages_exact(VMCOREINFO_NOTE_SIZE, > | ^~~~ >kernel/crash_core.c:563:9: error: implicit declaration of function > 'VMCOREINFO_OSRELEASE' [-Werror=implicit-function-declaration] > 563 | VMCOREINFO_OSRELEASE(init_uts_ns.name.release); > | ^~~~ >kernel/crash_core.c:564:9: error: implicit declaration of function > 'VMCOREINFO_BUILD_ID' [-Werror=implicit-function-declaration] > 564 | VMCOREINFO_BUILD_ID(); > | ^~~ >kernel/crash_core.c:565:9: error: implicit declaration of function > 'VMCOREINFO_PAGESIZE' [-Werror=implicit-function-declaration] > 565 | VMCOREINFO_PAGESIZE(PAGE_SIZE); > | ^~~ >kernel/crash_core.c:567:9: error: implicit declaration of function > 'VMCOREINFO_SYMBOL' [-Werror=implicit-function-declaration] > 567 | VMCOREINFO_SYMBOL(init_uts_ns); > | ^ >kernel/crash_core.c:568:9: error: implicit declaration of function > 'VMCOREINFO_OFFSET' [-Werror=implicit-function-declaration] > 568 | VMCOREINFO_OFFSET(uts_namespace, name); > | ^ >kernel/crash_core.c:568:27: error: 'uts_namespace' undeclared (first use > in this function) > 568 | VMCOREINFO_OFFSET(uts_namespace, name); > | ^ >kernel/crash_core.c:568:42: error: 'name' undeclared (first use in this > function) > 568 | VMCOREINFO_OFFSET(uts_namespace, name); > | ^~~~ >kernel/crash_core.c:571:9: error: implicit declaration of function > 'VMCOREINFO_SYMBOL_ARRAY' [-Werror=implicit-function-declaration] > 571 | VMCOREINFO_SYMBOL_ARRAY(swapper_pg_dir); > | ^~~ >kernel/crash_core.c:588:9: error: implicit declaration of function > 'VMCOREINFO_STRUCT_SIZE' [-Werror=implicit-function-declaration] > 588 | VMCOREINFO_STRUCT_SIZE(page); > | ^~ >kernel/crash_core.c:588:32: error: 'page' undeclared (first use in this > function) > 588 | VMCOREINFO_STRUCT_SIZE(page); > |^~~~ >kernel/crash_core.c:589:32: error: 'pglist_data' undeclared (first use in > this function) > 589 | VMCOREINFO_STRUCT_SIZE(pglist_data); > |^~~ >kernel/crash_core.c:590:32: error: 'zone' undeclared (first use in this > function) > 590 |
Re: [PATCH] kexec: update manpage with explicit mention of clean kexec
On 28/08/23 1:18 pm, Simon Horman wrote: On Mon, Aug 28, 2023 at 11:46:14AM +0530, Hari Bathini wrote: Any comments on this, please.. Hi Hari, Sorry, I had missed this. No worries. Thanks for the response. On 07/07/23 10:59 am, Hari Bathini wrote: While the manpage does mention about kexec boot with a clean shutdown, it is not explicit about it. Make it explicit. Signed-off-by: Hari Bathini --- kexec/kexec.8 | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/kexec/kexec.8 b/kexec/kexec.8 index 3a344c5..87e4ab5 100644 --- a/kexec/kexec.8 +++ b/kexec/kexec.8 @@ -95,8 +95,16 @@ then you would use the following command to load the kernel: .RB "\-\-append=" "root=/dev/hda1" "\ \-\-initrd=" /boot/initrd .RE .PP -After this kernel is loaded, it can be booted to at any time using the -command: +After this kernel is loaded, assuming your Linux distribution supports +kexec-based rebooting, it can be booted to, with a clean shutdown, using +the command: Perhaps user-space would be better than "your Linux distribution". But perhaps that is just kernel developer speak and makes less sense to others. No strong inclination to putting it either way. Would leave it to you :) - Hari ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[kexec-tools PATCH] build: fix tarball creation
The fix in 41b77edac did not work, bsdtar still complains about "hardlink pointing to itself". Simplify the code instead: since the staging directory contains exactly the files we want, just package it as a whole. Signed-off-by: Leah Neukirchen --- Makefile.in | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/Makefile.in b/Makefile.in index 09bbd5c..3cad22a 100644 --- a/Makefile.in +++ b/Makefile.in @@ -179,8 +179,6 @@ GENERATED_SRCS:= $(SPEC) TARBALL=$(PACKAGE_NAME)-$(PACKAGE_VERSION).tar TARBALL.gz=$(TARBALL).gz SRCS:= $(dist) -PSRCS:=$(foreach s, $(SRCS), $(PACKAGE_NAME)-$(PACKAGE_VERSION)/$(s)) -PGSRCS:=$(foreach s, $(GENERATED_SRCS), $(PACKAGE_NAME)-$(PACKAGE_VERSION)/$(s)) MAN_PAGES:=$(KEXEC_MANPAGE) $(VMCORE_DMESG_MANPAGE) BINARIES_i386:=$(KEXEC_TEST) @@ -223,8 +221,7 @@ $(TARBALL): $(SRCS) $(GENERATED_SRCS) $(MKDIR) $(PACKAGE_NAME)-$(PACKAGE_VERSION) $(TAR) -c $(SRCS) $(GENERATED_SRCS) | \ $(TAR) -C $(PACKAGE_NAME)-$(PACKAGE_VERSION) -x - $(TAR) -cf $@ $(PSRCS) - $(TAR) -rf $@ $(PGSRCS) + $(TAR) -cf $@ $(PACKAGE_NAME)-$(PACKAGE_VERSION) $(RM) -rf $(PACKAGE_NAME)-$(PACKAGE_VERSION) $(TARBALL.gz): $(TARBALL) -- 2.42.0 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 8/8] crash_core.c: remove unneeded functions
On 08/28/23 at 12:26am, Samuel Holland wrote:
> Hi Baoquan,
>
> On 2023-08-27 5:11 AM, Baoquan He wrote:
> > So far, nobody calls functions parse_crashkernel_high() and
> > parse_crashkernel_high(), remove both of them.
>
> minor typo: should be parse_crashkernel_low().
Good catch, will update. Thanks.
>
> > Signed-off-by: Baoquan He
> > ---
> > include/linux/crash_core.h | 4
> > kernel/crash_core.c| 18 --
> > 2 files changed, 22 deletions(-)
> >
> > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> > index 2f732493e922..0c512a80a768 100644
> > --- a/include/linux/crash_core.h
> > +++ b/include/linux/crash_core.h
> > @@ -80,10 +80,6 @@ void final_note(Elf_Word *buf);
> > int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> > unsigned long long *crash_size, unsigned long long *crash_base,
> > unsigned long long *low_size, bool *high);
> > -int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
> > - unsigned long long *crash_size, unsigned long long *crash_base);
> > -int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
> > - unsigned long long *crash_size, unsigned long long *crash_base);
> >
> > #ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> > #ifndef DEFAULT_CRASH_KERNEL_LOW_SIZE
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > index 6bc00cc390b5..61a8ea3b23a2 100644
> > --- a/kernel/crash_core.c
> > +++ b/kernel/crash_core.c
> > @@ -323,24 +323,6 @@ int __init parse_crashkernel(char *cmdline,
> > return 0;
> > }
> >
> > -int __init parse_crashkernel_high(char *cmdline,
> > -unsigned long long system_ram,
> > -unsigned long long *crash_size,
> > -unsigned long long *crash_base)
> > -{
> > - return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
> > - suffix_tbl[SUFFIX_HIGH]);
> > -}
> > -
> > -int __init parse_crashkernel_low(char *cmdline,
> > -unsigned long long system_ram,
> > -unsigned long long *crash_size,
> > -unsigned long long *crash_base)
> > -{
> > - return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
> > - suffix_tbl[SUFFIX_LOW]);
> > -}
> > -
> > /*
> > * Add a dummy early_param handler to mark crashkernel= as a known command
> > line
> > * parameter and suppress incorrect warnings in init/main.c.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: update manpage with explicit mention of clean kexec
On 08/28/23 at 09:48am, Simon Horman wrote: > On Mon, Aug 28, 2023 at 11:46:14AM +0530, Hari Bathini wrote: > > Any comments on this, please.. > > Hi Hari, > > Sorry, I had missed this. > > > On 07/07/23 10:59 am, Hari Bathini wrote: > > > While the manpage does mention about kexec boot with a clean shutdown, > > > it is not explicit about it. Make it explicit. > > > > > > Signed-off-by: Hari Bathini > > > --- > > > kexec/kexec.8 | 12 ++-- > > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > > > diff --git a/kexec/kexec.8 b/kexec/kexec.8 > > > index 3a344c5..87e4ab5 100644 > > > --- a/kexec/kexec.8 > > > +++ b/kexec/kexec.8 > > > @@ -95,8 +95,16 @@ then you would use the following command to load the > > > kernel: > > > .RB "\-\-append=" "root=/dev/hda1" "\ \-\-initrd=" /boot/initrd > > > .RE > > > .PP > > > -After this kernel is loaded, it can be booted to at any time using the > > > -command: > > > +After this kernel is loaded, assuming your Linux distribution supports > > > +kexec-based rebooting, it can be booted to, with a clean shutdown, using > > > +the command: > > Perhaps user-space would be better than "your Linux distribution". > But perhaps that is just kernel developer speak and makes less > sense to others. Agree, linux distrobution doesn't make sense here. And since this is a kexec man page, does it really need to make this change? We know kexec-tools loaded a kernel, we will use kexec-tools to trigger the reboot. Wondering why we need to stress distros or kernel or kexec-tools supports the kexec-based rebooting. 'with a clean shutdown' seems a little helpful though. > > > > + > > > +.RS > > > +.BR reboot > > > +.RE > > > +.PP > > > +Alternatively, it can also be booted to, without calling shutdown(8), > > > with > > > +the command: > > > > > > .RS > > > .BR kexec \ \-e > > > > ___ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.27
Hi all, I am happy to announce the release of kexec-tools 2.0.27. This is a feature release coinciding with the release of v6.5 of the Linux Kernel. This release can be downloaded from kernel.org: http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.27.tar.xz http://kernel.org/pub/linux/utils/kernel/kexec/ It is also tagged it in git: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec! Commits since v2.0.26: 17590eedff6d kexec-tools 2.0.27 777ca453ca69 kexec-tools 2.0.27-rc1 f67c4146d7b5 arm64: Hook up the ZBOOT support as vmlinuz fc7b83bdf734 arm64: Add ZBOOT PE containing compressed image support f41c4182b0c4 kexec/zboot: Add arch independent zboot support 1572b91da7c4 kexec: Introduce a member kernel_fd in kexec_info 714fa11590fe kexec/arm64: Simplify the code for zImage a8de94e5f033 LoongArch: kdump: Set up kernel image segment 4203eaccfa92 kexec: __NR_kexec_file_load is set to undefined on LoongArch 63e9a012112e ppc64: Add elf-ppc64 file types/options and an arch specific flag to man page 806711fca9e9 x86: add devicetree support 29fe5067ed07 kexec: make -a the default e63fefd4fc35 ppc64: add --reuse-cmdline parameter support 8fc55927f700 kexec-tools 2.0.26.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: update manpage with explicit mention of clean kexec
On Mon, Aug 28, 2023 at 11:46:14AM +0530, Hari Bathini wrote: > Any comments on this, please.. Hi Hari, Sorry, I had missed this. > On 07/07/23 10:59 am, Hari Bathini wrote: > > While the manpage does mention about kexec boot with a clean shutdown, > > it is not explicit about it. Make it explicit. > > > > Signed-off-by: Hari Bathini > > --- > > kexec/kexec.8 | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/kexec/kexec.8 b/kexec/kexec.8 > > index 3a344c5..87e4ab5 100644 > > --- a/kexec/kexec.8 > > +++ b/kexec/kexec.8 > > @@ -95,8 +95,16 @@ then you would use the following command to load the > > kernel: > > .RB "\-\-append=" "root=/dev/hda1" "\ \-\-initrd=" /boot/initrd > > .RE > > .PP > > -After this kernel is loaded, it can be booted to at any time using the > > -command: > > +After this kernel is loaded, assuming your Linux distribution supports > > +kexec-based rebooting, it can be booted to, with a clean shutdown, using > > +the command: Perhaps user-space would be better than "your Linux distribution". But perhaps that is just kernel developer speak and makes less sense to others. > > + > > +.RS > > +.BR reboot > > +.RE > > +.PP > > +Alternatively, it can also be booted to, without calling shutdown(8), with > > +the command: > > > > .RS > > .BR kexec \ \-e > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec: update manpage with explicit mention of clean kexec
Any comments on this, please.. On 07/07/23 10:59 am, Hari Bathini wrote: While the manpage does mention about kexec boot with a clean shutdown, it is not explicit about it. Make it explicit. Signed-off-by: Hari Bathini --- kexec/kexec.8 | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/kexec/kexec.8 b/kexec/kexec.8 index 3a344c5..87e4ab5 100644 --- a/kexec/kexec.8 +++ b/kexec/kexec.8 @@ -95,8 +95,16 @@ then you would use the following command to load the kernel: .RB "\-\-append=" "root=/dev/hda1" "\ \-\-initrd=" /boot/initrd .RE .PP -After this kernel is loaded, it can be booted to at any time using the -command: +After this kernel is loaded, assuming your Linux distribution supports +kexec-based rebooting, it can be booted to, with a clean shutdown, using +the command: + +.RS +.BR reboot +.RE +.PP +Alternatively, it can also be booted to, without calling shutdown(8), with +the command: .RS .BR kexec \ \-e ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
