linux-kernel - Re: [PATCH net-next v1 1/1] net: phy: add remote fault support

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: <YqdQJepq3Klvr5n5@lunn.ch>
Date:   Mon, 13 Jun 2022 16:56:37 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Michal Kubecek <mkubecek@...e.cz>, kernel@...gutronix.de,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 1/1] net: phy: add remote fault support

> If I see it correctly, there is no way to notify about remote fault when
> the link is up. The remote fault bit is transferred withing Link Code
> Word as part of FLP burst. At least in this part of specification.

Thanks for looking at the specification. So ksetting does seem like
the right API.

Sorry, i won't have time to look at the specification until tomorrow.
The next question is, is it a separate value, or as more link mode
bits? Or a mixture of both? Is there a capability bit somewhere to
indicate this PHY can advertise a remote fault? That would suggest we
want a ETHTOOL_LINK_MODE_REMOTE_FAULT_BIT, which we can set in
supported and maybe see in lpa? Set it in advertising when indicating
a fault. The actual fault value could then be in a separate value
which gets written to the extended page? Does 802.3 allow a remote
fault to be indicated but without the reason?

> So receiving remote fault information via linkstate and send remote fault via
> ksetting?

We could also just broadcast the results of a ksetting get to
userspace?

I don't have easy access to a machine at the moment. What does

ip monitor all

show when a link is configured up, but autoneg fails? And when autoneg
is successful but indicates a remote fault? Are there any existing
messages sent to userspace?

> The next logical question is, if a remote fault is RX'ed (potentially with a
> reason) who will react on this. There might be different policies on how to
> react on same reason.

Policy goes in userspace, is the general rule.

The only exception might be, if we decide to make use of one of these
to silence the link to allow cabling testing. We probably want the
kernel to try to do that.

       Andrew