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, 15 Dec 2017 14:01:57 -0600
From:   Govinda Tatti <Govinda.Tatti@...cle.COM>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     jgross@...e.com, Sinan Kaya <okaya@...eaurora.org>,
        Srikanth Jampala <Jampala.Srikanth@...ium.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Satanand Burla <satananda.burla@...iumnetworks.com>,
        linux-pci@...r.kernel.org,
        Felix Manlunas <felix.manlunas@...iumnetworks.com>,
        linux-kernel@...r.kernel.org,
        Derek Chickles <derek.chickles@...iumnetworks.com>,
        Christoph Hellwig <hch@...radead.org>, JBeulich@...e.com,
        Russell Currey <ruscur@...sell.cc>, bhelgaas@...gle.com,
        xen-devel@...ts.xenproject.org, boris.ostrovsky@...cle.COM,
        Raghu Vatsavayi <raghu.vatsavayi@...iumnetworks.com>,
        roger.pau@...rix.com
Subject: Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr()
 interface


Thanks Bjorn for your response. Please see below for my comments.
>> So, we should consider one of these options.
>>
>> - set PCI_DEV_FLAGS_NO_FLR_RESET if it is not supported.
>> - pcie_flr() should return if it is not supported
>>
>> If we modify pcie_flr() to return error codes, then we need to modify
>> all existing modules that are calling this function.
> Yes, of course.
>
>> Please let me know your preference, so that I can move accordingly. Thanks.
> I think Christoph volunteered to do some restructuring, but I don't
> know his timeframe.  If you can, I would probably wait for that
> because there's so much overlap here.
OK.
>
> The other paths that use PCI_EXP_DEVCTL_BCR_FLR are definitely issues
> and should be fixed, but again should wait for the revised pcie_flr()
> interface.  And if they're not actually required for your Xen issue,
> they sound like "nice to have" cleanups that will not gate your Xen
> fixes.  I added this to my ever-growing list of cleanups to do.
For now, I am planning to use existing pcie_flr() after checking FLR
capability inside Xenpciback driver (like other existing pcie_flr()
usage). We will switch to revised pcie_flr() once it is available.

Cheers
GOVINDA

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ