linux-kernel - Re: [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as same as ioremap

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: <dfc53da9-a1ab-4ab3-aba2-d100f7f28b9b@linux.dev>
Date: Tue, 3 Dec 2024 00:23:07 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Xi Ruoyao <xry111@...111.site>, WANG Xuerui <kernel@...0n.name>,
 Icenowy Zheng <uwu@...nowy.me>, Huacai Chen <chenhuacai@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 "Mike Rapoport (IBM)" <rppt@...nel.org>, Baoquan He <bhe@...hat.com>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 David Hildenbrand <david@...hat.com>, Zhen Lei <thunder.leizhen@...wei.com>,
 Thomas Gleixner <tglx@...utronix.de>, Zhihong Dong <donmor3000@...mail.com>,
 loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as
 same as ioremap_wc

Hi,

On 10/10/23 20:26, Xi Ruoyao wrote:
> On Tue, 2023-10-10 at 11:02 +0800, Sui Jingfeng wrote:
> 
>>
>> On LoongArch, cached mapping and uncached mappings are DMA-coherent and guaranteed by
>> the hardware. While WC mappings is *NOT* DMA-coherent when 3D GPU is involved. Therefore,
>> On downstream kernel, We disable write combine(WC) mappings at the drm drivers side.
> 
> Why it's only an issue when 3D GPU is involved? 

No one saying that only 3D GPU is suffer from this kind of issue,
I just meant that the issue is there at least for GPU

> What's the difference between 3D GPUs and other devices?  Is it possible that the other
> devices (say neural accelerators) start to perform DMA accesses in a
> similar way and then suddenly broken?

You, the patch contributor or the maintainer or whatever stuff
should carry on the test, right?

We are not intended to against the patch though.

>> - For buffers at VRAM(device memory), we replace the WC mappings with uncached mappings.
>> - For buffers reside in RAM, we replace the WC mappings with cached mappings.
>>
>> By this way, we were able to minimum the side effects, and meet the usable requirements
>> for all of the GPU drivers.
> 
> AFAIK there has been some clear NAK from DRM maintainers towards this
> "approach".  So it's not possible to be applied upstream.

That's your guys problems, stealing other programmer's patch.
And then, submit it to upstream without knowing and/or presenting
decent hardware details.


>> For DMA non-coherent buffers, we should try to implement arch-specific dma_map_ops,
>> invalidate the CPU cache and flush the CPU write buffer before the device do DMA. Instead
>> of pretend to be DMA coherent for all buffers, a kernel cmdline is not a system level
>> solution for all of GPU drivers and OS release.
> 
> IIUC this is a hardware bug of 7A1000 and 7A2000, so the proper location
> of the workaround is in the bridge chip driver.  Or am I
> misunderstanding something?
> 

You are misunderstanding everything and ranting like a dog.

The write buffers are inside the CPU, and the write-combine is related
to *both* the CPU side and the GPU side. The GPU side could choose
no snooping access mode, while the CPU side have to address such request
properly.

What's we arguing is that if this is a hardware bug of north bridge, we
at least still should be able to use WC at the CPU side, that is, WC on
system pages should be usable without any issue. While the weird commit
disable everything.