netdev - Re: [PATCH wireless-next 0/3] netlink carrier race workaround

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, 4 Dec 2023 08:23:54 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH wireless-next 0/3] netlink carrier race workaround

On Sun, 03 Dec 2023 19:51:28 +0100 Johannes Berg wrote:
> I think I wouldn't mind now, and perhaps if we want to sync in netlink
> we should also do this here so that it's consistent, but I'm not sure
> I'd want this to be the only way to do it, I might imagine that someone
> might want this in some kind of container that doesn't necessarily have
> (full) access there? Dunno.

Also dunno :) We can add a "sync" version of netif_carrier_ok()
and then call if from whatever places we need.

> We _could_ also use an input attribute on the rtnl_getlink() call to
> have userspace explicitly opt in to doing the sync before returning
> information?

Yeah, maybe.. IMHO a more "Rusty Russell API levels" thing to do would
be to allow opting out, as those who set the magic flag "know what they
are doing" and returning unsync'ed carrier may be surprising.
Also a "don't sync flag" we can add later, once someone who actually
cares appears, avoiding uAPI growth 😁️

Anyway, up to you :)