Received-SPF: pass (google.com: domain of linux-wireless+bounces-383-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Mon, 4 Dec 2023 08:23:54 -0800
From: Jakub Kicinski <kuba@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH wireless-next 0/3] netlink carrier race workaround
Message-ID: <20231204082354.78122161@kernel.org>
In-Reply-To: <efd89dee78a4c42b7825fa55bbceafad9bb9df36.camel@sipsolutions.net>
References: <346b21d87c69f817ea3c37caceb34f1f56255884.camel@sipsolutions.net>
	<20231201104329.25898-5-johannes@sipsolutions.net>
	<20231201162844.14d1bbb0@kernel.org>
	<339c73a6318bf94803a821d5e8ea7d4c736dc78e.camel@sipsolutions.net>
	<20231202104655.68138ab4@kernel.org>
	<efd89dee78a4c42b7825fa55bbceafad9bb9df36.camel@sipsolutions.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =F0=9F=98=81=EF=B8=8F

Anyway, up to you :)