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] [day] [month] [year] [list]
Message-ID: <df28aa12-176c-4761-a901-a2dd63a61b71@amd.com>
Date: Thu, 15 May 2025 14:39:38 +0530
From: "Rangoju, Raju" <raju.rangoju@....com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: kernel test robot <lkp@...el.com>, broonie@...nel.org,
 oe-kbuild-all@...ts.linux.dev, linux-spi@...r.kernel.org,
 linux-kernel@...r.kernel.org, Krishnamoorthi M <krishnamoorthi.m@....com>,
 Akshata MukundShetty <akshata.mukundshetty@....com>
Subject: Re: [PATCH] spi: spi_amd: Add HIDDMA basic write support



On 5/13/2025 12:04 AM, Geert Uytterhoeven wrote:
> Hi Raju,
> 
> On Mon, 12 May 2025 at 19:55, Rangoju, Raju <raju.rangoju@....com> wrote:
>> On 5/12/2025 7:47 PM, Geert Uytterhoeven wrote:
>>> On Mon, 12 May 2025 at 09:29, Rangoju, Raju <raju.rangoju@....com> wrote:
>>>> On 5/11/2025 3:51 AM, kernel test robot wrote:
>>>>> kernel test robot noticed the following build warnings:
>>>>>
>>>>> [auto build test WARNING on v6.15-rc5]
>>>>> [also build test WARNING on linus/master]
>>>>> [cannot apply to broonie-spi/for-next next-20250509]
>>>>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>>>>> And when submitting patch, we suggest to use '--base' as documented in
>>>>> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>>>>>
>>>>> url:    https://github.com/intel-lab-lkp/linux/commits/Raju-Rangoju/spi-spi_amd-Add-HIDDMA-basic-write-support/20250510-021954
>>>>> base:   v6.15-rc5
>>>>> patch link:    https://lore.kernel.org/r/20250509181737.997167-1-Raju.Rangoju%40amd.com
>>>>> patch subject: [PATCH] spi: spi_amd: Add HIDDMA basic write support
>>>>> config: m68k-randconfig-r111-20250511 (https://download.01.org/0day-ci/archive/20250511/202505110641.zLT16Dv7-lkp@intel.com/config)
>>>>> compiler: m68k-linux-gcc (GCC) 14.2.0
>>>>
>>>> Thanks for reporting this. We do not support m68k.
>>>
>>> All write[bwlq]() functions take a volatile void __iomem pointer
>>> (https://elixir.bootlin.com/linux/v6.14.6/source/include/asm-generic/io.h#L174)
>>> while you are passing a void *, so sparse should complain about this
>>> on all architectures.
>>
>> My bad, with the following flags included, sparse now complains this on
>> all architectures.
>>
>> -fmax-errors=unlimited -fmax-warnings=unlimited
>>
>> And sparse is right, this driver is using MMIO
>>> accessors on allocated DMA memory, which is just plain wrong:
>>>
>>>       amd_spi->dma_virt_addr = dma_alloc_coherent(dev, AMD_SPI_HID2_DMA_SIZE,
>>>               &amd_spi->phy_dma_buf, GFP_KERNEL);
>>>
>>>        for (i = 0; left_data >= 8; i++, left_data -= 8)
>>>               *buf_64++ = readq((u8 __iomem *)amd_spi->dma_virt_addr + (i * 8));
>>>
>>>> Will re-spin v2 with necessary changes in Kconfig.
>>>
>>> Please fix the real issue instead ;-)
>>
>> We are using read*/write* calls instead of memcpy to copy data to/from
>> DMA memory due to performance concerns, as we observed better throughput
>> during continuous read/write compared to the memcpy functions.
>
Hi Geert,

> Perhaps your memcpy() copies backwards?

Nope. The Source and destinations are in different address range, so we 
do not do backward copying.

> https://lwn.net/Articles/1016300/
> 
> There is no guarantee that read*/write* calls work on normal RAM on
> all architectures. It may just crash, as some architectures return
> cookies instead of real pointers when mapping MMIO.

Okay. We will copy the data to/from the DMA buffer by iterating 
(ensuring that memory access is safe) by avoiding MMIO accessor usage 
(`read*`/`write*`).

For example:

u64 *dma_buff = (u64 *)amd_spi->dma_virt_addr;
...
for (i = 0; i < nbytes / 8; i++)
     *dma_buff++ = *buf_64++;

We will re-spin V2 with these changes.

> Gr{oetje,eeting}s,
> 
>                          Geert
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ