On 04/13/22 at 09:24am, Omar Sandoval wrote: > On Fri, Apr 08, 2022 at 11:02:47AM +0800, Baoquan He wrote: ...... > > Since redhat mail server has issue, the body content of patch is empty > > from my mail client. So reply here to add comment. > > > > As replied in v1 to Omar, I think this is a great fix. That would be > > also great to state if this is a real issue which is breaking thing, > > then add 'Fixes' tag and Cc stable like "Cc: <stable@xxxxxxxxxxxxxxx> # 5.17", > > or a fantastic improvement from code inspecting. > > > > Concern this because in distros, e.g in our rhel8, we maintain old kernel > > and back port necessary patches into the kernel, those patches with > > 'Fixes' tag definitely are good candidate. This is important too to LTS > > kernel. > > > > Thanks > > Baoquan > > Hi, Baoquan, > > Sorry I missed your replies. I'll answer your questions from your first > email. > > > I am wondering if this is a real issue you met, or you just found it > > by code inspecting > > I hit this issue with the test suite for drgn > (https://github.com/osandov/drgn). We run the test cases in a virtual > machine on various kernel versions > (https://github.com/osandov/drgn/tree/main/vmtest). Part of the test > suite crashes the kernel to run some tests against /proc/vmcore > (https://github.com/osandov/drgn/blob/13144eda119790cdbc11f360c15a04efdf81ae9a/setup.py#L213, > https://github.com/osandov/drgn/blob/main/vmtest/enter_kdump.py, > https://github.com/osandov/drgn/tree/main/tests/linux_kernel/vmcore). > When I tried v5.18-rc1 configured with !SMP and !PREEMPT, that part of > the test suite got stuck, which is how I found this issue. > > > I am wondering how your vmcore dumping is handled. Asking this because > > we usually use makedumpfile utility > > In production at Facebook, we don't run drgn directly against > /proc/vmcore. We use makedumpfile and inspect the captured file with > drgn once we reboot. > > > While using makedumpfile, we use mmap which is 4M at one time by > > default, then process the content. So the copy_oldmem_page() may only > > be called during elfcorehdr and notes reading. > > We also use vmcore-dmesg > (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/vmcore-dmesg) > on /proc/vmcore before calling makedumpfile. From what I can tell, that > uses read()/pread() > (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/util_lib/elf_info.c), > so it would also hit this issue. Thanks for these details and great patch. It's clear to me now about the situation and motivation. We also use vmcore-dmesg to collect dmesg log before running makedumpfile. That could be a small probability event, but worth adding Fixes just in case. > > I'll send a v3 adding Fixes: 690467c81b1a ("mm/vmalloc: Move draining > areas out of caller context"). I don't think a stable tag is necessary > since this was introduced in v5.18-rc1 and hasn't been backported as far > as I can tell. > > Thanks, > Omar >
