netdev - Re: [ethtool v5 2/6] Add cable test TDR 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] [day] [month] [year] [list]

Date:   Tue, 23 Nov 2021 22:17:21 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Michal Kubecek <mkubecek@...e.cz>, netdev <netdev@...r.kernel.org>,
        Chris Healy <cphealy@...il.com>
Subject: Re: [ethtool v5 2/6] Add cable test TDR support

> Andrew, is this missing the following patch?
> 
> diff --git a/netlink/cable_test.c b/netlink/cable_test.c
> index 17139f7d297d..9305a4763c5b 100644
> --- a/netlink/cable_test.c
> +++ b/netlink/cable_test.c
> @@ -225,6 +225,7 @@ static int nl_cable_test_process_results(struct cmd_context *ctx)
>         nlctx->is_monitor = true;
>         nlsk->port = 0;
>         nlsk->seq = 0;
> +       nlctx->filter_devname = ctx->devname;
>  
>         ctctx.breakout = false;
>         nlctx->cmd_private = &ctctx;
> @@ -496,6 +497,7 @@ static int nl_cable_test_tdr_process_results(struct cmd_context *ctx)
>         nlctx->is_monitor = true;
>         nlsk->port = 0;
>         nlsk->seq = 0;
> +       nlctx->filter_devname = ctx->devname;
>  
>         ctctx.breakout = false;
>         nlctx->cmd_private = &ctctx;
> 
> I don't have hardware with cable test support so wondered if you could
> test it.

Hi Ido

I've tested this. No obvious regressions. My broken cable is still
broken.

> I think that without this patch you would see problems with two
> simultaneous cable tests. The first one to finish will terminate both
> ethtool processes because the code is processing all cable tests
> notifications regardless of the device for which the test was issued.

I did not test such a setup. But you are correct, the message from the
kernel is broadcast, and any waiting process will consume it, even if
it is for a different device.

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew