On Tue, 1 Jul 2025 19:59:53 +1200
Tao Liu wrote:
> Hi Kazu,
>
> Thanks for your comments!
>
> On Tue, Jul 1, 2025 at 7:38 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
> >
> > Hi Tao,
> >
> > thank you for the patch.
> >
> > On 2025/06/25 11:23, Tao Liu wrote:
> > > A vmcore corrupt issue has been noti
On Fri, 16 Aug 2024 07:54:52 -0500
"Eric W. Biederman" wrote:
> Petr Tesarik writes:
>
> > From: Petr Tesarik
> >
> > Fix the condition to exclude the elfcorehdr segment from the SHA digest
> > calculation.
> >
> > The j iterator is an
On Tue, 6 Aug 2024 06:59:35 +0800
Baoquan He wrote:
> On 08/05/24 at 05:07pm, Petr Tesarik wrote:
> > From: Petr Tesarik
> >
> > Fix the condition to exclude the elfcorehdr segment from the SHA digest
> > calculation.
> >
> > The j iterator is an index i
Hi,
On Sat, 18 May 2024 09:33:04 +0100
Simon Horman wrote:
> On Sat, May 18, 2024 at 11:39:18AM +0800, Dave Young wrote:
> > On Wed, 11 Oct 2023 at 13:24, Song Shuai
> > wrote:
> > >
> > >
> > >
> > > 在 2023/9/20 19:56, Simon Horman 写道:
> > > > On Fri, Sep 15, 2023 at 11:50:06AM +0800, Son
> Therefore, update the relevant kernel documentation to reflect the same.
>
> No functional change.
>
> Cc: Petr Tesarik
> Cc: Hari Bathini
> Cc: kexec@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: x...@kernel.org
+Cc Eric DeVolder (current email address)
On Mon, 5 Aug 2024 17:07:50 +0200
Petr Tesarik wrote:
> From: Petr Tesarik
>
> Fix the condition to exclude the elfcorehdr segment from the SHA digest
> calculation.
>
> The j iterator is an index into the output sha_regions[] arr
From: Petr Tesarik
Fix the condition to exclude the elfcorehdr segment from the SHA digest
calculation.
The j iterator is an index into the output sha_regions[] array, not into
the input image->segment[] array. Once it reaches image->elfcorehdr_index,
all subsequent segments are ex
ts about the commit message. No strong
> >> opinion on changing the commit message.
> >>
> >> On 11/07/24 16:04, Petr Tesarik wrote:
> >>> From: Petr Tesarik
> >>>
> >>> There is no reason to restrict access to this attribute, as
From: Petr Tesarik
There is no reason to restrict access to this attribute, as it merely
reports whether crash elfcorehdr is automatically updated on CPU hot
plug/unplug and/or online/offline events.
Note that since commit 79365026f8694 ("crash: add a new kexec flag for
hotplug support&qu
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)
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-riscv64-kd
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
().
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
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 the
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
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:
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 with
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 the
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:
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
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
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
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
arios. 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
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
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.
> >
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
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
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
Cl
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
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 arch_kexec_locate_mem_hole(struc
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")
Sign
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
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
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-by
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 fa
.
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
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 kernel
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
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
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".
> &g
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)
> >
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
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
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
definite
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
V Thu, 24 May 2018 11:34:05 -0500
ebied...@xmission.com (Eric W. Biederman) napsáno:
> Petr Tesarik writes:
>
> 2> On Thu, 24 May 2018 09:49:05 +0800
> > Dave Young wrote:
> >
> >> Hi Petr,
> >>
> >> On 05/23/18 at 10:22pm, Petr Tesarik w
On Thu, 24 May 2018 15:26:27 +0800
Dave Young 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 was caused by growing
> > u
On Thu, 24 May 2018 09:49:05 +0800
Dave Young 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?
>
> I agreed with all t
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"
> >> > +depen
Original Message-
> > From: Petr Tesarik [mailto:ptesa...@suse.cz]
> > Sent: Tuesday, April 10, 2018 8:39 PM
> > To: lijiang
> > Cc: Tachibana Masaki() ; Nakayama Takuya()
> > ;
> > kexec-ml
> > Subject: [PATCH v2] makedumpfile: Use integer arithmetics
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 wrote:
> When page cache is filtered out (dump level bitmap includes 2 or 4),
> makedumpfile checks the PG_swapcache bit, but since kernel
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
---
makedumpfile.c | 19 ++-
makedumpf
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
---
makedumpfile.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index d685427
Hello,
I've just hit a nasty bug in makedumpfile when page cache is filtered
out (dump level bitmap includes 2 or 4). In short, makedumpfile checks
PG_swapcache, but since commit 6326fec1122cde256bd2a8c63f2606e08e44ce1d
this bit is an alias for PG_owner_priv_1. This bit is also used by
filesystem
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
---
print_inf
On Tue, 10 Apr 2018 09:47:07 +0200
Petr Tesarik 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
> eta_to_human_sho
On Tue, 10 Apr 2018 15:09:37 +0800
lijiang 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
> > ASCII characters, but
wrong 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
---
print_info.c | 23 +--
1 file changed,
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
---
kexec/kexec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kexec/kex
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: Michal Suchanek
> ---
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:
> > >
> > > > On 03/26/18 at 05:08pm, Dave Young wrote
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
---
makedumpfile.c | 5 +
makedumpfile.h | 9 -
2 files changed, 9 insertions(+), 5 deletions
Hi,
On Tue, 13 Mar 2018 09:18:54 +
Masaki Tachibana wrote:
> Hi Petr,
>
> Sorry for the late reply.
Never mind. I was on vacation, anyway. ;-)
> > -Original Message-
> > From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Petr
> &g
On Tue, 27 Feb 2018 09:15:10 +0800
Dave Young wrote:
> On 02/26/18 at 01:08pm, Michal Suchánek wrote:
> > On Mon, 26 Feb 2018 09:45:15 +0800
> > Dave Young wrote:
> >
> > > On 02/24/18 at 05:34pm, Petr Tesarik wrote:
> > > > On Sat, 24 Feb 201
On Sat, 24 Feb 2018 09:43:42 +0800
Dave Young wrote:
> On 02/23/18 at 09:29am, Petr Tesarik wrote:
> > Hi Baoquan,
> >
> > On Fri, 23 Feb 2018 07:20:43 +0800
> > Baoquan He wrote:
> >
> > > Hi Michal,
> > >
> > > On 0
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.
> >
> > However, some plat
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
---
makedumpfile.c | 5 +
makedumpfile.h | 1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff
On Tue, 23 Jan 2018 08:49:48 +
Atsushi Kumagai wrote:
> >On 01/19/18 at 12:45pm, Petr Tesarik wrote:
> >> I have observed that makedumpfile --mem-usage shows bogus numbers
> >> on a kaslr-enabled kernel. This boils down to incorrect calculations
> >> i
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",
> > > >log_lvl, 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:
> > > > printk("%sHardware name: %s\n",
> > > >log_lvl, dum
st out-of-range
address, i.e. start + size. Thanks to that, no +1 or -1 adjustments
are needed in exclude_segment().
Second, since the value read from /proc/iomem is the last address
within range, add one when passing it as an argument to
exclude_segment(). This is now the only adjustment by one.
Sign
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 in
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
---
elf_i
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 -
> >
> > Date: Tue, 23 Ma
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
---
arch/ia64.c| 8 +---
arch/x86.c | 19 +--
arch/x86_
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.
>
> Definitely something like th
On Mon, 20 Mar 2017 10:17:42 +0800
Xunlei Pang wrote:
> On 03/19/2017 at 02:23 AM, Petr Tesarik wrote:
> > 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, Xun
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 vmcore size estimat
On Fri, 10 Feb 2017 10:14:02 +0200
Denys Fedoryshchenko wrote:
> Hello,
>
> After years of using kexec and recent unpleasant experience with modern
> (supposed to be blazing fast to boot) hardware that need 5-10 minutes
> just to pass POST tests,
> one question came up to me:
> Is it possible
e adjacent into a single LOAD
segment.
Signed-off-by: Petr Tesarik
---
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..f62b159 100644
--- a/
On Mon, 26 Sep 2016 15:19:50 -0500
Clif Houck wrote:
> Hi all,
>
> I was wondering if there's a known list of limitations of kexec?
>
> For example, is there anything fundamentally wrong with trying to kexec
> from kernel version X to kernel version Y where:
> 1) version Y > version X
> 2) X <
).
Changes from v1:
- Cleanup file descriptor usage in dwarf_info.c and sadump_info.c
Signed-off-by: Petr Tesarik
---
dwarf_info.c | 6 --
makedumpfile.c | 68 +-
makedumpfile.h | 2 +-
sadump_info.c | 3 ++-
4 files changed, 46
nsistent 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
>
> Good, thanks fo
).
Signed-off-by: Petr Tesarik
---
makedumpfile.c | 68 +-
makedumpfile.h | 2 +-
2 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 21784e8..d168dfd 100644
--- a/makedumpfile.c
+++ b
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
> >> > ---
> >> > makedumpfile.c |
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 +--
> 1 file changed, 1 insertion
On Fri, 15 Jul 2016 11:13:46 -0400
Vivek Goyal 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 wrote:
> >
> > > On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> > &g
On Fri, 15 Jul 2016 08:51:14 -0400
Vivek Goyal wrote:
> On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> > On Fri, 15 Jul 2016 07:57:22 +0800
> > joeyli wrote:
> >
> > > Hi Vivek
> > >
> > > On Thu, Jul 14, 2016 at 10:53:28AM
On Fri, 15 Jul 2016 18:28:05 +0800
joeyli wrote:
> On Fri, Jul 15, 2016 at 09:58:22AM +0200, Petr Tesarik wrote:
> > On Fri, 15 Jul 2016 07:57:22 +0800
> > joeyli wrote:
> >
> > > Hi Vivek
> > >
> > > On Thu, Jul 14, 2016 at 10:53:28AM -0400, Vi
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 to old kexec sys
On Wed, 13 Jul 2016 05:52:33 -0700
Josh Triplett 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_struct *p)
> > retu
On Wed, 13 Jul 2016 14:19:50 +0200
Petr Tesarik wrote:
> Hello all,
>
> this patch series makes it possible to save a kernel crash dump when the
> kernel command line includes "crash_kexec_post_notifiers".
Oh ... I forgot to add: This only applies to running Linux under X
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
---
arch/x86
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
dules separately to enable the use of PV
drivers with unmodified bare-metal kernels.
Signed-off-by: Petr Tesarik
---
include/linux/kexec.h |2 ++
kernel/kexec_core.c |6 ++
kernel/ksysfs.c |2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/
Linux 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
> > >> >> execution, but you have already mentioned the
> > >>
On Tue, 12 Jul 2016 16:22:07 -0500
ebied...@xmission.com (Eric W. Biederman) wrote:
> Petr Tesarik writes:
>
> > On Tue, 12 Jul 2016 13:25:11 -0300
> > Thiago Jung Bauermann wrote:
>[...]
> >> I also don't understand what you mean by code execution. How doe
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 (get_pt_load_extents(i, &phys_start, &phys_en
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. Biederman:
> > AKASHI Takahiro wri
1 - 100 of 320 matches
Mail list logo
