| Message ID | 20230327121317.4081816-9-arnd@kernel.org (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | dma-mapping: unify support for cache flushes | expand |
On Mon, Mar 27, 2023 at 02:13:04PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > No other architecture intentionally writes back dirty cache lines into > a buffer that a device has just finished writing into. If the cache is > clean, this has no effect at all, but > if a cacheline in the buffer has > actually been written by the CPU, there is a drive bug that is likely > made worse by overwriting that buffer. So does this need a Fixes: 1631ba1259d6 ("riscv: Add support for non-coherent devices using zicbom extension") then, even if the cacheline really should not have been touched by the CPU? Also, minor typo, s/drive/driver/. In the thread we had that sparked this, I went digging for the source of the flushes, and it came from a review comment: https://lore.kernel.org/linux-riscv/342e3c12-ebb0-badf-7d4c-c444a2b842b2@sholland.org/ But *surely* if no other arch needs to do that, then we are safe to also not do it... Your logic seems right by me at least, especially given the lack of flushes elsewhere. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Cheers, Conor. > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > arch/riscv/mm/dma-noncoherent.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index d919efab6eba..640f4c496d26 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size, > break; > case DMA_FROM_DEVICE: > case DMA_BIDIRECTIONAL: > - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); > + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size); > break; > default: > break; > -- > 2.39.2 >
On 27 Mar 2023, at 13:13, Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > No other architecture intentionally writes back dirty cache lines into > a buffer that a device has just finished writing into. If the cache is > clean, this has no effect at all, but if a cacheline in the buffer has > actually been written by the CPU, there is a drive bug that is likely > made worse by overwriting that buffer. FYI [1] proposed this same change a while ago but its justification was flawed (which was my objection at the time, not the diff itself). Jess [1] https://lore.kernel.org/all/20220818165105.99746-1-s.miroshnichenko@yadro.com > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > arch/riscv/mm/dma-noncoherent.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index d919efab6eba..640f4c496d26 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size, > break; > case DMA_FROM_DEVICE: > case DMA_BIDIRECTIONAL: > - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); > + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size); > break; > default: > break; > -- > 2.39.2 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Wed, Mar 29, 2023, at 22:48, Conor Dooley wrote: > On Mon, Mar 27, 2023 at 02:13:04PM +0200, Arnd Bergmann wrote: >> From: Arnd Bergmann <arnd@arndb.de> >> >> No other architecture intentionally writes back dirty cache lines into >> a buffer that a device has just finished writing into. If the cache is >> clean, this has no effect at all, but > >> if a cacheline in the buffer has >> actually been written by the CPU, there is a drive bug that is likely >> made worse by overwriting that buffer. > > So does this need a > Fixes: 1631ba1259d6 ("riscv: Add support for non-coherent devices using > zicbom extension") > then, even if the cacheline really should not have been touched by the > CPU? > Also, minor typo, s/drive/driver/. done > In the thread we had that sparked this, I went digging for the source of > the flushes, and it came from a review comment: > https://lore.kernel.org/linux-riscv/342e3c12-ebb0-badf-7d4c-c444a2b842b2@sholland.org/ Ah, so the comment that led to it was "For arch_sync_dma_for_cpu(DMA_BIDIRECTIONAL), we expect the CPU to have written to the buffer, so this should flush, not invalidate." which sounds like Samuel just misunderstood what "bidirectional" means: the comment implies that both the cpu and the device access the buffer before arch_sync_dma_for_cpu(DMA_BIDIRECTIONAL), but this is not allowed. Instead, the point is that the device may both read and write the buffer, requiring that we must do a writeback at arch_sync_dma_for_device(DMA_BIDIRECTIONAL) and an invalidate at arch_sync_dma_for_cpu(DMA_BIDIRECTIONAL). The comment about arch_sync_dma_for_device(DMA_FROM_DEVICE) (in the same email) seems equally confused. It's of course easy to misunderstand these, and many others have gotten confused in similar ways before. > But *surely* if no other arch needs to do that, then we are safe to also > not do it... Your logic seems right by me at least, especially given the > lack of flushes elsewhere. Right, I remove the extra writeback from powerpc, parisc and microblaze for the same reason. Those appear to only be there because they used the same function for _for_device() as for _for_cpu(), not because someone thought they were required. > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Thanks! Arnd
On Mon, Mar 27, 2023 at 1:16 PM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > No other architecture intentionally writes back dirty cache lines into > a buffer that a device has just finished writing into. If the cache is > clean, this has no effect at all, but if a cacheline in the buffer has > actually been written by the CPU, there is a drive bug that is likely > made worse by overwriting that buffer. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > arch/riscv/mm/dma-noncoherent.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Cheers, Prabhakar > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index d919efab6eba..640f4c496d26 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size, > break; > case DMA_FROM_DEVICE: > case DMA_BIDIRECTIONAL: > - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); > + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size); > break; > default: > break; > -- > 2.39.2 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Mon, 27 Mar 2023 05:13:04 PDT (-0700), arnd@kernel.org wrote: > From: Arnd Bergmann <arnd@arndb.de> > > No other architecture intentionally writes back dirty cache lines into > a buffer that a device has just finished writing into. If the cache is > clean, this has no effect at all, but if a cacheline in the buffer has > actually been written by the CPU, there is a drive bug that is likely > made worse by overwriting that buffer. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > arch/riscv/mm/dma-noncoherent.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index d919efab6eba..640f4c496d26 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size, > break; > case DMA_FROM_DEVICE: > case DMA_BIDIRECTIONAL: > - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); > + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size); > break; > default: > break; Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c index d919efab6eba..640f4c496d26 100644 --- a/arch/riscv/mm/dma-noncoherent.c +++ b/arch/riscv/mm/dma-noncoherent.c @@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size, break; case DMA_FROM_DEVICE: case DMA_BIDIRECTIONAL: - ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size); + ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size); break; default: break;