linux-kernel - Re: [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in DEVCTL2 on a hot-plug

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]

Date:   Fri, 23 Jun 2023 08:12:53 -0500
From:   Jay Cornwall <jay.cornwall@....com>
To:     Lukas Wunner <lukas@...ner.de>,
        Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
Cc:     linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        Bjorn Helgaas <bhelgaas@...gle.com>, oohall@...il.com,
        Mahesh J Salgaonkar <mahesh@...ux.ibm.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Yazen Ghannam <yazen.ghannam@....com>,
        Fontenot Nathan <Nathan.Fontenot@....com>,
        Felix Kuehling <Felix.Kuehling@....com>
Subject: Re: [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in
 DEVCTL2 on a hot-plug

On 6/22/2023 16:42, Lukas Wunner wrote:

> I don't now why commit 430a23689dea, which introduced
> pci_enable_atomic_ops_to_root(), chose to add it as a library function
> which is only called from specific drivers, instead of universally
> enabling the feature for all devices.  Adding the commit authors to cc
> so they can chime in.

IIRC during the initial design discussion on linux-pci this approach was suggested to avoid triggering potential bugs in devices without AtomicOps support. See quote below.

I've no objections to changing it.

On 2016-05-06 10:48, Bjorn Helgaas wrote:

> Once enabled in Device Control 2, a device's use of AtomicOps is
> competely device-specific.  In many cases, the device probably doesn't
> support AtomicOps, so enabling them would be a no-op.  But there could
> be devices where AtomicOps are nominally supported but untested or
> broken.  Even if we didn't change their drivers, those devices could
> start using AtomicOps, so I'm not comfortable with the PCI core
> enabling AtomicOp requests indiscriminately.