在 2019年08月09日 13:45, Dave Young 写道:
On 08/06/19 at 07:22pm, Lianbo Jiang wrote:
From: Jun Wang junw99@yahoo.com
With some corrupted vmcore files, the vmcore-dmesg.txt file may grow forever till the kdump disk becomes full, and also probably causes the disk error messages as follow: ... sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#6 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00 blk_update_request: I/O error, dev sda, sector 134630552 sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00 blk_update_request: I/O error, dev sda, sector 134630552 ...
Rethink about the problem, if the log_buf_len is not corrupted, it will be fine, in kernel code log_buf_len is a u32 int. so it will be not possible to fill disk forever unless vmcore-dmesg is buggy.
Also about the implementation, it looks not very elegant. Can you try to add some limitation in vmcore-dmesg.c?
Actually in upstream kernel there is a macro LOG_BUF_LEN_MAX which is defined as 2G, so limit the file output to within 2G should be fine.
I checked vmcore-dmesg.c, and made a draft patch limit the size of vmcore-dmesg.txt as follow:
diff --git a/util_lib/elf_info.c b/util_lib/elf_info.c index 90a3b21662e7..a66241d8d76a 100644 --- a/util_lib/elf_info.c +++ b/util_lib/elf_info.c @@ -54,6 +54,9 @@ static uint64_t phys_offset = UINT64_MAX; #error "Unknown machine endian" #endif
+/* stole this macro from kernel printk.c */ +#define LOG_BUF_LEN_MAX (uint32_t)(1 << 31) + static uint16_t file16_to_cpu(uint16_t val) { if (ehdr.e_ident[EI_DATA] != ELFDATANATIVE) @@ -534,6 +537,13 @@ static int32_t read_file_s32(int fd, uint64_t addr) static void write_to_stdout(char *buf, unsigned int nr) { ssize_t ret; + static uint32_t n_bytes = 0; + + n_bytes += nr; + if (n_bytes > LOG_BUF_LEN_MAX) { + fprintf(stderr, "The vmcore-dmesg.txt over 2G in size is not supported.\n"); + return; + }
ret = write(STDOUT_FILENO, buf, nr); if (ret != nr) {
What's your opinion?
Thanks. Lianbo
Lets limit the size of vmcore-dmesg.txt to avoid such problems.
Signed-off-by: Jun Wang junw99@yahoo.com Signed-off-by: Lianbo Jiang lijiang@redhat.com
Changes since v1: [1] Add dump_fs path to limit the size of vmcore-dmesg.txt [2] Add the option 'iflag=fullblock' for the dd command.
dracut-kdump.sh | 4 ++-- kdump-lib-initramfs.sh | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index 2ae1c7c5d70d..ddd96efb5184 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -102,8 +102,8 @@ save_vmcore_dmesg_ssh() { local _opts="$3" local _location=$4
- echo "kdump: saving vmcore-dmesg.txt"
- $_dmesg_collector /proc/vmcore | ssh $_opts $_location "dd of=$_path/vmcore-dmesg-incomplete.txt"
echo "kdump: saving vmcore-dmesg.txt, up to 100MB"
$_dmesg_collector /proc/vmcore | ssh $_opts $_location "dd of=$_path/vmcore-dmesg-incomplete.txt bs=512 count=204800 iflag=fullblock" _exitcode=$?
if [ $_exitcode -eq 0 ]; then
diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh index 608dc6efc07e..44f9ae4dfb8f 100755 --- a/kdump-lib-initramfs.sh +++ b/kdump-lib-initramfs.sh @@ -137,8 +137,8 @@ save_vmcore_dmesg_fs() { local _dmesg_collector=$1 local _path=$2
- echo "kdump: saving vmcore-dmesg.txt"
- $_dmesg_collector /proc/vmcore > ${_path}/vmcore-dmesg-incomplete.txt
- echo "kdump: saving vmcore-dmesg.txt, up to 100MB"
- $_dmesg_collector /proc/vmcore | dd of=$_path/vmcore-dmesg-incomplete.txt bs=512 count=204800 iflag=fullblock _exitcode=$? if [ $_exitcode -eq 0 ]; then mv ${_path}/vmcore-dmesg-incomplete.txt ${_path}/vmcore-dmesg.txt
-- 2.17.1
Thanks Dave