Re: [PATCH v2 2/3] riscv/purgatory: do not link with string.o and its dependencies

On 8/3/2023 5:13 PM, Palmer Dabbelt wrote: > On Wed, 26 Jul 2023 09:33:49 PDT (-0700), Conor Dooley wrote: >> On Wed, Jul 26, 2023 at 11:54:00AM +0200, Petr Tesarik wrote: >>> From: Petr Tesarik >>> >>> Linking with this object file makes kexec_file_load(2)

Re: [PATCH v2 0/3] RISC-V: Fix a few kexec_file_load(2) failures

Hi, On 7/26/2023 11:53 AM, Petr Tesarik wrote: > From: Petr Tesarik > > The kexec_file_load(2) syscall does not work at least in some kernel > builds. For details see the relevant section in this blog post: > > https://sigillatum.tesarici.cz/2023-07-21-state-of-

Re: [PATCH v2 3/3] riscv/kexec: load initrd high in available memory

On 7/26/2023 6:38 PM, Conor Dooley wrote: > On Wed, Jul 26, 2023 at 11:54:01AM +0200, Petr Tesarik wrote: >> From: Torsten Duwe >> >> When initrd is loaded low, the secondary kernel fails like this: >> >> INITRD: 0xdc581000+0x00eef000 overlaps in-use memory regi

[PATCH v2 3/3] riscv/kexec: load initrd high in available memory

(). It is technically possible to align the initrd load address accordingly, leaving a hole between the end of kernel and the initrd, but it is much simpler to allocate the initrd top-down. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Torsten Duwe Signed-of

[PATCH v2 0/3] RISC-V: Fix a few kexec_file_load(2) failures

From: Petr Tesarik The kexec_file_load(2) syscall does not work at least in some kernel builds. For details see the relevant section in this blog post: https://sigillatum.tesarici.cz/2023-07-21-state-of-riscv64-kdump.html This patch series handles an additional relocation types, removes

[PATCH v2 2/3] riscv/purgatory: do not link with string.o and its dependencies

From: Petr Tesarik Linking with this object file makes kexec_file_load(2) fail because of multiple unknown relocation types: - R_RISCV_ADD16, R_RISCV_SUB16: used by alternatives in strcmp() - R_RISCV_GOT_HI20: used to resolve _ctype in strcasecmp() All this hassle is needed for one single call

[PATCH v2 1/3] riscv/kexec: handle R_RISCV_CALL_PLT relocation type

age: Error loading purgatory ret=-8 The binary code at the call site remains the same, so tell arch_kexec_apply_relocations_add() to handle _PLT alike. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Torsten Duwe Signed-off-by: Petr Tesarik Cc:

[PATCH v1 2/3] riscv/kexec: handle R_RISCV_ADD16 and R_RISCV_SUB16 relocation types

From: Petr Tesarik 16-bit add and subtract relocation types are used by the purgatory code when the kernel is built with CONFIG_RISCV_ALTERNATIVES. If they are not handled, kexec_file_load(2) fails with: Unknown rela relocation: 34 kexec_image: Error loading purgatory ret=-8 or later

[PATCH v1 0/3] RISC-V: Fix a few kexec_file_load(2) failures

From: Petr Tesarik The kexec_file_load(2) syscall does not work at least in some kernel builds. For details see the relevant section in this blog post: https://sigillatum.tesarici.cz/2023-07-21-state-of-riscv64-kdump.html This patch series handles additional relocation types and removes

[PATCH v1 1/3] riscv/kexec: handle R_RISCV_CALL_PLT relocation type

age: Error loading purgatory ret=-8 The binary code at the call site remains the same, so tell arch_kexec_apply_relocations_add() to handle _PLT alike. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Torsten Duwe Signed-off-by: Petr Tesarik Cc:

[PATCH v1 3/3] riscv/purgatory: do not link with string.o

From: Petr Tesarik Linking with this object file it makes kexec_file_load(2) fail with: kexec_image: Unknown rela relocation: 20 kexec_image: Error loading purgatory ret=-8 This is R_RISCV_GOT_HI20, generated by the linker to handle references to the global variable _ctype from strcasecmp

[PATCH v1 2/2] eppic: Fix a warning about redefining ERRMSG

The macro is redefined on purpose, so let's #undef it first to silence the warning. Signed-off-by: Petr Tesarik --- extension_eppic.h | 1 + 1 file changed, 1 insertion(+) diff --git a/extension_eppic.h b/extension_eppic.h index 24189ba..08f1db0 100644 --- a/extension_eppic.h +++ b

[PATCH v1 0/2] makedumpfile: Fix a couple of warnings

Although none of the warnings is a real issue, they clutter the build output, making it easier to overlook another, real issue. Petr Tesarik (2): eppic: Fix incompatible pointer type warnings eppic: Fix a warning about redefining ERRMSG extension_eppic.c | 4 ++-- extension_eppic.h | 1 + 2

[PATCH v1 1/2] eppic: Fix incompatible pointer type warnings

From: Petr Tesarik On Linux, eppic defines ull (a bit confusingly) as uint64_t. This is an unsigned long on 64-bit platforms with both GCC and LLVM, and the compiler complains about passing a pointer to an unsigned long where a pointer to an unsigned long long is expected. It is not a real bug

Re: [PATCH] kexec-tools: print error if kexec_file_load fails

scenarios. But printing error message for other failure scenarios was inadvertently dropped. Restore printing error message for such cases. Indeed, my commit removed the error messages on failure. Fixes: 4f77da634035 ("kexec-tools: Fix kexec_file_load(2) error handling") Cc: Petr Tesarik Repo

[PATCH] kexec-tools: Remove duplicate definition of ramdisk

The ramdisk variable is defined in kexec/arch/ppc/kexec-ppc.c. This other definition is not needed and breaks build with -fno-common. Signed-off-by: Petr Tesarik --- kexec/arch/ppc/kexec-elf-ppc.c |1 - 1 file changed, 1 deletion(-) --- a/kexec/arch/ppc/kexec-elf-ppc.c +++ b/kexec/arch/ppc

Re: [PATCH 3/3] Cleanup: Remove offset_pt_load_memory

On Thu, 15 Oct 2020 03:07:59 + HAGIO KAZUHITO(萩尾　一仁) wrote: > -Original Message- > > > -Original Message- > > > After the previous commit, this variable has become write-only, so > > > it is clearly no longer needed. > >

[PATCH 2/3] Cleanup: Remove unused elf_info.c functions

These functions are unused and can be removed: - page_head_to_phys_start - page_head_to_phys_end - offset_to_pt_load_start - get_offset_pt_load_memory Signed-off-by: Petr Tesarik --- elf_info.c | 66 -- elf_info.h | 4 2 files changed

[PATCH 3/3] Cleanup: Remove offset_pt_load_memory

After the previous commit, this variable has become write-only, so it is clearly no longer needed. Signed-off-by: Petr Tesarik --- elf_info.c | 17 - 1 file changed, 17 deletions(-) diff --git a/elf_info.c b/elf_info.c index 5ed65fc..a6624b5 100644 --- a/elf_info.c +++ b

[PATCH 0/3] makedumpfile: Clean up unused code

I have noticed that some code in makedumpfile is either unused, or not really needed for correct operation. I suggest to remove that code, so other people don't have to waste time wondering why it is there. Petr Tesarik (3): Cleanup: Remove a superfluous seek to physical address 0 Cleanup

[PATCH 1/3] Cleanup: Remove a superfluous seek to physical address 0

The file position is updated for each page in readmem() via a read_pfn(). There is no point in seeking to PFN 0 data first. Signed-off-by: Petr Tesarik --- makedumpfile.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/makedumpfile.c b/makedumpfile.c index 4c4251e..cdde040

Re: [PATCH 01/11] kexec_file: allow archs to handle special regions while locating memory hole

Hi Hari, is there any good reason to add two more functions with a very similar name to an existing function? AFAICS all you need is a way to call a PPC64-specific function from within kexec_add_buffer (PATCH 4/11), so you could add something like this: int __weak

[PATCH] kexec-tools: s390: Reset kernel command line on syscall fallback

The command line is duplicated on s390 if kexec_file_load(2) is not implemented. That's because the corresponding variable is not reset to an empty string before re-parsing the kexec command line. Fixes: 9cf721279f6c ("Reset getopt before falling back to legacy syscall") Signed-of

[v2 0/2] Fix --kexec-syscall-auto on s390x

From: Petr Tesarik As noticed by Raymund Will, kexec -la does not work on kernels without the kexec_file_load(2) syscall, revealing some shortcomings in the automatic syscall selection. Petr Tesarik (2): kexec-tools: Fix kexec_file_load(2) error handling kexec-tools: Reset getopt before

[v2 1/2] kexec-tools: Fix kexec_file_load(2) error handling

From: Petr Tesarik The handling of kexec_file_load() error conditions needs some improvement. First, on failure, the system call itself returns -1 and sets errno. It is wrong to check the return value itself. Second, do_kexec_file_load() mixes different types of error codes (-1, return value

[v2 2/2] kexec-tools: Reset getopt before falling back to legacy syscall

From: Petr Tesarik The modules may need to parse the arguments again after kexec_file_load(2) failed, but getopt is not reset. This change fixes the --initrd option on s390x. Without this patch, it will fail to load the initrd on kernels that do not implement kexec_file_load(2). Signed-off

Re: [PATCH] kexec-tools: Fix kexec_file_load(2) error handling

Hold on, a follow-up patch is needed to fix --kexec-syscall-auto on s390x. I'm going to resend as a two-patch series. Petr T On Thu, 12 Mar 2020 21:17:40 +0100 Petr Tesarik wrote: > The handling of kexec_file_load() error conditions needs some > improvement. > > First, on failure

[PATCH] kexec-tools: Fix kexec_file_load(2) error handling

, or not. Move the error message towards the end of main(). Signed-off-by: Petr Tesarik --- kexec/kexec.c | 114 ++ kexec/kexec.h | 1 + 2 files changed, 61 insertions(+), 54 deletions(-) diff --git a/kexec/kexec.c b/kexec/kexec.c index bc6ab3d

Re: [PATCH] kdump, vmcoreinfo: Export sme_me_mask value to vmcoreinfo

On Fri, 26 Oct 2018 20:32:11 +0800 lijiang wrote: >[...] > For AMD machine with the SME feature, the msr 'MSR_K8_SYSCFG' can examine > whether SME is enabled in kernel, but the kexec is also userspace tool, > it has no permission to access the msr. But we need the MSR value from the panic

[PATCH 2/2] makedumpfile: Check if clock_gettime() requires -lrt

For glibc versions before 2.17, clock_gettime() was contained in a separate library and required linking with -lrt. Signed-off-by: Petr Tesarik --- Makefile | 12 1 file changed, 12 insertions(+) diff --git a/Makefile b/Makefile index e870b13..9c24387 100644 --- a/Makefile +++ b

[PATCH 1/2] makedumpfile: Use monotonic clock to calculate ETA and stats

Execution time should be always measured by a monotonic clock, because the system clock may be affected by discontinuous jumps, e.g. when time is set manually by an admin. Signed-off-by: Petr Tesarik --- makedumpfile.c | 84

Re: [PATCH] makedumpfile: Do not print ETA value if current progress is 0

Hi Lianbo, On Wed, 20 Jun 2018 11:07:46 +0800 lijiang wrote: > 在 2018年04月10日 15:47, Petr Tesarik 写道: >[...] > > Yes, the current code will not produce sensible results if the system > > clock moves backwards. With my patch it will most likely say: ">2day". >

Re: panic kexec broken on ARM64?

On Wed, 6 Jun 2018 10:00:24 +0200 Petr Tesarik wrote: > On Wed, 6 Jun 2018 09:02:04 +0200 > Stefan Wahren wrote: > > > Hi Petr, > > > > Am 05.06.2018 um 19:46 schrieb James Morse: > > > Hi Petr, > > > > > > (CC: +Akashi, Marc) > >

Re: panic kexec broken on ARM64?

On Wed, 6 Jun 2018 09:02:04 +0200 Stefan Wahren wrote: > Hi Petr, > > Am 05.06.2018 um 19:46 schrieb James Morse: > > Hi Petr, > > > > (CC: +Akashi, Marc) > > > > On 05/06/18 09:01, Petr Tesarik wrote: > >> I have observed hangs after crash on a

Re: panic kexec broken on ARM64?

On Wed, 6 Jun 2018 11:06:28 +0530 Bhupesh Sharma wrote: > Hello Petr, > > On Tue, Jun 5, 2018 at 1:31 PM, Petr Tesarik wrote: > > Hi all, > > > > I have observed hangs after crash on a Raspberry Pi 3 Model B+ board > > when a panic kernel is loaded. I attac

panic kexec broken on ARM64?

Hi all, I have observed hangs after crash on a Raspberry Pi 3 Model B+ board when a panic kernel is loaded. I attached a hardware debugger and found out that all CPU cores were stopped except one which was stuck in the idle thread. It seems that irq_set_irqchip_state() may sleep, which is

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

On Fri, 25 May 2018 15:00:13 -0500 ebied...@xmission.com (Eric W. Biederman) wrote: >[...] > The ultimate point is that the absolute best we can do is to run a > kernel in memory that we never use for anything else and then we have a > fighting chance of getting the system working and getting a

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

V Thu, 24 May 2018 11:34:05 -0500 ebied...@xmission.com (Eric W. Biederman) napsáno: > Petr Tesarik <ptesa...@suse.cz> writes: > > 2> On Thu, 24 May 2018 09:49:05 +0800 > > Dave Young <dyo...@redhat.com> wrote: > > > >> Hi Petr, > >

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

On Thu, 24 May 2018 15:26:27 +0800 Dave Young <dyo...@redhat.com> wrote: > On 05/24/18 at 08:57am, Petr Tesarik wrote: >[...] > > What is "a very minimal initrd"? Last time I had to make a significant > > adjustment to the estimation for openSUSE, this wa

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

On Thu, 24 May 2018 09:49:05 +0800 Dave Young <dyo...@redhat.com> wrote: > Hi Petr, > > On 05/23/18 at 10:22pm, Petr Tesarik wrote: >[...] > > In short, if one size fits none, what good is it to hardcode that "one > > size" into the kernel image? >

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

On Wed, 23 May 2018 10:53:55 -0500 ebied...@xmission.com (Eric W. Biederman) wrote: > Dave Young writes: > > > [snip] > > > >> > > >> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB > >> > +int "System memory size threshold for kdump memory default > >> > reserving" >

Re: [PATCH v2] makedumpfile: Use integer arithmetics for the progress bar

t; Thanks > Tachibana > > > > -Original Message- > > From: Petr Tesarik [mailto:ptesa...@suse.cz] > > Sent: Tuesday, April 10, 2018 8:39 PM > > To: lijiang <liji...@redhat.com> > > Cc: Tachibana Masaki() <mas-tachib...@vf.jp.nec.com>; Nakayama Takuya() &

Re: [PATCH 2/2] Check PG_swapbacked for swap cache pages

Hi Masaki-san, what is the status of this patch? Do you have any concerns? TIA, Petr T On Fri, 13 Apr 2018 18:29:59 +0200 Petr Tesarik <ptesa...@suse.cz> wrote: > When page cache is filtered out (dump level bitmap includes 2 or 4), > makedumpfile checks the PG_swapcache bit, but

[PATCH 2/2] Check PG_swapbacked for swap cache pages

and PG_swapbacked haven't changed since v4.10-rc1~7, so PG_swapbacked can fall back to PG_private + 6 if unknown. Without this patch, all Xen dumps are unusable, because PG_pinned is set for all page table pages. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- makedumpfile.

[PATCH 1/2] Add is_cache_page() helper to check if a page belongs to the cache

No functional change, but clarify the purpose of checking isLRU() and SwapCache(), and move the check to a single place. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- makedumpfile.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/makedumpfi

[PATCH v2] makedumpfile: Use integer arithmetics for the progress bar

was probably caused by the wrong assumption that integers < 100 can be interpreted with less than 3 ASCII characters, but that's not true for signed integers. To make eta_to_human_short() a bit safer, use an unsigned integer type. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- print_in

Re: [PATCH] makedumpfile: Do not print ETA value if current progress is 0

On Tue, 10 Apr 2018 09:47:07 +0200 Petr Tesarik <ptesa...@suse.cz> wrote: >[...] > Let's stay reasonable. Any value which represents more than a few > (dozen) hours is not usable in practice. But hey, to make sure we > cannot hit undefined behaviour, why not pass a double to &g

Re: [PATCH] makedumpfile: Do not print ETA value if current progress is 0

On Tue, 10 Apr 2018 15:09:37 +0800 lijiang <liji...@redhat.com> wrote: > 在 2018年04月09日 17:40, Petr Tesarik 写道: >[...] > > Last but not least, part of the issue was probably caused by the > > wrong assumption that integers < 100 can be interpreted with max 3 >

[PATCH] makedumpfile: Do not print ETA value if current progress is 0

assumption that integers < 100 can be interpreted with max 3 ASCII characters, but that's not true for signed integers. To make eta_to_human_short() a bit safer, use an unsigned integer type. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- print_info.c | 23 +-- 1 fil

[PATCH] Fix a segmentation fault when trying to run "kexec -p"

Do not fall through to "--mem-min" when "-p" option is parsed. The break statement was apparently removed by mistake... Fixes: cb434cbe6f401037e448276bb12056d1fdc3dbfc Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- kexec/kexec.c | 1 + 1 file changed, 1 insert

Re: [PATCH v6 3/5] kexec: Do not special-case the -s option

On Wed, 28 Mar 2018 15:15:16 +0200 Michal Suchanek wrote: > It is parsed separately to save a few CPU cycles when setting up other > options but it just complicates the code. So fold it back and set up all > flags for both KEXEC_LOAD and KEXEC_FILE_LOAD > > Signed-off-by:

Re: [PATCH v5 4/5] kexec: Add option to fall back to KEXEC_LOAD when KEXEC_FILE_LOAD is not supported

On Tue, 27 Mar 2018 13:01:29 +0200 Michal Suchánek wrote: > On Tue, 27 Mar 2018 18:06:19 +0800 > Dave Young wrote: > > > On 03/26/18 at 07:38pm, Michal Suchánek wrote: > > > On Mon, 26 Mar 2018 17:12:10 +0800 > > > Dave Young wrote: >

[makedumpfile PATCH v2] Always use bigger SECTION_MAP_MASK

4.13, removing some of the complexity. More importantly, makedumpfile fails on kernels which backport the patch on top of an older version (for example SLES15). Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- makedumpfile.c | 5 + makedumpfile.h | 9 - 2 files changed, 9 inse

Re: [makedumpfile PATCH] Always use bigger SECTION_MAP_MASK

ich is good in itself, because it reduces the maintenance burden going forward. A few years from now everybody will be too afraid of regressions to do such cleanup. The only downside is that in case B above, makedumpfile may silently produce incorrect ou

Re: [PATCH] kexec: do KEXEC_FILE_LOAD and fallback to KEXEC_LOAD if not supported.

On Tue, 27 Feb 2018 09:15:10 +0800 Dave Young <dyo...@redhat.com> wrote: > On 02/26/18 at 01:08pm, Michal Suchánek wrote: > > On Mon, 26 Feb 2018 09:45:15 +0800 > > Dave Young <dyo...@redhat.com> wrote: > > > > > On 02/24/18 at 05:34pm, Petr Tesarik

Re: [PATCH] kexec: do KEXEC_FILE_LOAD and fallback to KEXEC_LOAD if not supported.

On Sat, 24 Feb 2018 09:43:42 +0800 Dave Young <dyo...@redhat.com> wrote: > On 02/23/18 at 09:29am, Petr Tesarik wrote: > > Hi Baoquan, > > > > On Fri, 23 Feb 2018 07:20:43 +0800 > > Baoquan He <b...@redhat.com> wrote: > > > > > Hi Michal

Re: [PATCH] kexec: do KEXEC_FILE_LOAD and fallback to KEXEC_LOAD if not supported.

Hi Baoquan, On Fri, 23 Feb 2018 07:20:43 +0800 Baoquan He wrote: > Hi Michal, > > On 02/22/18 at 11:24pm, Michal Suchanek wrote: > > The new KEXEC_FILE_LOAD is preferred in the case the platform supports > > it because it allows kexec in locked down secure boot mode. > > > >

[makedumpfile PATCH] Always use bigger SECTION_MAP_MASK

4.13, removing some of the complexity. More importantly, makedumpfile fails on kernels which backport the patch on top of an older version (for example SLES15). Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- makedumpfile.c | 5 + makedumpfile.h | 1 - 2 files changed, 1 insertion

Re: [PATCH] print kdump kernel loaded status in stack dump

On Fri, 19 Jan 2018 08:16:04 -0800 Andi Kleen wrote: > On Fri, Jan 19, 2018 at 02:45:38PM +0900, Sergey Senozhatsky wrote: > > On (01/18/18 10:02), Andi Kleen wrote: > > > Dave Young writes: > > > > printk("%sHardware name: %s\n", > >

Re: [PATCH] print kdump kernel loaded status in stack dump

On Fri, 19 Jan 2018 12:47:19 +0800 Dave Young wrote: > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > On Thu, 18 Jan 2018 10:02:17 -0800 > > Andi Kleen wrote: > > > > > Dave Young writes: > > > >

[makedumpfile PATCH 0/2] Fix calculations in exclude_segment()

I have observed that makedumpfile --mem-usage shows bogus numbers on a kaslr-enabled kernel. This boils down to incorrect calculations in exclude_segment(). Consequently, data beyond a split LOAD segment are read from the wrong file offset. Petr Tesarik (2): Fix off-by-one errors

[makedumpfile PATCH 2/2] Fix physical-to-virtual conversion in exclude_segment()

With kaslr enabled, PAGE_OFFSET may no longer be aligned to allow calculation using bitwise OR. My fix follows the same idea as Baoquan's commit 4c53423b995463067fbbd394e724b4d1d6ea3d62 for set_kcore_vmcoreinfo, i.e. use arithmetic addition instead. Signed-off-by: Petr Tesarik <ptesa...@suse.

Re: makedumpfile PATCH] Fix the use of Xen physical and machine addresses

May I ask you to do the tests of this patch with our (Xen) dumpfiles? > > After that please drop the summary of the results here. If you have > > any questions drop me a line. > > > > Daniel > > > > - Forwarded message from Petr Tesarik <ptesa...@suse.cz> - &

[makedumpfile PATCH] Fix the use of Xen physical and machine addresses

converted using ptom_xen(), but this call is in fact merely moved from readmem(). This patch has been tested on a few bare metal and Xen dumps (x86_64 and x86). Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- arch/ia64.c| 8 +--- arch/x86.c | 19 +-- arc

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

On Mon, 20 Mar 2017 13:50:31 +0800 Xunlei Pang wrote: > As Eric said, > "what we need to do is move the variable vmcoreinfo_note out > of the kernel's .bss section. And modify the code to regenerate > and keep this information in something like the control page. > >

Re: [PATCH] kexec: Update vmcoreinfo after crash happened

On Mon, 20 Mar 2017 10:17:42 +0800 Xunlei Pang <xp...@redhat.com> wrote: > On 03/19/2017 at 02:23 AM, Petr Tesarik wrote: > > On Thu, 16 Mar 2017 21:40:58 +0800 > > Xunlei Pang <xp...@redhat.com> wrote: > > > >> On 03/16/2017 at 09:18 PM, Baoquan He w

Re: [PATCH] kexec: Update vmcoreinfo after crash happened

On Thu, 16 Mar 2017 21:40:58 +0800 Xunlei Pang wrote: > On 03/16/2017 at 09:18 PM, Baoquan He wrote: > > On 03/16/17 at 08:36pm, Xunlei Pang wrote: > >> On 03/16/2017 at 08:27 PM, Baoquan He wrote: > >>> Hi Xunlei, > >>> > >>> Did you really see this ever happened? Because the

[PATCH] ppc64: Reduce number of ELF LOAD segments

e adjacent into a single LOAD segment. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- kexec/arch/ppc64/crashdump-ppc64.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/kexec/arch/ppc64/crashdump-ppc64.c b/kexec/arch/ppc64/crashdump-ppc64.c index b3c8928

Re: [PATCH v2] Cleanup: Use a negative number for uninitialized file descriptors

). Changes from v1: - Cleanup file descriptor usage in dwarf_info.c and sadump_info.c Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- dwarf_info.c | 6 -- makedumpfile.c | 68 +- makedumpfile.h | 2 +- sadump_info.c | 3

Re: [PATCH] Cleanup: Use a negative number for uninitialized file descriptors

o aid in debugging by using a consistent value > >for uninitialized file descriptors which is also regarded as invalid by > >the kernel. For example, attempts to close a negative FD will fail > >(unlike an attempt to close FD 0). > > > >Signed-off-by: Petr Tesarik <pte

[PATCH] Cleanup: Use a negative number for uninitialized file descriptors

). Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- makedumpfile.c | 68 +- makedumpfile.h | 2 +- 2 files changed, 40 insertions(+), 30 deletions(-) diff --git a/makedumpfile.c b/makedumpfile.c index 21784e8..d168dfd

Re: [PATCH 3/3] close_dump_bitmap: simplify logic

On Tue, 16 Aug 2016 00:37:09 + Atsushi Kumagai wrote: > >> > The boolean expression replicates the logic of open_dump_bitmap(). > >> > It's simpler and less error-prone to simply check if fd_bitmap is > >> > valid. > >> > > >> > Signed-off-by: Martin Wilck

Re: [PATCH 3/3] close_dump_bitmap: simplify logic

On Wed, 10 Aug 2016 14:56:58 +0200 Martin Wilck wrote: > The boolean expression replicates the logic of open_dump_bitmap(). > It's simpler and less error-prone to simply check if fd_bitmap is > valid. > > Signed-off-by: Martin Wilck > --- > makedumpfile.c | 3

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

On Fri, 15 Jul 2016 11:13:46 -0400 Vivek Goyal <vgo...@redhat.com> wrote: > On Fri, Jul 15, 2016 at 04:42:40PM +0200, Petr Tesarik wrote: > > On Fri, 15 Jul 2016 08:51:14 -0400 > > Vivek Goyal <vgo...@redhat.com> wrote: > > > > > On Fri, Jul 15, 20

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

On Fri, 15 Jul 2016 08:51:14 -0400 Vivek Goyal <vgo...@redhat.com> wrote: > On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote: > > On Fri, 15 Jul 2016 07:57:22 +0800 > > joeyli <j...@suse.com> wrote: > > > > > Hi Vivek > > > > >

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

On Fri, 15 Jul 2016 18:28:05 +0800 joeyli <j...@suse.com> wrote: > On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote: > > On Fri, 15 Jul 2016 07:57:22 +0800 > > joeyli <j...@suse.com> wrote: > > > > > Hi Vivek > > > > > >

Re: [PATCH] kexec: Add option to fallback to old kexec syscall when kexec file based syscall failed

On Fri, 15 Jul 2016 07:57:22 +0800 joeyli wrote: > Hi Vivek > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vivek Goyal wrote: > > On Thu, Jul 14, 2016 at 04:45:11PM +0800, Lee, Chun-Yi wrote: > > > This patch adds a new "--fallback-kexec" option to give a chance to > > > fallback

Re: [PATCH 1/2] Add a kexec_crash_loaded() function

On Wed, 13 Jul 2016 05:52:33 -0700 Josh Triplett <j...@joshtriplett.org> wrote: > On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote: > > --- a/kernel/kexec_core.c > > +++ b/kernel/kexec_core.c > > @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_

[PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

If a crash kernel is loaded, do not crash the running domain. This is needed if the kernel is loaded with crash_kexec_post_notifiers, because panic notifiers are run before __crash_kexec() in that case, and this Xen hook prevents its being called later. Signed-off-by: Petr Tesarik <pt

[PATCH 0/2] Allow crash dumps with crash_kexec_post_notifiers

rs are run or not: If you load a crash kernel with kexec, it will be used, otherwise the hypervisor facility is used (using a hypercall). Feedback welcome! Petr T --- Petr Tesarik (2): Add a kexec_crash_loaded() function Allow kdump with crash_kexec_post_notifiers arch/x86/xen/e

[PATCH 1/2] Add a kexec_crash_loaded() function

separately to enable the use of PV drivers with unmodified bare-metal kernels. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- include/linux/kexec.h |2 ++ kernel/kexec_core.c |6 ++ kernel/ksysfs.c |2 +- 3 files changed, 9 insertions(+), 1 deletion(-) diff

Re: [RFC 0/3] extend kexec_file_load system call

1PM +1000, Stewart Smith wrote: > > >> Russell King - ARM Linux <li...@armlinux.org.uk> writes: > > >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > > >> >> I'm not an expert on DTB, so I can't provide an example of code > > &

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, 12 Jul 2016 16:22:07 -0500 ebied...@xmission.com (Eric W. Biederman) wrote: > Petr Tesarik <ptesa...@suse.cz> writes: > > > On Tue, 12 Jul 2016 13:25:11 -0300 > > Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> wrote: >[...] > >> I a

Re: [PATCH 2/3] makedumpfile: Mark unstored ELF pages as filtered

On Tue, 7 Jun 2016 04:18:48 + Atsushi Kumagai wrote: > >>+static void > >>+exclude_nodata_pages(struct cycle *cycle) > >>+{ > >>+ int i; > >>+ unsigned long long phys_start, phys_end; > >>+ off_t file_size; > >>+ > >>+ i = 0; > >>+ while

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, 12 Jul 2016 13:25:11 -0300 Thiago Jung Bauermann wrote: > Hi Eric, > > I'm trying to understand your concerns leading to your nack. I hope you > don't mind expanding your thoughts on them a bit. > > Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W.

[PATCH] makedumpfile: Fix several issues with reading ELF pages

tests the final conditional after the loop. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- makedumpfile.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) --- a/makedumpfile.c +++ b/makedumpfile.c @@ -656,14 +656,15 @@ readpage_elf(unsigned long long paddr,

Re: [PATCH] makedumpfile: When reading partial ELF pages, check final pointer against buffer end

Hi again, On Mon, 29 Feb 2016 19:59:52 +0100 Petr Tesarik <ptesa...@suse.cz> wrote: > If the last part of a page is not present in the ELF file, it should > be replaced with zeroes. However, the check is incorrect. While this fix is correct, it seems there are a few more errors in

[PATCH] makedumpfile: When reading partial ELF pages, check final pointer against buffer end

If the last part of a page is not present in the ELF file, it should be replaced with zeroes. However, the check is incorrect. Signed-off-by: Petr Tesarik <ptesa...@suse.com> diff --git a/makedumpfile.c b/makedumpfile.c index 867b953..138ddec 100644 --- a/makedumpfile.c +++ b/makedump

Re: [PATCH 3/3] makedumpfile: Rewrite readpage_elf

Hi, I just found a silly typo in my patch, see below. On Wed, 10 Feb 2016 08:50:09 +0100 Petr Tesarik <ptesa...@suse.cz> wrote: > The current code in readpage_elf (and readpage_elf_parallel) is extremely > hard to follow. Additionally, it still does not cover all possible cases. &

Re: [PATCH] makedumpfile: readpage_elf: handle 0-pages not stored in the ELF file

On Tue, 2 Feb 2016 08:00:44 +0100 Ivan Delalande wrote: > On Tue, Feb 02, 2016 at 06:48:17AM +, Atsushi Kumagai wrote: > > >Anyway, are you going to take the patch by Ivan, or my patch (after I > > >remove exclude_nodata_pages)? > > > > Ivan's patch is necessary to follow

Re: [PATCH] makedumpfile: readpage_elf: handle 0-pages not stored in the ELF file

On Wed, 10 Feb 2016 04:21:18 +0100 Ivan Delalande <col...@arista.com> wrote: > Hi, > > On Tue, Feb 09, 2016 at 09:31:50AM +0100, Petr Tesarik wrote: >[...] > > just a short status update. I haven't forgotten this patch, but I've > > had some troubles reproduci

[PATCH 0/3] makedumpfile: Fix handling of ELF segments with p_memsz > p_filesz

be9b (reported on the mailing list). I was able to verify that --dump-dmesg works on a variety of weird ELF files that I created manually (and the output hasn't changed). In my opinion, this is enough to verify that the read routine works, but the final decision is up to you. Petr Tes

[PATCH 2/3] makedumpfile: Mark unstored ELF pages as filtered

ed that pages between p_filesz and p_memsz were filtered out. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- elf_info.c | 26 ++ elf_info.h |5 + makedumpfile.c | 32 3 files changed, 63 insertions(+) ---

[PATCH 3/3] makedumpfile: Rewrite readpage_elf

only part of a page is stored, a complete page must be provided to make this partial data accessible. Credits to Ivan Delalande <col...@arista.com> who first found the problem and wrote the original fix. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- elf_info.c | 2

[PATCH 1/3] makedumpfile: Keep segment memory size when re-filtering ELF dumps

page data, so it must be stored separately and checked when translating a physical address to a file offset. Signed-off-by: Petr Tesarik <ptesa...@suse.com> --- elf_info.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/elf_info.c +++ b/elf_info.c @@ -38,6

Regression in makedumpfile-1.5.9

operly, but I have no time now to research further. Is the above information sufficient, or do you need more info from me? Regards, Petr Tesarik ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] makedumpfile: readpage_elf: handle 0-pages not stored in the ELF file

led pages when converting an already-filtered ELF file to the compressed format; but they may be filtered again if bit 0 is set in the dump level, so Ivan's approach is cleaner, in fact. If you ever find a way to mark filtered out pages in an ELF file, then this behaviour can be improved later. A

Re: [PATCH] makedumpfile: readpage_elf: handle 0-pages not stored in the ELF file

Resent to the list. The list does not like attachments, it seems. Petr T On Wed, 27 Jan 2016 08:58:21 +0100 Petr Tesarik <ptesa...@suse.cz> wrote: > Hello Atsushi-san, > > On Wed, 27 Jan 2016 02:21:57 + > Atsushi Kumagai <ats-kuma...@wm.jp.nec.com>

Re: [PATCH v2] kexec: fix mmap return code handling

uld break too many assumptions in user space (for example gcc assumes that dereferencing a NULL pointer terminates a process). In short, this other fix is just as good as the previous one. Regards, Petr Tesarik > --- > Subject: [PATCH] kexec: fix mmap return code handling > &g

Re: [PATCH v3] Load crash kernel high on x86

Hello Simon, what's up with this patch? Do you plan to apply it, or is there still an issue? Regards, Petr Tesarik On Thu, 24 Sep 2015 08:48:52 +0200 Petr Tesarik <ptesa...@suse.com> wrote: > There may be more than one crash kernel regions on x86. Currently, > kexec-tools picks the

  1   2   3   >