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

Message-ID: <20180417130040.GA9426@infradead.org>
Date:   Tue, 17 Apr 2018 06:00:40 -0700
From:   'Christoph Hellwig' <hch@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     David Wang <davidwang@...oxin.com>,
        'Christoph Hellwig' <hch@...radead.org>, 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, 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.