在 2019年08月09日 13:45, Dave Young 写道:
On 08/06/19 at 07:22pm, Lianbo Jiang wrote:
> From: Jun Wang <junw99(a)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(a)yahoo.com>
>> Signed-off-by: Lianbo Jiang <lijiang(a)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
>