linux-kernel - Re: [PATCH v3] PCI: Check for PCIe downtraining conditions

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:   Mon, 23 Jul 2018 12:01:48 -0500
From:   "Alex G." <mr.nuke.me@...il.com>
To:     Tal Gilboa <talgi@...lanox.com>, Bjorn Helgaas <helgaas@...nel.org>
Cc:     bhelgaas@...gle.com, alex_gagniuc@...lteam.com,
        austin_bolen@...l.com, shyam_iyer@...l.com, keith.busch@...el.com,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Ariel Elior <ariel.elior@...ium.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Ganesh Goudar <ganeshgr@...lsio.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Dave Airlie <airlied@...il.com>,
        Alex Deucher <alexander.deucher@....com>
Subject: Re: [PATCH v3] PCI: Check for PCIe downtraining conditions

On 07/23/2018 12:21 AM, Tal Gilboa wrote:
> On 7/19/2018 6:49 PM, Alex G. wrote:
>>
>>
>> On 07/18/2018 08:38 AM, Tal Gilboa wrote:
>>> On 7/16/2018 5:17 PM, Bjorn Helgaas wrote:
>>>> [+cc maintainers of drivers that already use pcie_print_link_status()
>>>> and GPU folks]
>> [snip]
>>>>
>>>>> +    /* Multi-function PCIe share the same link/status. */
>>>>> +    if ((PCI_FUNC(dev->devfn) != 0) || dev->is_virtfn)
>>>>> +        return;
>>>>> +
>>>>> +    pcie_print_link_status(dev);
>>>>> +}
>>>
>>> Is this function called by default for every PCIe device? What about 
>>> VFs? We make an exception for them on our driver since a VF doesn't 
>>> have access to the needed information in order to provide a 
>>> meaningful message.
>>
>> I'm assuming VF means virtual function. pcie_print_link_status() 
>> doesn't care if it's passed a virtual function. It will try to do its 
>> job. That's why I bail out three lines above, with 'dev->is_virtfn' 
>> check.
>>
>> Alex
> 
> That's the point - we don't want to call pcie_print_link_status() for 
> virtual functions. We make the distinction in our driver. If you want to 
> change the code to call this function by default it shouldn't affect the 
> current usage.

I'm not understanding very well what you're asking. I understand you 
want to avoid printing this message on virtual functions, and that's 
already taken care of. I'm also not changing current behavior.  Let's 
get v2 out and start the discussion again based on that.

Alex