On Mon, 8 Jan 2024 21:06:47 +0800 fuqiang wang <fuqiang.w...@easystack.cn> wrote:
> In memmap_exclude_ranges(), elfheader will be excluded from crashk_res. > In the current x86 architecture code, the elfheader is always allocated > at crashk_res.start. It seems that there won't be a new split range. > But it depends on the allocation position of elfheader in crashk_res. To > avoid potential out of bounds in future, add a extra slot. > > The similar issue also exists in fill_up_crash_elf_data(). The range to > be excluded is [0, 1M], start (0) is special and will not appear in the > middle of existing cmem->ranges[]. But in cast the low 1M could be > changed in the future, add a extra slot too. > > Previously discussed link: > [1] https://lore.kernel.org/kexec/ZXk2oBf%2FT1Ul6o0c@MiWiFi-R3L-srv/ > [2] > https://lore.kernel.org/kexec/273284e8-7680-4f5f-8065-c5d780987...@easystack.cn/ > [3] https://lore.kernel.org/kexec/ZYQ6O%2F57sHAPxTHm@MiWiFi-R3L-srv/ So. When I merge this ancient fix against mainline, it goes OK. When I merge Coiby's "x86/crash: pass dm crypt keys to kdump kernel" on top of this fix, things do not go OK. Here is what I did: int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params) { unsigned int nr_ranges = 0; int i, ret = 0; unsigned long flags; struct e820_entry ei; struct crash_memmap_data cmd; struct crash_mem *cmem; /* * Using random kexec_buf for passing dm crypt keys may cause a range * split. So use two slots here. */ nr_ranges = 2; /* * In the current x86 architecture code, the elfheader is always * allocated at crashk_res.start. But it depends on the allocation * position of elfheader in crashk_res. To avoid potential out of * bounds in future, add a extra slot. */ cmem = vzalloc(struct_size(cmem, ranges, nr_ranges)); if (!cmem) return -ENOMEM; cmem->max_nr_ranges = nr_ranges; cmem->nr_ranges = 0; memset(&cmd, 0, sizeof(struct crash_memmap_data)); Please triple check this, I changed a few things.
