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: <757729fb-1eb5-e1fa-899b-5cef0cc3106c@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ