netdev - Re: Regression: Network link not coming up after suspend/resume cycle

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:   Mon, 30 Sep 2019 02:26:21 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Jan Janssen <medhefgo@....de>
Cc:     netdev <netdev@...r.kernel.org>,
        Vedang Patel <vedang.patel@...el.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: Regression: Network link not coming up after suspend/resume cycle

Hi Jan,

On Sun, 29 Sep 2019 at 22:25, Jan Janssen <medhefgo@....de> wrote:
>
> Hi,
>
> I've been noticing lately that my network link sometimes does not go up
> after a suspend resume cycle (roughly 1 or 2 out of 10 times). This also
> sometimes happens with a fresh boot too. Doing a manual
> "ip link set down/up" cycle resolves this issue.
>
> I was able to bisect it to the commit below (or hope so) and also CCed
> the maintainer for my driver too.
>
> This is happening on a up-to-date Arch Linux system with a Intel I219-V.
>
> Jan
>
>
>
> 7ede7b03484bbb035aa5be98c45a40cfabdc0738 is the first bad commit
> commit 7ede7b03484bbb035aa5be98c45a40cfabdc0738
> Author: Vedang Patel <vedang.patel@...el.com>
> Date:   Tue Jun 25 15:07:18 2019 -0700
>
> taprio: make clock reference conversions easier
>
> Later in this series we will need to transform from
> CLOCK_MONOTONIC (used in TCP) to the clock reference used in TAPRIO.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@...el.com>
> Signed-off-by: Vedang Patel <vedang.patel@...el.com>
> Signed-off-by: David S. Miller <davem@...emloft.net>
>
> net/sched/sch_taprio.c | 30 ++++++++++++++++++++++--------
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
>
>

That is a mechanical patch that produces no behavior change.
Furthermore, even if distributions were to build with
CONFIG_NET_SCH_TAPRIO (which there aren't many reasons to), it is
extremely likely that this qdisc is not enabled by default on your
interface. Are you voluntarily using taprio?
You might need to bisect again.

Regards,
-Vladimir