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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ