lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6fe34090-656d-491f-8173-217d20144166@inbox.ru>
Date: Fri, 22 Dec 2023 18:53:03 +0300
From: Maxim Kochetkov <fido_max@...ox.ru>
To: Jiaxun Yang <jiaxun.yang@...goat.com>, Conor Dooley <conor@...nel.org>
Cc: Christoph Hellwig <hch@....de>, linux-riscv@...ts.infradead.org,
 linux-kernel@...r.kernel.org, robh@...nel.org, mpe@...erman.id.au,
 aou@...s.berkeley.edu, palmer@...belt.com, paul.walmsley@...ive.com
Subject: Re: [PATCH 1/1] riscv: set ARCH_DMA_DEFAULT_COHERENT if
 RISCV_DMA_NONCOHERENT is not set



On 22.12.2023 18:45, Jiaxun Yang wrote:
> 
> 
> 在 2023/12/22 15:38, Maxim Kochetkov 写道:
>>
>>
>> On 22.12.2023 17:54, Conor Dooley wrote:
>>
>>>> etc..) do not have this feature. These devices will use value from
>>>> device_initialize(). And we have no possibility to change
>>>> dma_default_coherent value by disabling ARCH_DMA_DEFAULT_COHERENT.
>>>> Moreover, changing dma_default_coherent from false to true may cause
>>>> regression for other devices.
>>>
>>> How can there be a regression when dma has been coherent by default for
>>> the RISC-V kernel from day 1?
>>
>> Before ARCH_DMA_DEFAULT_COHERENT patch dma_default_coherent was used 
>> unassigned as "false" in device_initialize():
>> ..........
>> #if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
>>     defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
>>     defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
>>     dev->dma_coherent = dma_default_coherent;
>> #endif
>> ..........
>> And now it becomes "true". It may change behavior of other non-DT 
>> drivers.
> I don't see any problem here, default is default.
> Actually leaving those device with  dev->dma_coherent = false is risky, 
> because
> we can't guarantee underlying cache flush functions are here.
> 
> If a non-dt device do need to override it, it should be done in 
> arch_setup_dma_ops.

But arch_setup_dma_ops() is called only from of_dma_configure_id() and 
acpi_dma_configure_id(). So it works only for DT and ACPI devices. What 
about platform_device?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ