On Thu 30-11-23 11:00:48, Baoquan He wrote: [...] > Now, we are worried if there's risk if the CMA area is retaken into kdump > kernel as system RAM. E.g is it possible that 1st kernel's ongoing RDMA > or DMA will interfere with kdump kernel's normal memory accessing? > Because kdump kernel usually only reset and initialize the needed > device, e.g dump target. Those unneeded devices will be unshutdown and > let go. I do not really want to discount your concerns but I am bit confused why this matters so much. First of all, if there is a buggy RDMA driver which doesn't use the proper pinning API (which would migrate away from the CMA) then what is the worst case? We will get crash kernel corrupted potentially and fail to take a proper kernel crash, right? Is this worrisome? Yes. Is it a real roadblock? I do not think so. The problem seems theoretical to me and it is not CMA usage at fault here IMHO. It is the said theoretical driver that needs fixing anyway. Now, it is really fair to mention that CMA backed crash kernel memory has some limitations - CMA reservation can only be used by the userspace in the primary kernel. If the size is overshot this might have negative impact on kernel allocations - userspace memory dumping in the crash kernel is fundamentally incomplete. Just my 2c -- Michal Hocko SUSE Labs _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
