On Thu, Oct 22, 2026 at 09:44:57PM +0000, Eric Biggers wrote:
> On Thu, Oct 22, 2026 at 03:24:18PM +0200, Mikulas Patocka wrote:
> > > async_tx adds significant complexity and maintenance overhead while
> > > providing little practical benefit on modern systems, where RAID parity
> > > computation is typically performed more efficiently by CPU-based XOR/PQ
> > > implementations than by DMA engine offload.
>
> This patch is to dm-integrity, which is doing an XOR, but not for a RAID
> parity computation. The above paragraph should be adjusted.
>
> > > ---
> > > drivers/md/dm-integrity.c | 26 ++++++++++++++------------
> > > 1 file changed, 14 insertions(+), 12 deletions(-)
>
> Should also drop the 'select ASYNC_XOR' from CONFIG_DM_INTEGRITY.
>
> > > + src0 = kmap_local_page(source_pl[pl_index].page);
> > > + src1 = kmap_local_page(ic->journal_xor[pl_index].page);
> > > + dst = kmap_local_page(target_pl[pl_index].page);
> > > +
> > > + memcpy(dst + pl_offset, src0 + pl_offset, this_step);
> > > + crypto_xor(dst + pl_offset, src1 + pl_offset, this_step);
>
> crypto_xor_cpy(), instead of memcpy() + crypto_xor().
>
> Also, these pages come from dm_integrity_alloc_page_list() which
> allocates them in lowmem, and elsewhere in the file they are accessed
> using lowmem_page_address(). So the kmap_local is not necessary.
>
> Also note that crypto_xor() and crypto_xor_cpy() just use scalar
> instructions. Probably fine (it's just an XOR after all), but it might
> be worthwhile to mention why xor_gen() isn't used instead. Is it
> because the pointers and lengths aren't aligned well enough for that?
> Or just because not enough data is being processed here to bother?
There's also a stale comment:
/* mirror async_tx per-page completion accounting */
complete_journal_op(comp);
- Eric
