netdev - Re: [PATCH net-next 6/6] mlxsw: pci: Add support for new reset flow

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: <ZCVHtk/wqTAR4Ejd@shredder>
Date:   Thu, 30 Mar 2023 11:26:30 +0300
From:   Ido Schimmel <idosch@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Bjorn Helgaas <helgaas@...nel.org>,
        Petr Machata <petrm@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        Amit Cohen <amcohen@...dia.com>, mlxsw@...dia.com,
        linux-pci@...r.kernel.org, Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH net-next 6/6] mlxsw: pci: Add support for new reset flow

On Wed, Mar 29, 2023 at 11:10:01AM -0600, Alex Williamson wrote:
> I think we don't have it because it's unclear how it's actually
> different from a secondary bus reset from the bridge control register,
> which is what "bus" would do when selected for the example above.  Per
> the spec, both must cause a hot reset.  It seems this device needs a
> significantly longer delay though.

Assuming you are referring to the 2ms sleep in
pci_reset_secondary_bus(), then yes. In our case, after disabling the
link on the downstream port we need to wait for 500ms before enabling
it.

> Note that hot resets can be generated by a userspace driver with
> ownership of the device and will make use of the pci-core reset
> mechanisms.  Therefore if there is not a device specific reset, we'll
> use the standard delays and the device ought not to get itself wedged
> if the link becomes active at an unexpected point relative to a
> firmware update.  This might be a point in favor of a device specific
> reset solution in pci-core.  Thanks,

I assume you referring to something like this:

# echo 1 > /sys/class/pci_bus/0000:03/device/0000:03:00.0/reset

Doesn't seem to have any effect (network ports remain up, at least).
Anyway, this device is completely managed by the kernel, not a user
space driver. I'm not aware of anyone using this method to reset the
device.

If I understand Bjorn and you correctly, we have two options:

1. Keep the current implementation inside the driver.

2. Call __pci_reset_function_locked() from the driver and move the link
toggling to drivers/pci/quirks.c as a "device_specific" method.

Personally, I don't see any benefit in 2, but we can try to implement
it, see if it even works and then decide.

Please let me know what are your preferences.

Thanks