netdev - Re: 2nd RTM_NEWLINK notification with operstate down is always 1 second delayed

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]

Message-ID: <20240419093108.0fb8c108@hermes.local>
Date: Fri, 19 Apr 2024 09:31:08 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: "Tom, Deepak Abraham" <deepak-abraham.tom@....com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: 2nd RTM_NEWLINK notification with operstate down is always 1
 second delayed

On Thu, 18 Apr 2024 19:26:51 +0000
"Tom, Deepak Abraham" <deepak-abraham.tom@....com> wrote:

> Maybe I'm missing something, but could you please explain how this really helps to not keep FRR busy?
> If I understood this right, the link watch code does not ignore events but merely delays them. So any link transition will be propagated whether its scheduled urgently or not urgently.
> So FRR will have to still deal with each transition keeping it busy with or without this change, unless FRR dampens flaps on its own?
>

A poor connection to a switch can cause repeated link down/up. I haven't seen it in person,
but have had to deal with user reports of poor router connections.

> Also from a design perspective, would it be better if FRR's issues with route flaps be dealt directly in FRR code itself? That way, in use cases where FRR does not come in to play, such a delay is not causing other consequences? Are there more such situations where such a delay is absolutely required?

Too late, now. Can't change Linux semantics without breaking many things. And it impacts not just FRR.