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] [thread-next>] [day] [month] [year] [list]

Message-ID: <049fbd3906b60f75be3900f20f6974967da374f3.camel@xry111.site>
Date:   Fri, 13 Oct 2023 21:15:10 +0800
From:   Xi Ruoyao <xry111@...111.site>
To:     Sui Jingfeng <suijingfeng@...ngson.cn>,
        WANG Xuerui <kernel@...0n.name>,
        Icenowy Zheng <uwu@...nowy.me>,
        Huacai Chen <chenhuacai@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Weihao Li <liweihao@...ngson.cn>,
        "Mike Rapoport (IBM)" <rppt@...nel.org>,
        Jun Yi <yijun@...ngson.cn>, Baoquan He <bhe@...hat.com>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        David Hildenbrand <david@...hat.com>,
        Hongchen Zhang <zhanghongchen@...ngson.cn>,
        Binbin Zhou <zhoubinbin@...ngson.cn>,
        Zhen Lei <thunder.leizhen@...wei.com>,
        Tiezhu Yang <yangtiezhu@...ngson.cn>,
        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

On Fri, 2023-10-13 at 20:51 +0800, Sui Jingfeng wrote:
> Hi,
> 
> 
> On 2023/10/10 20:26, Xi Ruoyao wrote:
> > > - 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.
> 
> 
> Yeah, domain specific reviewers are really hard to persuade to accept our solution.
> Probably because they are not know our hardware very well.

The problem: why this is only an issue with DRM devices?  Work around it
in DRM subsystem just does not make sense to me, at all.

You cannot exclude the possibility that another subsystem will start to
hit the same issue in the future.  Then such a "solution" will cause #if
CONFIG_LOONGARCH scattering everywhere and doing so is completely
unmaintainable.

> But the side effects of this patch is really too hurt to accept. In this case, if you really want to make
> a progress by workaround.

This is not a valid reason.  For example, the spectre-like bug
workarounds hurts the performance as well, but we enable them on
affected CPUs by default.

> I think you could try scan the PCI device in the whole
> system on boot time. Turn off the WC mappings when there is a AMD or ATI GPUs found.

Again, why this is only an issue with AMD or ATI GPUs?

Can you provide some detailed documentations about this hardware issue
so the community can help to figure out a solution?

> Leave the the WC mappings open at the rest of cases. But this is yet another ugly
> workaround. Perhaps it is a bit of better than this because there is no way left.

And this also won't work with PCI hotplug, I'm not sure if it's
supported now but I'm 99% sure you'll add it in the future.

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University