On 10/22/25 23:20, Vasileios Almpanis wrote:
When handling multiple concurrent dm-ploop requests, large bio_vec arrays can be allocated during request processing. These allocations are currently done with kmalloc_array(GFP_ATOMIC), which can fail under memory pressure for higher orders (order >= 6, ~256KB). Such failures result in partial or corrupted I/O, leading to EXT4 directory checksum errors and read-only remounts under heavy parallel workloads.
I don't fully like this approach. According to the commit message, the allocation error path leads to corruption. And instead of fixing the corruption on this error path we try to workaround it by eliminating this error path through delaying the allocation.
What if ploop_split_pio_to_list will fail (another error path in the same stack) will it lead to the corruption again?
In ideal world the error should be reported to the "user" (ext4) the way it understands exactly what data to expect on disk. Now we see that ext4 reports invalid checksums, that means AFAIU that errors were not reported to it correctly.
What I'm trying to say is that, maybe, making the allocation work is only a part of the solution, but not the whole solution.
-- Best regards, Pavel Tikhomirov Senior Software Developer, Virtuozzo. _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
