* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 [not found] ` <CAOtvUMcudG3ySU+VeE7hfneDVWGLKFTnws-xjhq4hgFYSj0qOg@mail.gmail.com> @ 2022-03-07 10:48 ` Corentin Labbe 2022-03-07 11:14 ` Robin Murphy ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Corentin Labbe @ 2022-03-07 10:48 UTC (permalink / raw) To: Gilad Ben-Yossef, hch, m.szyprowski, robin.murphy Cc: Linux kernel mailing list, iommu, Herbert Xu, Linux Crypto Mailing List Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a écrit : > On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > > > On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > > > Hello > > > > > > I got: > > > [ 17.563793] ------------[ cut here ]------------ > > > [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > > The direction argument during unmap must match whatever direction > > you used during the original map call. > > > Yes, of course. I changed one but forgot the other. > > Corentin, could you be kind and check that this solves the original > problem and does not produce new warnings? > > diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > b/drivers/crypto/ccree/cc_buffer_mgr.c > index 11e0278c8631..31cfe014922e 100644 > --- a/drivers/crypto/ccree/cc_buffer_mgr.c > +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > void *ctx, > req_ctx->mlli_params.mlli_dma_addr); > } > > - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > - > if (src != dst) { > - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > + } else { > + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > } > } > > @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > *drvdata, void *ctx, > u32 dummy = 0; > int rc = 0; > u32 mapped_nents = 0; > + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > mlli_params->curr_pool = NULL; > @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > *drvdata, void *ctx, > } > > /* Map the src SGL */ > - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > if (rc) > goto cipher_exit; > @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > *drvdata, void *ctx, > } > } else { > /* Map the dst sg */ > - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > &dummy, &mapped_nents); > if (rc) > > Hello I still get the warning: [ 433.406230] ------------[ cut here ]------------ [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 [ 433.406434] Modules linked in: [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 433.406498] pc : add_dma_entry+0x1d0/0x288 [ 433.406510] lr : add_dma_entry+0x1d0/0x288 [ 433.406522] sp : ffff800015da3690 [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 [ 433.406833] Call trace: [ 433.406841] add_dma_entry+0x1d0/0x288 [ 433.406854] debug_dma_map_sg+0x150/0x398 [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 [ 433.406889] dma_map_sg_attrs+0x10/0x28 [ 433.406904] cc_map_sg+0x80/0x100 [ 433.406924] cc_map_cipher_request+0x178/0x3c8 [ 433.406939] cc_cipher_process+0x210/0xb58 [ 433.406953] cc_cipher_encrypt+0x2c/0x38 [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 [ 433.406986] skcipher_recvmsg+0x36c/0x420 [ 433.407003] ____sys_recvmsg+0x90/0x280 [ 433.407024] ___sys_recvmsg+0x88/0xd0 [ 433.407038] __sys_recvmsg+0x6c/0xd0 [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 [ 433.407061] invoke_syscall+0x44/0x100 [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 [ 433.407096] do_el0_svc+0x24/0x88 [ 433.407110] el0_svc+0x4c/0x100 [ 433.407131] el0t_64_sync_handler+0x90/0xb8 [ 433.407145] el0t_64_sync+0x170/0x174 [ 433.407160] irq event stamp: 5624 [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 [ 433.407241] ---[ end trace 0000000000000000 ]--- [ 433.407381] DMA-API: Mapped at: [ 433.407396] debug_dma_map_sg+0x16c/0x398 [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 [ 433.407436] dma_map_sg_attrs+0x10/0x28 [ 433.407455] cc_map_sg+0x80/0x100 [ 433.407475] cc_map_cipher_request+0x178/0x3c8 BUT I start to thing this is a bug in DMA-API debug. My sun8i-ss driver hit the same warning: [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported [ 142.458455] Modules linked in: ccm algif_aead xts cmac [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 [ 142.458581] Hardware name: Allwinner A83t board [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 [ 142.458627] show_stack from 0xf0abdd1c [ 142.458646] irq event stamp: 31747 [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 [ 142.458758] ---[ end trace 0000000000000000 ]--- [ 142.458771] DMA-API: Mapped at: Yes the mapped at is empty just after. And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. So I booted a kernel without any other user of DMA (no net,mmc,usb,media) And I added this debug: diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index f8ff598596b8..56b243d24bac 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -548,6 +548,31 @@ static void active_cacheline_remove(struct dma_debug_entry *entry) spin_unlock_irqrestore(&radix_lock, flags); } +static void minidump(void) { + int idx; + + for (idx = 0; idx < HASH_SIZE; idx++) { + struct hash_bucket *bucket = &dma_entry_hash[idx]; + struct dma_debug_entry *entry; + unsigned long flags; + + spin_lock_irqsave(&bucket->lock, flags); + list_for_each_entry(entry, &bucket->list, list) { + if (strcmp("dwmac-sun8i", dev_driver_string(entry->dev))) + pr_info( + "%s %s %s idx %d P=%llx N=%lx D=%llx L=%llx %s %s\n", + dev_name(entry->dev), + dev_driver_string(entry->dev), + type2name[entry->type], idx, + phys_addr(entry), entry->pfn, + entry->dev_addr, entry->size, + dir2name[entry->direction], + maperr2str[entry->map_err_type]); + } + spin_unlock_irqrestore(&bucket->lock, flags); + } +} + /* * Wrapper function for adding an entry to the hash. * This function takes care of locking itself. @@ -562,13 +587,18 @@ static void add_dma_entry(struct dma_debug_entry *entry, unsigned long attrs) hash_bucket_add(bucket, entry); put_hash_bucket(bucket, flags); + pr_info("%s start P=%llx N=%lx D=%llx L=%llx %s attrs=%x\n", __func__, phys_addr(entry), entry->pfn, entry->dev_addr, entry->size, dir2name[entry->direction], attrs); rc = active_cacheline_insert(entry); if (rc == -ENOMEM) { pr_err("cacheline tracking ENOMEM, dma-debug disabled\n"); global_disable = true; } else if (rc == -EEXIST && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) { + pr_info("%s P=%llx N=%lx D=%llx L=%llx %s attrs=%x\n", __func__, phys_addr(entry), entry->pfn, entry->dev_addr, entry->size, dir2name[entry->direction], attrs); err_printk(entry->dev, entry, "cacheline tracking EEXIST, overlapping mappings aren't supported\n"); + pr_info("==================== MINIDUMP ===================\n"); + minidump(); + pr_info("==================== MINIDUMP END ===================\n"); } } and some more trace: diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c index 5bb950182026..c7ba32f68e41 100644 --- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c +++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c @@ -253,6 +271,7 @@ static int sun8i_ss_cipher(struct skcipher_request *areq) rctx->t_src[i].addr = sg_dma_address(sg); todo = min(len, sg_dma_len(sg)); rctx->t_src[i].len = todo / 4; + dev_info(ss->dev, "SRC %d/%d/%d %lx len=%d bi=%d\n", i, nr_sgd, nsgd, sg_dma_address(sg), sg_dma_len(sg), areq->src == areq->dst); dev_dbg(ss->dev, "%s total=%u SGS(%d %u off=%d) todo=%u\n", __func__, areq->cryptlen, i, rctx->t_src[i].len, sg->offset, todo); len -= todo; @@ -275,6 +294,7 @@ static int sun8i_ss_cipher(struct skcipher_request *areq) rctx->t_dst[i].addr = sg_dma_address(sg); todo = min(len, sg_dma_len(sg)); rctx->t_dst[i].len = todo / 4; + dev_info(ss->dev, "DST %d/%d/%d %lx len=%d bi=%d\n", i, nr_sgd, nsgd, sg_dma_address(sg), sg_dma_len(sg), areq->src == areq->dst); dev_dbg(ss->dev, "%s total=%u SGD(%d %u off=%d) todo=%u\n", __func__, areq->cryptlen, i, rctx->t_dst[i].len, sg->offset, todo); len -= todo; diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c index d23258f76292..6cdee02967b0 100644 --- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c +++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c @@ -603,6 +603,7 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void *breq) err = -EINVAL; goto err_dma_result; } + dev_info(ss->dev, "RES: %lx\n", addr_res); addr_xpad = dma_map_single(ss->dev, tfmctx->opad, bs, DMA_TO_DEVICE); if (dma_mapping_error(ss->dev, addr_xpad)) { dev_err(ss->dev, "Fail to create DMA mapping of opad\n"); The boot log is viewable at http://kernel.montjoie.ovh/230073.log (seek ba79f210 to go to the interesting place). We can see that the address handled by add_dma_entry was never handled before and so cannot overlap anything. I have added DMA people to confirm/refute what I said. Regards _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 10:48 ` [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 Corentin Labbe @ 2022-03-07 11:14 ` Robin Murphy 2022-03-07 11:49 ` Corentin Labbe ` (2 more replies) 2022-03-07 12:24 ` Gilad Ben-Yossef 2022-03-07 13:43 ` Gilad Ben-Yossef 2 siblings, 3 replies; 21+ messages in thread From: Robin Murphy @ 2022-03-07 11:14 UTC (permalink / raw) To: Corentin Labbe, Gilad Ben-Yossef, hch, m.szyprowski Cc: Linux kernel mailing list, iommu, Herbert Xu, Linux Crypto Mailing List On 2022-03-07 10:48, Corentin Labbe wrote: > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: >>> >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: >>>> >>>> Hello >>>> >>>> I got: >>>> [ 17.563793] ------------[ cut here ]------------ >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] >>> >>> The direction argument during unmap must match whatever direction >>> you used during the original map call. >> >> >> Yes, of course. I changed one but forgot the other. >> >> Corentin, could you be kind and check that this solves the original >> problem and does not produce new warnings? >> >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c >> b/drivers/crypto/ccree/cc_buffer_mgr.c >> index 11e0278c8631..31cfe014922e 100644 >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, >> void *ctx, >> req_ctx->mlli_params.mlli_dma_addr); >> } >> >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); >> - >> if (src != dst) { >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); >> + } else { >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); >> } >> } >> >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata >> *drvdata, void *ctx, >> u32 dummy = 0; >> int rc = 0; >> u32 mapped_nents = 0; >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); >> >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; >> mlli_params->curr_pool = NULL; >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata >> *drvdata, void *ctx, >> } >> >> /* Map the src SGL */ >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); >> if (rc) >> goto cipher_exit; >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata >> *drvdata, void *ctx, >> } >> } else { >> /* Map the dst sg */ >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, >> &dummy, &mapped_nents); >> if (rc) >> >> > > Hello > > I still get the warning: > [ 433.406230] ------------[ cut here ]------------ > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > [ 433.406434] Modules linked in: > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > [ 433.406522] sp : ffff800015da3690 > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > [ 433.406833] Call trace: > [ 433.406841] add_dma_entry+0x1d0/0x288 > [ 433.406854] debug_dma_map_sg+0x150/0x398 > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > [ 433.406904] cc_map_sg+0x80/0x100 > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > [ 433.406939] cc_cipher_process+0x210/0xb58 > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > [ 433.407003] ____sys_recvmsg+0x90/0x280 > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > [ 433.407061] invoke_syscall+0x44/0x100 > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > [ 433.407096] do_el0_svc+0x24/0x88 > [ 433.407110] el0_svc+0x4c/0x100 > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > [ 433.407145] el0t_64_sync+0x170/0x174 > [ 433.407160] irq event stamp: 5624 > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > [ 433.407241] ---[ end trace 0000000000000000 ]--- > [ 433.407381] DMA-API: Mapped at: > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > [ 433.407455] cc_map_sg+0x80/0x100 > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > BUT I start to thing this is a bug in DMA-API debug. > > > My sun8i-ss driver hit the same warning: > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > [ 142.458581] Hardware name: Allwinner A83t board > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > [ 142.458627] show_stack from 0xf0abdd1c > [ 142.458646] irq event stamp: 31747 > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > [ 142.458758] ---[ end trace 0000000000000000 ]--- > [ 142.458771] DMA-API: Mapped at: > > Yes the mapped at is empty just after. > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. The "overlap" is in the sense of having more than one mapping within the same cacheline: [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc D=445dc010 L=10 DMA_TO_DEVICE attrs=0 [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 This actually illustrates exactly the reason why this is unsupportable. ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range ba79f200-ba79f23f to be written back over the top of data that the device has already started to write to memory. Hello data corruption. Separate DMA mappings should be from separate memory allocations, respecting ARCH_DMA_MINALIGN. Thanks, Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 11:14 ` Robin Murphy @ 2022-03-07 11:49 ` Corentin Labbe 2022-03-07 11:59 ` Gilad Ben-Yossef 2022-03-07 12:17 ` Gilad Ben-Yossef 2022-03-07 13:45 ` Corentin Labbe 2 siblings, 1 reply; 21+ messages in thread From: Corentin Labbe @ 2022-03-07 11:49 UTC (permalink / raw) To: Robin Murphy Cc: Herbert Xu, Linux kernel mailing list, Gilad Ben-Yossef, iommu, Linux Crypto Mailing List, hch Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > On 2022-03-07 10:48, Corentin Labbe wrote: > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > >>> > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > >>>> > >>>> Hello > >>>> > >>>> I got: > >>>> [ 17.563793] ------------[ cut here ]------------ > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > >>> > >>> The direction argument during unmap must match whatever direction > >>> you used during the original map call. > >> > >> > >> Yes, of course. I changed one but forgot the other. > >> > >> Corentin, could you be kind and check that this solves the original > >> problem and does not produce new warnings? > >> > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > >> index 11e0278c8631..31cfe014922e 100644 > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > >> void *ctx, > >> req_ctx->mlli_params.mlli_dma_addr); > >> } > >> > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> - > >> if (src != dst) { > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> + } else { > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> } > >> } > >> > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> u32 dummy = 0; > >> int rc = 0; > >> u32 mapped_nents = 0; > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > >> > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > >> mlli_params->curr_pool = NULL; > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> > >> /* Map the src SGL */ > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > >> if (rc) > >> goto cipher_exit; > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> } else { > >> /* Map the dst sg */ > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > >> &dummy, &mapped_nents); > >> if (rc) > >> > >> > > > > Hello > > > > I still get the warning: > > [ 433.406230] ------------[ cut here ]------------ > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > [ 433.406434] Modules linked in: > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > [ 433.406522] sp : ffff800015da3690 > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > [ 433.406833] Call trace: > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > [ 433.406904] cc_map_sg+0x80/0x100 > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > [ 433.407061] invoke_syscall+0x44/0x100 > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > [ 433.407096] do_el0_svc+0x24/0x88 > > [ 433.407110] el0_svc+0x4c/0x100 > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > [ 433.407145] el0t_64_sync+0x170/0x174 > > [ 433.407160] irq event stamp: 5624 > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > [ 433.407381] DMA-API: Mapped at: > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > [ 433.407455] cc_map_sg+0x80/0x100 > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > My sun8i-ss driver hit the same warning: > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > [ 142.458581] Hardware name: Allwinner A83t board > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > [ 142.458627] show_stack from 0xf0abdd1c > > [ 142.458646] irq event stamp: 31747 > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > [ 142.458771] DMA-API: Mapped at: > > > > Yes the mapped at is empty just after. > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > The "overlap" is in the sense of having more than one mapping within the > same cacheline: > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > This actually illustrates exactly the reason why this is unsupportable. > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > ba79f200-ba79f23f to be written back over the top of data that the > device has already started to write to memory. Hello data corruption. > > Separate DMA mappings should be from separate memory allocations, > respecting ARCH_DMA_MINALIGN. > Hello, thanks for the explanation. Does my driver can do something about it ? Like checking SGs respect this ARCH_DMA_MINALIGN constraints and if not fallback to a software implementation (as it will does non-DMA transfer). Regards _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 11:49 ` Corentin Labbe @ 2022-03-07 11:59 ` Gilad Ben-Yossef 2022-03-07 13:47 ` Corentin Labbe 0 siblings, 1 reply; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 11:59 UTC (permalink / raw) To: Corentin Labbe Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig Hi Corentin, A bug in the DMA API it is not. What is the call site that calls into the crypto driver in your case? Is it the drbg like in the cryptocell case or something else? Thanks, Gilad On Mon, Mar 7, 2022 at 1:49 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > >>> > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > >>>> > > >>>> Hello > > >>>> > > >>>> I got: > > >>>> [ 17.563793] ------------[ cut here ]------------ > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > >>> > > >>> The direction argument during unmap must match whatever direction > > >>> you used during the original map call. > > >> > > >> > > >> Yes, of course. I changed one but forgot the other. > > >> > > >> Corentin, could you be kind and check that this solves the original > > >> problem and does not produce new warnings? > > >> > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > >> index 11e0278c8631..31cfe014922e 100644 > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > >> void *ctx, > > >> req_ctx->mlli_params.mlli_dma_addr); > > >> } > > >> > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > >> - > > >> if (src != dst) { > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > >> + } else { > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > >> } > > >> } > > >> > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > >> *drvdata, void *ctx, > > >> u32 dummy = 0; > > >> int rc = 0; > > >> u32 mapped_nents = 0; > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > >> > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > >> mlli_params->curr_pool = NULL; > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > >> *drvdata, void *ctx, > > >> } > > >> > > >> /* Map the src SGL */ > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > > >> if (rc) > > >> goto cipher_exit; > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > >> *drvdata, void *ctx, > > >> } > > >> } else { > > >> /* Map the dst sg */ > > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > > >> &dummy, &mapped_nents); > > >> if (rc) > > >> > > >> > > > > > > Hello > > > > > > I still get the warning: > > > [ 433.406230] ------------[ cut here ]------------ > > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > > [ 433.406434] Modules linked in: > > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > > [ 433.406522] sp : ffff800015da3690 > > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > > [ 433.406833] Call trace: > > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > > [ 433.406904] cc_map_sg+0x80/0x100 > > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > > [ 433.407061] invoke_syscall+0x44/0x100 > > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > > [ 433.407096] do_el0_svc+0x24/0x88 > > > [ 433.407110] el0_svc+0x4c/0x100 > > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > > [ 433.407145] el0t_64_sync+0x170/0x174 > > > [ 433.407160] irq event stamp: 5624 > > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > > [ 433.407381] DMA-API: Mapped at: > > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > > [ 433.407455] cc_map_sg+0x80/0x100 > > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > > > > My sun8i-ss driver hit the same warning: > > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > > [ 142.458581] Hardware name: Allwinner A83t board > > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > > [ 142.458627] show_stack from 0xf0abdd1c > > > [ 142.458646] irq event stamp: 31747 > > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > > [ 142.458771] DMA-API: Mapped at: > > > > > > Yes the mapped at is empty just after. > > > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > > > The "overlap" is in the sense of having more than one mapping within the > > same cacheline: > > > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > > > This actually illustrates exactly the reason why this is unsupportable. > > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > > ba79f200-ba79f23f to be written back over the top of data that the > > device has already started to write to memory. Hello data corruption. > > > > Separate DMA mappings should be from separate memory allocations, > > respecting ARCH_DMA_MINALIGN. > > > > Hello, thanks for the explanation. > Does my driver can do something about it ? > Like checking SGs respect this ARCH_DMA_MINALIGN constraints and if not fallback to a software implementation (as it will does non-DMA transfer). > > Regards -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 11:59 ` Gilad Ben-Yossef @ 2022-03-07 13:47 ` Corentin Labbe 0 siblings, 0 replies; 21+ messages in thread From: Corentin Labbe @ 2022-03-07 13:47 UTC (permalink / raw) To: Gilad Ben-Yossef Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig Le Mon, Mar 07, 2022 at 01:59:00PM +0200, Gilad Ben-Yossef a écrit : > Hi Corentin, > > A bug in the DMA API it is not. > > What is the call site that calls into the crypto driver in your case? > Is it the drbg like in the cryptocell case or something else? > In my case, it is a user call from libkacpi test. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 11:14 ` Robin Murphy 2022-03-07 11:49 ` Corentin Labbe @ 2022-03-07 12:17 ` Gilad Ben-Yossef 2022-03-07 12:35 ` Robin Murphy 2022-03-07 13:45 ` Corentin Labbe 2 siblings, 1 reply; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 12:17 UTC (permalink / raw) To: Robin Murphy Cc: Herbert Xu, Linux kernel mailing list, iommu, Corentin Labbe, Linux Crypto Mailing List, Christoph Hellwig On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> wrote: > The "overlap" is in the sense of having more than one mapping within the > same cacheline: > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > This actually illustrates exactly the reason why this is unsupportable. > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > ba79f200-ba79f23f to be written back over the top of data that the > device has already started to write to memory. Hello data corruption. > > Separate DMA mappings should be from separate memory allocations, > respecting ARCH_DMA_MINALIGN. hmm... I know I'm missing something here, but how does this align with the following from active_cacheline_insert() in kernel/dma/debug.c ? /* If the device is not writing memory then we don't have any * concerns about the cpu consuming stale data. This mitigates * legitimate usages of overlapping mappings. */ if (entry->direction == DMA_TO_DEVICE) return 0; Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 12:17 ` Gilad Ben-Yossef @ 2022-03-07 12:35 ` Robin Murphy 2022-03-07 12:47 ` Gilad Ben-Yossef 0 siblings, 1 reply; 21+ messages in thread From: Robin Murphy @ 2022-03-07 12:35 UTC (permalink / raw) To: Gilad Ben-Yossef Cc: Herbert Xu, Linux kernel mailing list, iommu, Corentin Labbe, Linux Crypto Mailing List, Christoph Hellwig On 2022-03-07 12:17, Gilad Ben-Yossef wrote: > On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> wrote: > >> The "overlap" is in the sense of having more than one mapping within the >> same cacheline: >> >> [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f >> D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 >> [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc >> D=445dc010 L=10 DMA_TO_DEVICE attrs=0 >> [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 >> [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 >> [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f >> D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 >> >> This actually illustrates exactly the reason why this is unsupportable. >> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping >> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range >> ba79f200-ba79f23f to be written back over the top of data that the >> device has already started to write to memory. Hello data corruption. >> >> Separate DMA mappings should be from separate memory allocations, >> respecting ARCH_DMA_MINALIGN. > > hmm... I know I'm missing something here, but how does this align with > the following from active_cacheline_insert() in kernel/dma/debug.c ? > > /* If the device is not writing memory then we don't have any > * concerns about the cpu consuming stale data. This mitigates > * legitimate usages of overlapping mappings. > */ > if (entry->direction == DMA_TO_DEVICE) > return 0; It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which looks to be the case that this check was intended to allow. However I think you're right that it should still actually check for conflicting directions between the new entry and any existing ones, otherwise it ends up a bit too lenient. Cheers, Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 12:35 ` Robin Murphy @ 2022-03-07 12:47 ` Gilad Ben-Yossef 2022-03-07 13:03 ` Robin Murphy 0 siblings, 1 reply; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 12:47 UTC (permalink / raw) To: Robin Murphy Cc: Herbert Xu, Linux kernel mailing list, iommu, Corentin Labbe, Linux Crypto Mailing List, Christoph Hellwig On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2022-03-07 12:17, Gilad Ben-Yossef wrote: > > On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> wrote: > > > >> The "overlap" is in the sense of having more than one mapping within the > >> same cacheline: > >> > >> [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > >> D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > >> [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > >> D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > >> [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > >> [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > >> [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > >> D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > >> > >> This actually illustrates exactly the reason why this is unsupportable. > >> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > >> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > >> ba79f200-ba79f23f to be written back over the top of data that the > >> device has already started to write to memory. Hello data corruption. > >> > >> Separate DMA mappings should be from separate memory allocations, > >> respecting ARCH_DMA_MINALIGN. > > > > hmm... I know I'm missing something here, but how does this align with > > the following from active_cacheline_insert() in kernel/dma/debug.c ? > > > > /* If the device is not writing memory then we don't have any > > * concerns about the cpu consuming stale data. This mitigates > > * legitimate usages of overlapping mappings. > > */ > > if (entry->direction == DMA_TO_DEVICE) > > return 0; > > It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which > looks to be the case that this check was intended to allow. However I > think you're right that it should still actually check for conflicting > directions between the new entry and any existing ones, otherwise it > ends up a bit too lenient. > > Cheers, > Robin. I understand what you are saying about why checking for conflicting directions may be a good thing, but given that the code is as it is right now, how are we seeing the warning for two mapping that one of them is DMA_TO_DEVICE? Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 12:47 ` Gilad Ben-Yossef @ 2022-03-07 13:03 ` Robin Murphy 2022-03-07 13:12 ` Robin Murphy 2022-03-07 13:13 ` Gilad Ben-Yossef 0 siblings, 2 replies; 21+ messages in thread From: Robin Murphy @ 2022-03-07 13:03 UTC (permalink / raw) To: Gilad Ben-Yossef Cc: Herbert Xu, Linux kernel mailing list, iommu, Corentin Labbe, Linux Crypto Mailing List, Christoph Hellwig On 2022-03-07 12:47, Gilad Ben-Yossef wrote: > On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy <robin.murphy@arm.com> wrote: >> >> On 2022-03-07 12:17, Gilad Ben-Yossef wrote: >>> On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> wrote: >>> >>>> The "overlap" is in the sense of having more than one mapping within the >>>> same cacheline: >>>> >>>> [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f >>>> D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 >>>> [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc >>>> D=445dc010 L=10 DMA_TO_DEVICE attrs=0 >>>> [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 >>>> [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 >>>> [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f >>>> D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 >>>> >>>> This actually illustrates exactly the reason why this is unsupportable. >>>> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping >>>> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range >>>> ba79f200-ba79f23f to be written back over the top of data that the >>>> device has already started to write to memory. Hello data corruption. >>>> >>>> Separate DMA mappings should be from separate memory allocations, >>>> respecting ARCH_DMA_MINALIGN. >>> >>> hmm... I know I'm missing something here, but how does this align with >>> the following from active_cacheline_insert() in kernel/dma/debug.c ? >>> >>> /* If the device is not writing memory then we don't have any >>> * concerns about the cpu consuming stale data. This mitigates >>> * legitimate usages of overlapping mappings. >>> */ >>> if (entry->direction == DMA_TO_DEVICE) >>> return 0; >> >> It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which >> looks to be the case that this check was intended to allow. However I >> think you're right that it should still actually check for conflicting >> directions between the new entry and any existing ones, otherwise it >> ends up a bit too lenient. >> >> Cheers, >> Robin. > > I understand what you are saying about why checking for conflicting > directions may be a good thing, but given that the code is as it is > right now, how are we seeing the warning for two mapping that one of > them is DMA_TO_DEVICE? Because it's the second one that isn't. The warning is triggered by adding the DMA_FROM_DEVICE entry, which *is* checked, and finds the DMA_TO_DEVICE entry already present. What's not great is that if those two mappings happened to be made in the opposite order then it would be missed entirely. Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 13:03 ` Robin Murphy @ 2022-03-07 13:12 ` Robin Murphy 2022-03-07 13:21 ` Gilad Ben-Yossef 2022-03-07 13:13 ` Gilad Ben-Yossef 1 sibling, 1 reply; 21+ messages in thread From: Robin Murphy @ 2022-03-07 13:12 UTC (permalink / raw) To: Gilad Ben-Yossef Cc: Herbert Xu, Linux kernel mailing list, iommu, Corentin Labbe, Linux Crypto Mailing List, Christoph Hellwig On 2022-03-07 13:03, Robin Murphy wrote: > On 2022-03-07 12:47, Gilad Ben-Yossef wrote: >> On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy <robin.murphy@arm.com> wrote: >>> >>> On 2022-03-07 12:17, Gilad Ben-Yossef wrote: >>>> On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> >>>> wrote: >>>> >>>>> The "overlap" is in the sense of having more than one mapping >>>>> within the >>>>> same cacheline: >>>>> >>>>> [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f >>>>> D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 >>>>> [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc >>>>> D=445dc010 L=10 DMA_TO_DEVICE attrs=0 >>>>> [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 >>>>> [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 >>>>> [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f >>>>> D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 >>>>> >>>>> This actually illustrates exactly the reason why this is >>>>> unsupportable. >>>>> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping >>>>> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range >>>>> ba79f200-ba79f23f to be written back over the top of data that the >>>>> device has already started to write to memory. Hello data corruption. >>>>> >>>>> Separate DMA mappings should be from separate memory allocations, >>>>> respecting ARCH_DMA_MINALIGN. >>>> >>>> hmm... I know I'm missing something here, but how does this align with >>>> the following from active_cacheline_insert() in kernel/dma/debug.c ? >>>> >>>> /* If the device is not writing memory then we don't have any >>>> * concerns about the cpu consuming stale data. This >>>> mitigates >>>> * legitimate usages of overlapping mappings. >>>> */ >>>> if (entry->direction == DMA_TO_DEVICE) >>>> return 0; >>> >>> It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which >>> looks to be the case that this check was intended to allow. However I >>> think you're right that it should still actually check for conflicting >>> directions between the new entry and any existing ones, otherwise it >>> ends up a bit too lenient. >>> >>> Cheers, >>> Robin. >> >> I understand what you are saying about why checking for conflicting >> directions may be a good thing, but given that the code is as it is >> right now, how are we seeing the warning for two mapping that one of >> them is DMA_TO_DEVICE? > > Because it's the second one that isn't. The warning is triggered by > adding the DMA_FROM_DEVICE entry, which *is* checked, and finds the > DMA_TO_DEVICE entry already present. What's not great is that if those > two mappings happened to be made in the opposite order then it would be > missed entirely. Urgh, no, sorry, that's some imaginary conflation of the cacheline radix tree with the entry hash bucket... What's actually happened here is that I've failed to read the log properly and they're both DMA_FROM_DEVICE. But the potential problem of mixed-direction mappings being missed does still stand in general. Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 13:12 ` Robin Murphy @ 2022-03-07 13:21 ` Gilad Ben-Yossef 0 siblings, 0 replies; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 13:21 UTC (permalink / raw) To: Robin Murphy Cc: Herbert Xu, Linux kernel mailing list, iommu, Corentin Labbe, Linux Crypto Mailing List, Christoph Hellwig On Mon, Mar 7, 2022 at 3:12 PM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2022-03-07 13:03, Robin Murphy wrote: > > On 2022-03-07 12:47, Gilad Ben-Yossef wrote: > >> On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy <robin.murphy@arm.com> wrote: > >>> > >>> On 2022-03-07 12:17, Gilad Ben-Yossef wrote: > >>>> On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> > >>>> wrote: > >>>> > >>>>> The "overlap" is in the sense of having more than one mapping > >>>>> within the > >>>>> same cacheline: > >>>>> > >>>>> [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > >>>>> D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > >>>>> [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > >>>>> D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > >>>>> [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > >>>>> [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > >>>>> [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > >>>>> D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > >>>>> > >>>>> This actually illustrates exactly the reason why this is > >>>>> unsupportable. > >>>>> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > >>>>> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > >>>>> ba79f200-ba79f23f to be written back over the top of data that the > >>>>> device has already started to write to memory. Hello data corruption. > >>>>> > >>>>> Separate DMA mappings should be from separate memory allocations, > >>>>> respecting ARCH_DMA_MINALIGN. > >>>> > >>>> hmm... I know I'm missing something here, but how does this align with > >>>> the following from active_cacheline_insert() in kernel/dma/debug.c ? > >>>> > >>>> /* If the device is not writing memory then we don't have any > >>>> * concerns about the cpu consuming stale data. This > >>>> mitigates > >>>> * legitimate usages of overlapping mappings. > >>>> */ > >>>> if (entry->direction == DMA_TO_DEVICE) > >>>> return 0; > >>> > >>> It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which > >>> looks to be the case that this check was intended to allow. However I > >>> think you're right that it should still actually check for conflicting > >>> directions between the new entry and any existing ones, otherwise it > >>> ends up a bit too lenient. > >>> > >>> Cheers, > >>> Robin. > >> > >> I understand what you are saying about why checking for conflicting > >> directions may be a good thing, but given that the code is as it is > >> right now, how are we seeing the warning for two mapping that one of > >> them is DMA_TO_DEVICE? > > > > Because it's the second one that isn't. The warning is triggered by > > adding the DMA_FROM_DEVICE entry, which *is* checked, and finds the > > DMA_TO_DEVICE entry already present. What's not great is that if those > > two mappings happened to be made in the opposite order then it would be > > missed entirely. > > Urgh, no, sorry, that's some imaginary conflation of the cacheline radix > tree with the entry hash bucket... > > What's actually happened here is that I've failed to read the log > properly and they're both DMA_FROM_DEVICE. But the potential problem of > mixed-direction mappings being missed does still stand in general. Ah, right! OK, Now I feel a little better. You know, I think that dma debug logic is oversimplified a bit in other ways too. Think for example about the scenario that started this - a (crypto, but it doesn't matter) gets two sg lists - src and dst. It will map the src for DMA_TO_DEVICE and the dst as DMA_FROM_DEVICE. Now the two sg list might actually be one and the same or they might be two different sg lists but referring to the exact same buffers. So long as the driver DMA maps, says, the src first and then the dst, or vice versa, and does not initiate any read/write from either the CPU or device until the 2nd mapping, I would claim that this is perfectly safe (same thing for not touching the buffer post the first unmap and before the 2nd) and it does simplify the driver quite a bit - but the dma debug logic will consider it an error right now. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 13:03 ` Robin Murphy 2022-03-07 13:12 ` Robin Murphy @ 2022-03-07 13:13 ` Gilad Ben-Yossef 1 sibling, 0 replies; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 13:13 UTC (permalink / raw) To: Robin Murphy Cc: Herbert Xu, Linux kernel mailing list, iommu, Corentin Labbe, Linux Crypto Mailing List, Christoph Hellwig On Mon, Mar 7, 2022 at 3:03 PM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2022-03-07 12:47, Gilad Ben-Yossef wrote: > > On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy <robin.murphy@arm.com> wrote: > >> > >> On 2022-03-07 12:17, Gilad Ben-Yossef wrote: > >>> On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy <robin.murphy@arm.com> wrote: > >>> > >>>> The "overlap" is in the sense of having more than one mapping within the > >>>> same cacheline: > >>>> > >>>> [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > >>>> D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > >>>> [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > >>>> D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > >>>> [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > >>>> [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > >>>> [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > >>>> D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > >>>> > >>>> This actually illustrates exactly the reason why this is unsupportable. > >>>> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > >>>> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > >>>> ba79f200-ba79f23f to be written back over the top of data that the > >>>> device has already started to write to memory. Hello data corruption. > >>>> > >>>> Separate DMA mappings should be from separate memory allocations, > >>>> respecting ARCH_DMA_MINALIGN. > >>> > >>> hmm... I know I'm missing something here, but how does this align with > >>> the following from active_cacheline_insert() in kernel/dma/debug.c ? > >>> > >>> /* If the device is not writing memory then we don't have any > >>> * concerns about the cpu consuming stale data. This mitigates > >>> * legitimate usages of overlapping mappings. > >>> */ > >>> if (entry->direction == DMA_TO_DEVICE) > >>> return 0; > >> > >> It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which > >> looks to be the case that this check was intended to allow. However I > >> think you're right that it should still actually check for conflicting > >> directions between the new entry and any existing ones, otherwise it > >> ends up a bit too lenient. > >> > >> Cheers, > >> Robin. > > > > I understand what you are saying about why checking for conflicting > > directions may be a good thing, but given that the code is as it is > > right now, how are we seeing the warning for two mapping that one of > > them is DMA_TO_DEVICE? > > Because it's the second one that isn't. The warning is triggered by > adding the DMA_FROM_DEVICE entry, which *is* checked, and finds the > DMA_TO_DEVICE entry already present. What's not great is that if those > two mappings happened to be made in the opposite order then it would be > missed entirely. Please accept my sincere apologies if I'm being daft , but here is the code for add_dma_entry(): static void add_dma_entry(struct dma_debug_entry *entry, unsigned long attrs) { struct hash_bucket *bucket; unsigned long flags; int rc; bucket = get_hash_bucket(entry, &flags); hash_bucket_add(bucket, entry); put_hash_bucket(bucket, flags); rc = active_cacheline_insert(entry); if (rc == -ENOMEM) { pr_err("cacheline tracking ENOMEM, dma-debug disabled\n"); global_disable = true; } else if (rc == -EEXIST && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) { err_printk(entry->dev, entry, "cacheline tracking EEXIST, overlapping mappings aren't supported\n"); } } Clearly we get to active_cacheline_insert() unconditionally. Here is the code of active_cacheline_insert(): static int active_cacheline_insert(struct dma_debug_entry *entry) { phys_addr_t cln = to_cacheline_number(entry); unsigned long flags; int rc; /* If the device is not writing memory then we don't have any * concerns about the cpu consuming stale data. This mitigates * legitimate usages of overlapping mappings. */ if (entry->direction == DMA_TO_DEVICE) return 0; spin_lock_irqsave(&radix_lock, flags); rc = radix_tree_insert(&dma_active_cacheline, cln, entry); if (rc == -EEXIST) active_cacheline_inc_overlap(cln); spin_unlock_irqrestore(&radix_lock, flags); return rc; } Clearly the check for direction happens BEFORE we ever attempt to add the cacheline tracking data. So it shouldn't matter at all which is first and which is second... :-( I know I'm missing something. But what? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 11:14 ` Robin Murphy 2022-03-07 11:49 ` Corentin Labbe 2022-03-07 12:17 ` Gilad Ben-Yossef @ 2022-03-07 13:45 ` Corentin Labbe 2022-03-07 13:53 ` Gilad Ben-Yossef 2 siblings, 1 reply; 21+ messages in thread From: Corentin Labbe @ 2022-03-07 13:45 UTC (permalink / raw) To: Robin Murphy Cc: Herbert Xu, Linux kernel mailing list, Gilad Ben-Yossef, iommu, Linux Crypto Mailing List, hch Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > On 2022-03-07 10:48, Corentin Labbe wrote: > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > >>> > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > >>>> > >>>> Hello > >>>> > >>>> I got: > >>>> [ 17.563793] ------------[ cut here ]------------ > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > >>> > >>> The direction argument during unmap must match whatever direction > >>> you used during the original map call. > >> > >> > >> Yes, of course. I changed one but forgot the other. > >> > >> Corentin, could you be kind and check that this solves the original > >> problem and does not produce new warnings? > >> > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > >> index 11e0278c8631..31cfe014922e 100644 > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > >> void *ctx, > >> req_ctx->mlli_params.mlli_dma_addr); > >> } > >> > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> - > >> if (src != dst) { > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> + } else { > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > >> } > >> } > >> > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> u32 dummy = 0; > >> int rc = 0; > >> u32 mapped_nents = 0; > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > >> > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > >> mlli_params->curr_pool = NULL; > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> > >> /* Map the src SGL */ > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > >> if (rc) > >> goto cipher_exit; > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > >> *drvdata, void *ctx, > >> } > >> } else { > >> /* Map the dst sg */ > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > >> &dummy, &mapped_nents); > >> if (rc) > >> > >> > > > > Hello > > > > I still get the warning: > > [ 433.406230] ------------[ cut here ]------------ > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > [ 433.406434] Modules linked in: > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > [ 433.406522] sp : ffff800015da3690 > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > [ 433.406833] Call trace: > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > [ 433.406904] cc_map_sg+0x80/0x100 > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > [ 433.407061] invoke_syscall+0x44/0x100 > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > [ 433.407096] do_el0_svc+0x24/0x88 > > [ 433.407110] el0_svc+0x4c/0x100 > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > [ 433.407145] el0t_64_sync+0x170/0x174 > > [ 433.407160] irq event stamp: 5624 > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > [ 433.407381] DMA-API: Mapped at: > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > [ 433.407455] cc_map_sg+0x80/0x100 > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > My sun8i-ss driver hit the same warning: > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > [ 142.458581] Hardware name: Allwinner A83t board > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > [ 142.458627] show_stack from 0xf0abdd1c > > [ 142.458646] irq event stamp: 31747 > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > [ 142.458771] DMA-API: Mapped at: > > > > Yes the mapped at is empty just after. > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > The "overlap" is in the sense of having more than one mapping within the > same cacheline: > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > This actually illustrates exactly the reason why this is unsupportable. > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > ba79f200-ba79f23f to be written back over the top of data that the > device has already started to write to memory. Hello data corruption. > > Separate DMA mappings should be from separate memory allocations, > respecting ARCH_DMA_MINALIGN. > I just saw something strange, only one SG is involved, and I dont see any DMA_TO_DEVICE for ba79f210. I see 2 DMA_FROM_DEVICE (ba79f200 and ba79f210), but only one should be done. Why 2 FROM mappings are added with only one sg ? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 13:45 ` Corentin Labbe @ 2022-03-07 13:53 ` Gilad Ben-Yossef 2022-03-07 13:56 ` Corentin Labbe 0 siblings, 1 reply; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 13:53 UTC (permalink / raw) To: Corentin Labbe Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > >>> > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > >>>> > > >>>> Hello > > >>>> > > >>>> I got: > > >>>> [ 17.563793] ------------[ cut here ]------------ > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > >>> > > >>> The direction argument during unmap must match whatever direction > > >>> you used during the original map call. > > >> > > >> > > >> Yes, of course. I changed one but forgot the other. > > >> > > >> Corentin, could you be kind and check that this solves the original > > >> problem and does not produce new warnings? > > >> > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > >> index 11e0278c8631..31cfe014922e 100644 > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > >> void *ctx, > > >> req_ctx->mlli_params.mlli_dma_addr); > > >> } > > >> > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > >> - > > >> if (src != dst) { > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > >> + } else { > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > >> } > > >> } > > >> > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > >> *drvdata, void *ctx, > > >> u32 dummy = 0; > > >> int rc = 0; > > >> u32 mapped_nents = 0; > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > >> > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > >> mlli_params->curr_pool = NULL; > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > >> *drvdata, void *ctx, > > >> } > > >> > > >> /* Map the src SGL */ > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > > >> if (rc) > > >> goto cipher_exit; > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > >> *drvdata, void *ctx, > > >> } > > >> } else { > > >> /* Map the dst sg */ > > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > > >> &dummy, &mapped_nents); > > >> if (rc) > > >> > > >> > > > > > > Hello > > > > > > I still get the warning: > > > [ 433.406230] ------------[ cut here ]------------ > > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > > [ 433.406434] Modules linked in: > > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > > [ 433.406522] sp : ffff800015da3690 > > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > > [ 433.406833] Call trace: > > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > > [ 433.406904] cc_map_sg+0x80/0x100 > > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > > [ 433.407061] invoke_syscall+0x44/0x100 > > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > > [ 433.407096] do_el0_svc+0x24/0x88 > > > [ 433.407110] el0_svc+0x4c/0x100 > > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > > [ 433.407145] el0t_64_sync+0x170/0x174 > > > [ 433.407160] irq event stamp: 5624 > > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > > [ 433.407381] DMA-API: Mapped at: > > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > > [ 433.407455] cc_map_sg+0x80/0x100 > > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > > > > My sun8i-ss driver hit the same warning: > > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > > [ 142.458581] Hardware name: Allwinner A83t board > > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > > [ 142.458627] show_stack from 0xf0abdd1c > > > [ 142.458646] irq event stamp: 31747 > > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > > [ 142.458771] DMA-API: Mapped at: > > > > > > Yes the mapped at is empty just after. > > > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > > > The "overlap" is in the sense of having more than one mapping within the > > same cacheline: > > > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > > > This actually illustrates exactly the reason why this is unsupportable. > > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > > ba79f200-ba79f23f to be written back over the top of data that the > > device has already started to write to memory. Hello data corruption. > > > > Separate DMA mappings should be from separate memory allocations, > > respecting ARCH_DMA_MINALIGN. > > > > I just saw something strange, only one SG is involved, and I dont see any DMA_TO_DEVICE for ba79f210. > I see 2 DMA_FROM_DEVICE (ba79f200 and ba79f210), but only one should be done. > Why 2 FROM mappings are added with only one sg ? > The thing that does the memory allocation of user calls from libkcapi tests is the crypto/af_alg.c code ... I assume the sglist has two buffers? could it be that somehow they are not DMA aligned? that would be weird indeed... -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 13:53 ` Gilad Ben-Yossef @ 2022-03-07 13:56 ` Corentin Labbe 2022-03-07 14:00 ` Gilad Ben-Yossef 2022-03-08 9:40 ` Corentin Labbe 0 siblings, 2 replies; 21+ messages in thread From: Corentin Labbe @ 2022-03-07 13:56 UTC (permalink / raw) To: Gilad Ben-Yossef Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > > >>> > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > >>>> > > > >>>> Hello > > > >>>> > > > >>>> I got: > > > >>>> [ 17.563793] ------------[ cut here ]------------ > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > >>> > > > >>> The direction argument during unmap must match whatever direction > > > >>> you used during the original map call. > > > >> > > > >> > > > >> Yes, of course. I changed one but forgot the other. > > > >> > > > >> Corentin, could you be kind and check that this solves the original > > > >> problem and does not produce new warnings? > > > >> > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> index 11e0278c8631..31cfe014922e 100644 > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > > >> void *ctx, > > > >> req_ctx->mlli_params.mlli_dma_addr); > > > >> } > > > >> > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > >> - > > > >> if (src != dst) { > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > >> + } else { > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > >> } > > > >> } > > > >> > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > >> *drvdata, void *ctx, > > > >> u32 dummy = 0; > > > >> int rc = 0; > > > >> u32 mapped_nents = 0; > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > > >> > > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > > >> mlli_params->curr_pool = NULL; > > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > >> *drvdata, void *ctx, > > > >> } > > > >> > > > >> /* Map the src SGL */ > > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > > > >> if (rc) > > > >> goto cipher_exit; > > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > >> *drvdata, void *ctx, > > > >> } > > > >> } else { > > > >> /* Map the dst sg */ > > > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > > > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > > > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > > > >> &dummy, &mapped_nents); > > > >> if (rc) > > > >> > > > >> > > > > > > > > Hello > > > > > > > > I still get the warning: > > > > [ 433.406230] ------------[ cut here ]------------ > > > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > > > [ 433.406434] Modules linked in: > > > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > > > [ 433.406522] sp : ffff800015da3690 > > > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > > > [ 433.406833] Call trace: > > > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > > > [ 433.406904] cc_map_sg+0x80/0x100 > > > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > > > [ 433.407061] invoke_syscall+0x44/0x100 > > > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > > > [ 433.407096] do_el0_svc+0x24/0x88 > > > > [ 433.407110] el0_svc+0x4c/0x100 > > > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > > > [ 433.407145] el0t_64_sync+0x170/0x174 > > > > [ 433.407160] irq event stamp: 5624 > > > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > > > [ 433.407381] DMA-API: Mapped at: > > > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > > > [ 433.407455] cc_map_sg+0x80/0x100 > > > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > > > > > > > My sun8i-ss driver hit the same warning: > > > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > > > [ 142.458581] Hardware name: Allwinner A83t board > > > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > > > [ 142.458627] show_stack from 0xf0abdd1c > > > > [ 142.458646] irq event stamp: 31747 > > > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > > > [ 142.458771] DMA-API: Mapped at: > > > > > > > > Yes the mapped at is empty just after. > > > > > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > > > > > The "overlap" is in the sense of having more than one mapping within the > > > same cacheline: > > > > > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > > > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > > > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > > > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > > > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > > > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > > > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > > > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > > > > > This actually illustrates exactly the reason why this is unsupportable. > > > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > > > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > > > ba79f200-ba79f23f to be written back over the top of data that the > > > device has already started to write to memory. Hello data corruption. > > > > > > Separate DMA mappings should be from separate memory allocations, > > > respecting ARCH_DMA_MINALIGN. > > > > > > > I just saw something strange, only one SG is involved, and I dont see any DMA_TO_DEVICE for ba79f210. > > I see 2 DMA_FROM_DEVICE (ba79f200 and ba79f210), but only one should be done. > > Why 2 FROM mappings are added with only one sg ? > > > > The thing that does the memory allocation of user calls from libkcapi > tests is the crypto/af_alg.c code ... > > I assume the sglist has two buffers? could it be that somehow they are > not DMA aligned? that would be weird indeed... > The SGlist has only one SG, so only one buffer, it is why I dont understand the double call to add_dma_entry(). _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 13:56 ` Corentin Labbe @ 2022-03-07 14:00 ` Gilad Ben-Yossef 2022-03-07 14:05 ` Corentin Labbe 2022-03-08 9:40 ` Corentin Labbe 1 sibling, 1 reply; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 14:00 UTC (permalink / raw) To: Corentin Labbe Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig On Mon, Mar 7, 2022 at 3:56 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a ďż˝crit : > > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > > > >>> > > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > >>>> > > > > >>>> Hello > > > > >>>> > > > > >>>> I got: > > > > >>>> [ 17.563793] ------------[ cut here ]------------ > > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > > >>> > > > > >>> The direction argument during unmap must match whatever direction > > > > >>> you used during the original map call. > > > > >> > > > > >> > > > > >> Yes, of course. I changed one but forgot the other. > > > > >> > > > > >> Corentin, could you be kind and check that this solves the original > > > > >> problem and does not produce new warnings? > > > > >> > > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> index 11e0278c8631..31cfe014922e 100644 > > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > > > >> void *ctx, > > > > >> req_ctx->mlli_params.mlli_dma_addr); > > > > >> } > > > > >> > > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > >> - > > > > >> if (src != dst) { > > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > >> + } else { > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > >> } > > > > >> } > > > > >> > > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> u32 dummy = 0; > > > > >> int rc = 0; > > > > >> u32 mapped_nents = 0; > > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > > > >> > > > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > > > >> mlli_params->curr_pool = NULL; > > > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> } > > > > >> > > > > >> /* Map the src SGL */ > > > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > > > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > > > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > > > > >> if (rc) > > > > >> goto cipher_exit; > > > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> } > > > > >> } else { > > > > >> /* Map the dst sg */ > > > > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > > > > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > > > > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > > > > >> &dummy, &mapped_nents); > > > > >> if (rc) > > > > >> > > > > >> > > > > > > > > > > Hello > > > > > > > > > > I still get the warning: > > > > > [ 433.406230] ------------[ cut here ]------------ > > > > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > > > > [ 433.406434] Modules linked in: > > > > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > > > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > > > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > > > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > > > > [ 433.406522] sp : ffff800015da3690 > > > > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > > > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > > > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > > > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > > > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > > > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > > > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > > > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > > > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > > > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > > > > [ 433.406833] Call trace: > > > > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > > > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > > > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > > > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > > > > [ 433.406904] cc_map_sg+0x80/0x100 > > > > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > > > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > > > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > > > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > > > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > > > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > > > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > > > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > > > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > > > > [ 433.407061] invoke_syscall+0x44/0x100 > > > > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > > > > [ 433.407096] do_el0_svc+0x24/0x88 > > > > > [ 433.407110] el0_svc+0x4c/0x100 > > > > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > > > > [ 433.407145] el0t_64_sync+0x170/0x174 > > > > > [ 433.407160] irq event stamp: 5624 > > > > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > > > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > > > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > > > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > > > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > > > > [ 433.407381] DMA-API: Mapped at: > > > > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > > > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > > > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > > > > [ 433.407455] cc_map_sg+0x80/0x100 > > > > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > > > > > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > > > > > > > > > > My sun8i-ss driver hit the same warning: > > > > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > > > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > > > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > > > > [ 142.458581] Hardware name: Allwinner A83t board > > > > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > > > > [ 142.458627] show_stack from 0xf0abdd1c > > > > > [ 142.458646] irq event stamp: 31747 > > > > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > > > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > > > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > > > > [ 142.458771] DMA-API: Mapped at: > > > > > > > > > > Yes the mapped at is empty just after. > > > > > > > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > > > > > > > The "overlap" is in the sense of having more than one mapping within the > > > > same cacheline: > > > > > > > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > > > > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > > > > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > > > > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > > > > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > > > > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > > > > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > > > > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > > > > > > > This actually illustrates exactly the reason why this is unsupportable. > > > > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > > > > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > > > > ba79f200-ba79f23f to be written back over the top of data that the > > > > device has already started to write to memory. Hello data corruption. > > > > > > > > Separate DMA mappings should be from separate memory allocations, > > > > respecting ARCH_DMA_MINALIGN. > > > > > > > > > > I just saw something strange, only one SG is involved, and I dont see any DMA_TO_DEVICE for ba79f210. > > > I see 2 DMA_FROM_DEVICE (ba79f200 and ba79f210), but only one should be done. > > > Why 2 FROM mappings are added with only one sg ? > > > > > > > The thing that does the memory allocation of user calls from libkcapi > > tests is the crypto/af_alg.c code ... > > > > I assume the sglist has two buffers? could it be that somehow they are > > not DMA aligned? that would be weird indeed... > > > > The SGlist has only one SG, so only one buffer, it is why I dont understand the double call to add_dma_entry(). But... a scatter gather list by its nature can hold more than one buffer, no? that is the whole purpose of a scatter gather list...? -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 14:00 ` Gilad Ben-Yossef @ 2022-03-07 14:05 ` Corentin Labbe 0 siblings, 0 replies; 21+ messages in thread From: Corentin Labbe @ 2022-03-07 14:05 UTC (permalink / raw) To: Gilad Ben-Yossef Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig Le Mon, Mar 07, 2022 at 04:00:44PM +0200, Gilad Ben-Yossef a écrit : > On Mon, Mar 7, 2022 at 3:56 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > > > Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > > > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > > > > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > > > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a ďż˝crit : > > > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > > > > >>> > > > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > > >>>> > > > > > >>>> Hello > > > > > >>>> > > > > > >>>> I got: > > > > > >>>> [ 17.563793] ------------[ cut here ]------------ > > > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > > > >>> > > > > > >>> The direction argument during unmap must match whatever direction > > > > > >>> you used during the original map call. > > > > > >> > > > > > >> > > > > > >> Yes, of course. I changed one but forgot the other. > > > > > >> > > > > > >> Corentin, could you be kind and check that this solves the original > > > > > >> problem and does not produce new warnings? > > > > > >> > > > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> index 11e0278c8631..31cfe014922e 100644 > > > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > > > > >> void *ctx, > > > > > >> req_ctx->mlli_params.mlli_dma_addr); > > > > > >> } > > > > > >> > > > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > > >> - > > > > > >> if (src != dst) { > > > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > > > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > > > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > > >> + } else { > > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > > >> } > > > > > >> } > > > > > >> > > > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > > >> *drvdata, void *ctx, > > > > > >> u32 dummy = 0; > > > > > >> int rc = 0; > > > > > >> u32 mapped_nents = 0; > > > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > > > > >> > > > > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > > > > >> mlli_params->curr_pool = NULL; > > > > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > > >> *drvdata, void *ctx, > > > > > >> } > > > > > >> > > > > > >> /* Map the src SGL */ > > > > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > > > > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > > > > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > > > > > >> if (rc) > > > > > >> goto cipher_exit; > > > > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > > >> *drvdata, void *ctx, > > > > > >> } > > > > > >> } else { > > > > > >> /* Map the dst sg */ > > > > > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > > > > > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > > > > > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > > > > > >> &dummy, &mapped_nents); > > > > > >> if (rc) > > > > > >> > > > > > >> > > > > > > > > > > > > Hello > > > > > > > > > > > > I still get the warning: > > > > > > [ 433.406230] ------------[ cut here ]------------ > > > > > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406434] Modules linked in: > > > > > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > > > > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > > > > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > > > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406522] sp : ffff800015da3690 > > > > > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > > > > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > > > > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > > > > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > > > > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > > > > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > > > > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > > > > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > > > > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > > > > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > > > > > [ 433.406833] Call trace: > > > > > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > > > > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > > > > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > > > > > [ 433.406904] cc_map_sg+0x80/0x100 > > > > > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > > > > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > > > > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > > > > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > > > > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > > > > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > > > > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > > > > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > > > > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > > > > > [ 433.407061] invoke_syscall+0x44/0x100 > > > > > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > > > > > [ 433.407096] do_el0_svc+0x24/0x88 > > > > > > [ 433.407110] el0_svc+0x4c/0x100 > > > > > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > > > > > [ 433.407145] el0t_64_sync+0x170/0x174 > > > > > > [ 433.407160] irq event stamp: 5624 > > > > > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > > > > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > > > > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > > > > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > > > > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > > > > > [ 433.407381] DMA-API: Mapped at: > > > > > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > > > > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > > > > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > > > > > [ 433.407455] cc_map_sg+0x80/0x100 > > > > > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > > > > > > > > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > > > > > > > > > > > > > My sun8i-ss driver hit the same warning: > > > > > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > > > > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > > > > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > > > > > [ 142.458581] Hardware name: Allwinner A83t board > > > > > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > > > > > [ 142.458627] show_stack from 0xf0abdd1c > > > > > > [ 142.458646] irq event stamp: 31747 > > > > > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > > > > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > > > > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > > > > > [ 142.458771] DMA-API: Mapped at: > > > > > > > > > > > > Yes the mapped at is empty just after. > > > > > > > > > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > > > > > > > > > The "overlap" is in the sense of having more than one mapping within the > > > > > same cacheline: > > > > > > > > > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > > > > > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > > > > > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > > > > > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > > > > > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > > > > > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > > > > > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > > > > > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > > > > > > > > > This actually illustrates exactly the reason why this is unsupportable. > > > > > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > > > > > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > > > > > ba79f200-ba79f23f to be written back over the top of data that the > > > > > device has already started to write to memory. Hello data corruption. > > > > > > > > > > Separate DMA mappings should be from separate memory allocations, > > > > > respecting ARCH_DMA_MINALIGN. > > > > > > > > > > > > > I just saw something strange, only one SG is involved, and I dont see any DMA_TO_DEVICE for ba79f210. > > > > I see 2 DMA_FROM_DEVICE (ba79f200 and ba79f210), but only one should be done. > > > > Why 2 FROM mappings are added with only one sg ? > > > > > > > > > > The thing that does the memory allocation of user calls from libkcapi > > > tests is the crypto/af_alg.c code ... > > > > > > I assume the sglist has two buffers? could it be that somehow they are > > > not DMA aligned? that would be weird indeed... > > > > > > > The SGlist has only one SG, so only one buffer, it is why I dont understand the double call to add_dma_entry(). > > But... a scatter gather list by its nature can hold more than one > buffer, no? that is the whole purpose of a scatter gather list...? > Each buffer is "in" one struct scatterlist (this is what I call SG, perhaps wrongly). The debug sun8i-ss 1c15000.crypto: DST 0/1/1 show that we have only one entry (as given by sg_nents_for_len() and dma_map_sg()) Sorry for my misleading SG. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 13:56 ` Corentin Labbe 2022-03-07 14:00 ` Gilad Ben-Yossef @ 2022-03-08 9:40 ` Corentin Labbe 2022-03-09 6:49 ` Gilad Ben-Yossef 1 sibling, 1 reply; 21+ messages in thread From: Corentin Labbe @ 2022-03-08 9:40 UTC (permalink / raw) To: Gilad Ben-Yossef Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig Le Mon, Mar 07, 2022 at 02:56:21PM +0100, Corentin Labbe a écrit : > Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit : > > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > > > >>> > > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > >>>> > > > > >>>> Hello > > > > >>>> > > > > >>>> I got: > > > > >>>> [ 17.563793] ------------[ cut here ]------------ > > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > > >>> > > > > >>> The direction argument during unmap must match whatever direction > > > > >>> you used during the original map call. > > > > >> > > > > >> > > > > >> Yes, of course. I changed one but forgot the other. > > > > >> > > > > >> Corentin, could you be kind and check that this solves the original > > > > >> problem and does not produce new warnings? > > > > >> > > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> index 11e0278c8631..31cfe014922e 100644 > > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > > > >> void *ctx, > > > > >> req_ctx->mlli_params.mlli_dma_addr); > > > > >> } > > > > >> > > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > >> - > > > > >> if (src != dst) { > > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > >> + } else { > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > >> } > > > > >> } > > > > >> > > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> u32 dummy = 0; > > > > >> int rc = 0; > > > > >> u32 mapped_nents = 0; > > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > > > >> > > > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > > > >> mlli_params->curr_pool = NULL; > > > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> } > > > > >> > > > > >> /* Map the src SGL */ > > > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > > > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > > > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > > > > >> if (rc) > > > > >> goto cipher_exit; > > > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > >> *drvdata, void *ctx, > > > > >> } > > > > >> } else { > > > > >> /* Map the dst sg */ > > > > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > > > > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > > > > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > > > > >> &dummy, &mapped_nents); > > > > >> if (rc) > > > > >> > > > > >> > > > > > > > > > > Hello > > > > > > > > > > I still get the warning: > > > > > [ 433.406230] ------------[ cut here ]------------ > > > > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > > > > [ 433.406434] Modules linked in: > > > > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > > > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > > > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > > > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > > > > [ 433.406522] sp : ffff800015da3690 > > > > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > > > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > > > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > > > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > > > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > > > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > > > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > > > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > > > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > > > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > > > > [ 433.406833] Call trace: > > > > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > > > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > > > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > > > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > > > > [ 433.406904] cc_map_sg+0x80/0x100 > > > > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > > > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > > > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > > > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > > > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > > > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > > > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > > > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > > > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > > > > [ 433.407061] invoke_syscall+0x44/0x100 > > > > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > > > > [ 433.407096] do_el0_svc+0x24/0x88 > > > > > [ 433.407110] el0_svc+0x4c/0x100 > > > > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > > > > [ 433.407145] el0t_64_sync+0x170/0x174 > > > > > [ 433.407160] irq event stamp: 5624 > > > > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > > > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > > > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > > > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > > > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > > > > [ 433.407381] DMA-API: Mapped at: > > > > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > > > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > > > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > > > > [ 433.407455] cc_map_sg+0x80/0x100 > > > > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > > > > > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > > > > > > > > > > My sun8i-ss driver hit the same warning: > > > > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > > > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > > > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > > > > [ 142.458581] Hardware name: Allwinner A83t board > > > > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > > > > [ 142.458627] show_stack from 0xf0abdd1c > > > > > [ 142.458646] irq event stamp: 31747 > > > > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > > > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > > > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > > > > [ 142.458771] DMA-API: Mapped at: > > > > > > > > > > Yes the mapped at is empty just after. > > > > > > > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > > > > > > > The "overlap" is in the sense of having more than one mapping within the > > > > same cacheline: > > > > > > > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > > > > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > > > > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > > > > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > > > > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > > > > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > > > > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > > > > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > > > > > > > This actually illustrates exactly the reason why this is unsupportable. > > > > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > > > > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > > > > ba79f200-ba79f23f to be written back over the top of data that the > > > > device has already started to write to memory. Hello data corruption. > > > > > > > > Separate DMA mappings should be from separate memory allocations, > > > > respecting ARCH_DMA_MINALIGN. > > > > > > > > > > I just saw something strange, only one SG is involved, and I dont see any DMA_TO_DEVICE for ba79f210. > > > I see 2 DMA_FROM_DEVICE (ba79f200 and ba79f210), but only one should be done. > > > Why 2 FROM mappings are added with only one sg ? > > > > > > > The thing that does the memory allocation of user calls from libkcapi > > tests is the crypto/af_alg.c code ... > > > > I assume the sglist has two buffers? could it be that somehow they are > > not DMA aligned? that would be weird indeed... > > > > The SGlist has only one SG, so only one buffer, it is why I dont understand the double call to add_dma_entry(). Answering myself, the driver can handle 2 requests in parallel, this is the reason of 2 dma call. And both are using the same key, and so first DMA call (for the key) give same address. This is something hard to prevent at driver level. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-08 9:40 ` Corentin Labbe @ 2022-03-09 6:49 ` Gilad Ben-Yossef 0 siblings, 0 replies; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-09 6:49 UTC (permalink / raw) To: Corentin Labbe Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig On Tue, Mar 8, 2022 at 11:40 AM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > Le Mon, Mar 07, 2022 at 02:56:21PM +0100, Corentin Labbe a écrit : > > Le Mon, Mar 07, 2022 at 03:53:02PM +0200, Gilad Ben-Yossef a écrit : > > > On Mon, Mar 7, 2022 at 3:45 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > > > > > > > Le Mon, Mar 07, 2022 at 11:14:16AM +0000, Robin Murphy a écrit : > > > > > On 2022-03-07 10:48, Corentin Labbe wrote: > > > > > > Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a ďż˝crit : > > > > > >> On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > > > > >>> > > > > > >>> On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote: > > > > > >>>> > > > > > >>>> Hello > > > > > >>>> > > > > > >>>> I got: > > > > > >>>> [ 17.563793] ------------[ cut here ]------------ > > > > > >>>> [ 17.568492] DMA-API: ccree e6601000.crypto: device driver frees DMA memory with different direction [device address=0x0000000078fe5800] [size=8 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] > > > > > >>> > > > > > >>> The direction argument during unmap must match whatever direction > > > > > >>> you used during the original map call. > > > > > >> > > > > > >> > > > > > >> Yes, of course. I changed one but forgot the other. > > > > > >> > > > > > >> Corentin, could you be kind and check that this solves the original > > > > > >> problem and does not produce new warnings? > > > > > >> > > > > > >> diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> index 11e0278c8631..31cfe014922e 100644 > > > > > >> --- a/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> +++ b/drivers/crypto/ccree/cc_buffer_mgr.c > > > > > >> @@ -356,12 +356,14 @@ void cc_unmap_cipher_request(struct device *dev, > > > > > >> void *ctx, > > > > > >> req_ctx->mlli_params.mlli_dma_addr); > > > > > >> } > > > > > >> > > > > > >> - dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > > >> - dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > > >> - > > > > > >> if (src != dst) { > > > > > >> - dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL); > > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_TO_DEVICE); > > > > > >> + dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_FROM_DEVICE); > > > > > >> dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst)); > > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > > >> + } else { > > > > > >> + dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL); > > > > > >> + dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src)); > > > > > >> } > > > > > >> } > > > > > >> > > > > > >> @@ -377,6 +379,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > > >> *drvdata, void *ctx, > > > > > >> u32 dummy = 0; > > > > > >> int rc = 0; > > > > > >> u32 mapped_nents = 0; > > > > > >> + int src_direction = (src != dst ? DMA_TO_DEVICE : DMA_BIDIRECTIONAL); > > > > > >> > > > > > >> req_ctx->dma_buf_type = CC_DMA_BUF_DLLI; > > > > > >> mlli_params->curr_pool = NULL; > > > > > >> @@ -399,7 +402,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > > >> *drvdata, void *ctx, > > > > > >> } > > > > > >> > > > > > >> /* Map the src SGL */ > > > > > >> - rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, &req_ctx->in_nents, > > > > > >> + rc = cc_map_sg(dev, src, nbytes, src_direction, &req_ctx->in_nents, > > > > > >> LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents); > > > > > >> if (rc) > > > > > >> goto cipher_exit; > > > > > >> @@ -416,7 +419,7 @@ int cc_map_cipher_request(struct cc_drvdata > > > > > >> *drvdata, void *ctx, > > > > > >> } > > > > > >> } else { > > > > > >> /* Map the dst sg */ > > > > > >> - rc = cc_map_sg(dev, dst, nbytes, DMA_BIDIRECTIONAL, > > > > > >> + rc = cc_map_sg(dev, dst, nbytes, DMA_FROM_DEVICE, > > > > > >> &req_ctx->out_nents, LLI_MAX_NUM_OF_DATA_ENTRIES, > > > > > >> &dummy, &mapped_nents); > > > > > >> if (rc) > > > > > >> > > > > > >> > > > > > > > > > > > > Hello > > > > > > > > > > > > I still get the warning: > > > > > > [ 433.406230] ------------[ cut here ]------------ > > > > > > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406434] Modules linked in: > > > > > > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > > > > > > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > > > > > > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > > > > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406522] sp : ffff800015da3690 > > > > > > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > > > > > > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > > > > > > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > > > > > > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > > > > > > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > > > > > > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > > > > > > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > > > > > > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > > > > > > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > > > > > > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > > > > > > [ 433.406833] Call trace: > > > > > > [ 433.406841] add_dma_entry+0x1d0/0x288 > > > > > > [ 433.406854] debug_dma_map_sg+0x150/0x398 > > > > > > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > > > > > > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > > > > > > [ 433.406904] cc_map_sg+0x80/0x100 > > > > > > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > > > > > > [ 433.406939] cc_cipher_process+0x210/0xb58 > > > > > > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > > > > > > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > > > > > > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > > > > > > [ 433.407003] ____sys_recvmsg+0x90/0x280 > > > > > > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > > > > > > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > > > > > > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > > > > > > [ 433.407061] invoke_syscall+0x44/0x100 > > > > > > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > > > > > > [ 433.407096] do_el0_svc+0x24/0x88 > > > > > > [ 433.407110] el0_svc+0x4c/0x100 > > > > > > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > > > > > > [ 433.407145] el0t_64_sync+0x170/0x174 > > > > > > [ 433.407160] irq event stamp: 5624 > > > > > > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > > > > > > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > > > > > > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > > > > > > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > > > > > > [ 433.407241] ---[ end trace 0000000000000000 ]--- > > > > > > [ 433.407381] DMA-API: Mapped at: > > > > > > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > > > > > > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > > > > > > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > > > > > > [ 433.407455] cc_map_sg+0x80/0x100 > > > > > > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > > > > > > > > > > > > > > > > BUT I start to thing this is a bug in DMA-API debug. > > > > > > > > > > > > > > > > > > My sun8i-ss driver hit the same warning: > > > > > > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > > > > > > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > > > > > > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > > > > > > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > > > > > > [ 142.458581] Hardware name: Allwinner A83t board > > > > > > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > > > > > > [ 142.458627] show_stack from 0xf0abdd1c > > > > > > [ 142.458646] irq event stamp: 31747 > > > > > > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > > > > > > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > > > > > > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > > > > > > [ 142.458758] ---[ end trace 0000000000000000 ]--- > > > > > > [ 142.458771] DMA-API: Mapped at: > > > > > > > > > > > > Yes the mapped at is empty just after. > > > > > > > > > > > > And the sequence of DMA operations in my driver is simple, so I cannot see how any overlap could occur. > > > > > > > > > > The "overlap" is in the sense of having more than one mapping within the > > > > > same cacheline: > > > > > > > > > > [ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f > > > > > D=ba79f200 L=10 DMA_FROM_DEVICE attrs=0 > > > > > [ 142.458156] DMA-API: add_dma_entry start P=445dc010 N=445dc > > > > > D=445dc010 L=10 DMA_TO_DEVICE attrs=0 > > > > > [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=16 bi=0 > > > > > [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=16 bi=0 > > > > > [ 142.458234] DMA-API: add_dma_entry start P=ba79f210 N=ba79f > > > > > D=ba79f210 L=10 DMA_FROM_DEVICE attrs=0 > > > > > > > > > > This actually illustrates exactly the reason why this is unsupportable. > > > > > ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > > > > > ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > > > > > ba79f200-ba79f23f to be written back over the top of data that the > > > > > device has already started to write to memory. Hello data corruption. > > > > > > > > > > Separate DMA mappings should be from separate memory allocations, > > > > > respecting ARCH_DMA_MINALIGN. > > > > > > > > > > > > > I just saw something strange, only one SG is involved, and I dont see any DMA_TO_DEVICE for ba79f210. > > > > I see 2 DMA_FROM_DEVICE (ba79f200 and ba79f210), but only one should be done. > > > > Why 2 FROM mappings are added with only one sg ? > > > > > > > > > > The thing that does the memory allocation of user calls from libkcapi > > > tests is the crypto/af_alg.c code ... > > > > > > I assume the sglist has two buffers? could it be that somehow they are > > > not DMA aligned? that would be weird indeed... > > > > > > > The SGlist has only one SG, so only one buffer, it is why I dont understand the double call to add_dma_entry(). > > > Answering myself, the driver can handle 2 requests in parallel, this is the reason of 2 dma call. > And both are using the same key, and so first DMA call (for the key) give same address. > > This is something hard to prevent at driver level. I don't think you can safely DMA map the key though anyway? what if you were passed a stack variable? Better to have an internally allocated context buffer, copy the key there and map that buffer. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 10:48 ` [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 Corentin Labbe 2022-03-07 11:14 ` Robin Murphy @ 2022-03-07 12:24 ` Gilad Ben-Yossef 2022-03-07 13:43 ` Gilad Ben-Yossef 2 siblings, 0 replies; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 12:24 UTC (permalink / raw) To: Corentin Labbe Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig On Mon, Mar 7, 2022 at 12:48 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > Hello > > I still get the warning: > [ 433.406230] ------------[ cut here ]------------ > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > [ 433.406434] Modules linked in: > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > [ 433.406522] sp : ffff800015da3690 > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > [ 433.406833] Call trace: > [ 433.406841] add_dma_entry+0x1d0/0x288 > [ 433.406854] debug_dma_map_sg+0x150/0x398 > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > [ 433.406904] cc_map_sg+0x80/0x100 > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > [ 433.406939] cc_cipher_process+0x210/0xb58 > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > [ 433.407003] ____sys_recvmsg+0x90/0x280 > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > [ 433.407061] invoke_syscall+0x44/0x100 > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > [ 433.407096] do_el0_svc+0x24/0x88 > [ 433.407110] el0_svc+0x4c/0x100 > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > [ 433.407145] el0t_64_sync+0x170/0x174 > [ 433.407160] irq event stamp: 5624 > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > [ 433.407241] ---[ end trace 0000000000000000 ]--- > [ 433.407381] DMA-API: Mapped at: > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > [ 433.407455] cc_map_sg+0x80/0x100 > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 By the way, this comes from a totally different call site than the previous drbg. Judging from the fact that we've never seen this error before and that you start seeing it suddenly from different drivers on different platforms from different call sites ... I suspect this is caused by some recent addition or change. Which tree are you building this from and does it have dma related commits? may try toi bisect this? Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 2022-03-07 10:48 ` [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 Corentin Labbe 2022-03-07 11:14 ` Robin Murphy 2022-03-07 12:24 ` Gilad Ben-Yossef @ 2022-03-07 13:43 ` Gilad Ben-Yossef 2 siblings, 0 replies; 21+ messages in thread From: Gilad Ben-Yossef @ 2022-03-07 13:43 UTC (permalink / raw) To: Corentin Labbe Cc: Herbert Xu, Linux kernel mailing list, iommu, Linux Crypto Mailing List, Robin Murphy, Christoph Hellwig On Mon, Mar 7, 2022 at 12:48 PM Corentin Labbe <clabbe.montjoie@gmail.com> wrote: > > Hello > > I still get the warning: > [ 433.406230] ------------[ cut here ]------------ > [ 433.406326] DMA-API: ccree e6601000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > [ 433.406386] WARNING: CPU: 7 PID: 31074 at /home/clabbe/linux-next/kernel/dma/debug.c:571 add_dma_entry+0x1d0/0x288 > [ 433.406434] Modules linked in: > [ 433.406458] CPU: 7 PID: 31074 Comm: kcapi Not tainted 5.17.0-rc6-next-20220303-00130-g30042e47ee47-dirty #54 > [ 433.406473] Hardware name: Renesas Salvator-X board based on r8a77950 (DT) > [ 433.406484] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 433.406498] pc : add_dma_entry+0x1d0/0x288 > [ 433.406510] lr : add_dma_entry+0x1d0/0x288 > [ 433.406522] sp : ffff800015da3690 > [ 433.406531] x29: ffff800015da3690 x28: 0000000000000000 x27: 0000000000000000 > [ 433.406562] x26: 0000000000000000 x25: ffff80000b4c7bc0 x24: ffff80000b4c7000 > [ 433.406593] x23: 0000000000000000 x22: 00000000ffffffef x21: ffff80000a9b6000 > [ 433.406623] x20: ffff0004c0af5c00 x19: ffff80000b420000 x18: ffffffffffffffff > [ 433.406653] x17: 6c7265766f202c54 x16: 534958454520676e x15: 000000000000022e > [ 433.406683] x14: ffff800015da3380 x13: 00000000ffffffea x12: ffff80000b4be010 > [ 433.406713] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff80000b4a6028 > [ 433.406743] x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : ffff80000b4a5fd0 > [ 433.406773] x5 : ffff0006ff795c48 x4 : 0000000000000000 x3 : 0000000000000027 > [ 433.406802] x2 : 0000000000000023 x1 : 8ca4e4fbf4b87900 x0 : 0000000000000000 > [ 433.406833] Call trace: > [ 433.406841] add_dma_entry+0x1d0/0x288 > [ 433.406854] debug_dma_map_sg+0x150/0x398 > [ 433.406869] __dma_map_sg_attrs+0x9c/0x108 > [ 433.406889] dma_map_sg_attrs+0x10/0x28 > [ 433.406904] cc_map_sg+0x80/0x100 > [ 433.406924] cc_map_cipher_request+0x178/0x3c8 > [ 433.406939] cc_cipher_process+0x210/0xb58 > [ 433.406953] cc_cipher_encrypt+0x2c/0x38 > [ 433.406967] crypto_skcipher_encrypt+0x44/0x78 > [ 433.406986] skcipher_recvmsg+0x36c/0x420 > [ 433.407003] ____sys_recvmsg+0x90/0x280 > [ 433.407024] ___sys_recvmsg+0x88/0xd0 > [ 433.407038] __sys_recvmsg+0x6c/0xd0 > [ 433.407049] __arm64_sys_recvmsg+0x24/0x30 > [ 433.407061] invoke_syscall+0x44/0x100 > [ 433.407082] el0_svc_common.constprop.3+0x90/0x120 > [ 433.407096] do_el0_svc+0x24/0x88 > [ 433.407110] el0_svc+0x4c/0x100 > [ 433.407131] el0t_64_sync_handler+0x90/0xb8 > [ 433.407145] el0t_64_sync+0x170/0x174 > [ 433.407160] irq event stamp: 5624 > [ 433.407168] hardirqs last enabled at (5623): [<ffff80000812f6a8>] __up_console_sem+0x60/0x98 > [ 433.407191] hardirqs last disabled at (5624): [<ffff800009c9a060>] el1_dbg+0x28/0x90 > [ 433.407208] softirqs last enabled at (5570): [<ffff8000097e62f8>] lock_sock_nested+0x80/0xa0 > [ 433.407226] softirqs last disabled at (5568): [<ffff8000097e62d8>] lock_sock_nested+0x60/0xa0 > [ 433.407241] ---[ end trace 0000000000000000 ]--- > [ 433.407381] DMA-API: Mapped at: > [ 433.407396] debug_dma_map_sg+0x16c/0x398 > [ 433.407416] __dma_map_sg_attrs+0x9c/0x108 > [ 433.407436] dma_map_sg_attrs+0x10/0x28 > [ 433.407455] cc_map_sg+0x80/0x100 > [ 433.407475] cc_map_cipher_request+0x178/0x3c8 > > > BUT I start to thing this is a bug in DMA-API debug. > > > My sun8i-ss driver hit the same warning: > [ 142.458351] WARNING: CPU: 1 PID: 90 at kernel/dma/debug.c:597 add_dma_entry+0x2ec/0x4cc > [ 142.458429] DMA-API: sun8i-ss 1c15000.crypto: cacheline tracking EEXIST, overlapping mappings aren't supported > [ 142.458455] Modules linked in: ccm algif_aead xts cmac > [ 142.458563] CPU: 1 PID: 90 Comm: 1c15000.crypto- Not tainted 5.17.0-rc6-next-20220307-00132-g39dad568d20a-dirty #223 > [ 142.458581] Hardware name: Allwinner A83t board > [ 142.458596] unwind_backtrace from show_stack+0x10/0x14 > [ 142.458627] show_stack from 0xf0abdd1c > [ 142.458646] irq event stamp: 31747 > [ 142.458660] hardirqs last enabled at (31753): [<c019316c>] __up_console_sem+0x50/0x60 > [ 142.458688] hardirqs last disabled at (31758): [<c0193158>] __up_console_sem+0x3c/0x60 > [ 142.458710] softirqs last enabled at (31600): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > [ 142.458738] softirqs last disabled at (31580): [<c06990c8>] sun8i_ss_handle_cipher_request+0x300/0x8b8 > [ 142.458758] ---[ end trace 0000000000000000 ]--- > [ 142.458771] DMA-API: Mapped at: The more I think about it, the more I suspect that this is a problem of the input sglists to crypto API calls overlapping in some fashion, either between src and dst or maybe even across different crypto operations and HW crypto drivers just mapping those sglists, oblivious to it. What are crypto HW drivers to do? scan each input scatterlist for overlap, not just between src and dst of the same operation but also across different crypto operations? That is insane... I am not sure where to go from here. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2022-03-09 6:49 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAOtvUMeoYcVm7OQdqXd1V5iPSXW_BkVxx6TA6nF7zTLVeHe0Ww@mail.gmail.com>
[not found] ` <CAOtvUMfy1fF35B2sfbOMui8n9Q4iCke9rgn5TiYMUMjd8gqHsA@mail.gmail.com>
[not found] ` <YhKV55t90HWm6bhv@Red>
[not found] ` <CAOtvUMdRU4wnRCXsC+U5XBDp+b+u8w7W7JCUKW2+ohuJz3PVhQ@mail.gmail.com>
[not found] ` <YhOcEQEjIKBrbMIZ@Red>
[not found] ` <CAOtvUMfN8U4+eG-TEVW4bSE6kOzuOSsJE4dOYGXYuWQKNzv7wQ@mail.gmail.com>
[not found] ` <CAOtvUMeRb=j=NDrc88x8aB-3=D1mxZ_-aA1d4FfvJmj7Jrbi4w@mail.gmail.com>
[not found] ` <YiIUXtxd44ut5uzV@Red>
[not found] ` <YiUsWosH+MKMF7DQ@gondor.apana.org.au>
[not found] ` <CAOtvUMcudG3ySU+VeE7hfneDVWGLKFTnws-xjhq4hgFYSj0qOg@mail.gmail.com>
2022-03-07 10:48 ` [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 Corentin Labbe
2022-03-07 11:14 ` Robin Murphy
2022-03-07 11:49 ` Corentin Labbe
2022-03-07 11:59 ` Gilad Ben-Yossef
2022-03-07 13:47 ` Corentin Labbe
2022-03-07 12:17 ` Gilad Ben-Yossef
2022-03-07 12:35 ` Robin Murphy
2022-03-07 12:47 ` Gilad Ben-Yossef
2022-03-07 13:03 ` Robin Murphy
2022-03-07 13:12 ` Robin Murphy
2022-03-07 13:21 ` Gilad Ben-Yossef
2022-03-07 13:13 ` Gilad Ben-Yossef
2022-03-07 13:45 ` Corentin Labbe
2022-03-07 13:53 ` Gilad Ben-Yossef
2022-03-07 13:56 ` Corentin Labbe
2022-03-07 14:00 ` Gilad Ben-Yossef
2022-03-07 14:05 ` Corentin Labbe
2022-03-08 9:40 ` Corentin Labbe
2022-03-09 6:49 ` Gilad Ben-Yossef
2022-03-07 12:24 ` Gilad Ben-Yossef
2022-03-07 13:43 ` Gilad Ben-Yossef
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox