linux-kernel - Re: [PATCH] x86/dma-mapping: override via_no

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]

Date:   Tue, 17 Apr 2018 15:33:08 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     'Christoph Hellwig' <hch@...radead.org>
cc:     David Wang <davidwang@...oxin.com>, mingo@...hat.com,
        hpa@...or.com, gregkh@...uxfoundation.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, brucechang@...-alliance.com,
        cooperyan@...oxin.com, qiyuanwang@...oxin.com,
        benjaminpan@...tech.com, lukelin@...cpu.com, timguo@...oxin.com
Subject: Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI
 bridges

On Tue, 17 Apr 2018, 'Christoph Hellwig' wrote:
> On Tue, Apr 17, 2018 at 10:54:37AM +0200, Thomas Gleixner wrote:
> > The question was rather to have a list of PCI IDs for those chipsets which
> > have the problem and set the 'disable' flag only for those. That makes a lot
> > more sense than making a list of new chips which disable the disable flag.
> 
> Agreed.
> 
> There are a few other things I'd like to do in this area while we're
> at it (I'm happy to do the work, not trying to offload it to David
> or Thomas):
> 
>  (1) make the nodac flag a per-device flag.  Set for every device
>      under one of the affected VIA bridges, or for all PCI devices
>      if the nodac command line option is used
>  (2) move that flag into the common struct device (or the to be
>      designed dma struct hanging off it in the future) and make that
>      bit handled in common code as there is a common Xilinx host
>      bridge with a 32-bit dma limitation
>  (3) kill of the forcesac option, which was a strange performance
>      tweak back in plain PCI days, which probably didn't even work
>      as expected to start with.

Sounds good.