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

On Mon, Apr 09, 2018 at 02:14:09PM +0530, Bhupesh Sharma wrote: > On 04/05/2018 05:09 PM, Petr Tesarik wrote: > > Do not fall through to "--mem-min" when "-p" option is parsed. The > > break statement was apparently removed by mistake... > > > > Fixes: cb434cbe6f401037e448276bb12056d1fdc3dbfc > >

[ANNOUNCE] kexec-tools 2.0.17-rc1

Hi all, I am happy to announce the release of kexec-tools 2.0.17-rc1. This is an incremental feature pre-release. So long as no serious problems arise I intend to release kexec-tools 2.0.17 in a weeks time. Testing of 2.0.17-rc1 would be greatly appreciated. I do not have any outstanding

Re: [RESEND PATCH] arm64: fix an issue with kaslr-enabled vmlinux

On Fri, Apr 06, 2018 at 11:45:28AM +0900, AKASHI Takahiro wrote: > Normally vmlinux for arm64 is of ET_EXEC type, while if built with > CONFIG_RANDAMIZE_BASE (that is KASLR), it will be of ET_DYN type. > Meanwhile, physical address field of segments in vmlinux has actually > the same value as

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

Essentially, the estimated remaining time is calculated as: elapsed * (100 - progress) / progress Since the calculation is done with floating point numbers, it had masked a division by zero (if progress is 0), producing a NaN or infinity. The following conversion to int produces INT_MIN with

[PATCH 4.15 098/168] x86/gart: Exclude GART aperture from vmcore

4.15-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Bohac [ Upstream commit 2a3e83c6f96c513f43ce5a8c9034608ea584a255 ] On machines where the GART aperture is mapped over physical RAM /proc/vmcore contains the remapped

[PATCH 4.14 074/138] x86/gart: Exclude GART aperture from vmcore

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Bohac [ Upstream commit 2a3e83c6f96c513f43ce5a8c9034608ea584a255 ] On machines where the GART aperture is mapped over physical RAM /proc/vmcore contains the remapped

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

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 >

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

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 that's not

Re: [PATCH v2 00/11] kexec_file: Clean up purgatory load

On 03/23/18 at 10:41am, Philipp Rudo wrote: > Hi Andrew, > Hi Dave, > > i checked out linux-next with the patches and it looks good to me. Also made a > quick test and everything works fine. Thank you! Not sure if it is late about an ack :) Anyway, for the series: Acked-by: Dave Young

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

在 2018年04月09日 17:40, Petr Tesarik 写道: > Essentially, the estimated remaining time is calculated as: > > elapsed * (100 - progress) / progress > > However, print_progress() is also called when progress is 0. The > result of a floating point division by zero is either NaN (if > elapsed is zero),