On Tue, 2026-07-21 at 02:27 -0400, Benjamin Marzinski wrote:
> After commit 03071031 ("kpartx: fix crash and truncated device creation
> with long -p delimiter"), when attempting to remove deleted partitions
> on kpartx -u, kpartx started calling dm_find_part() to check if the
> partition existed before checking if the slice size was 0 (and thus
> should get removed).You're right. My patch changed the order of checks in the DELETE loop, causing dm_find_part() to be called even when slices[j].size is non-zero (meaning the partition is still valid and should not be removed). > The problem is that if dm_find_part() returns DFP_DEVICE_RELOAD > because the partition device exists, part_uuid gets allocated, and > if the slices[j].size is non-zero and the partition device shouldn't > be removed, part_uuid wasn't getting freed. Fix this by reverting > to checking the slice size first. I see the memory leak now. When slices[j].size != 0 and dm_find_part() returns DFP_DEVICE_RELOAD, we hit the "continue" without freeing part_uuid. Reverting to checking slice size first is the correct fix - it restores the original optimization of only calling dm_find_part() for partitions that actually need to be removed. Reviewed-by: Kou Wenqi <[email protected]> Thank you for catching this!
