Received: by 2002:a05:7412:b10a:b0:f3:1519:9f41 with SMTP id az10csp1826337rdb; Sat, 2 Dec 2023 10:47:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IE+TyiZGT4b7iYB8Eg55Rj7wQ5ssQAf3WodRxtviE70Vfd2i9lUVjM/ENf6v6BFN6vmVd5W X-Received: by 2002:a05:600c:5247:b0:40b:5e59:99a8 with SMTP id fc7-20020a05600c524700b0040b5e5999a8mr852784wmb.200.1701542821984; Sat, 02 Dec 2023 10:47:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701542821; cv=none; d=google.com; s=arc-20160816; b=BOUgokZgr5b+k+MwtdZOSQjdbUdy+ridXmAtA/VYXfNDS2wUhNoymN6eC5EGPsdO9L KB0IS5hu770Bgusa/dxMt4ybTBMAwaT1pDpDFxOkWO0dMRRvEpY3EuKwX10RmZqOeCrH F1vlCmQUEnfOT4r6u/lY2UwUQjOyFVDnPRZUoHXMIFWYO2tMGAppXGzMineGdYnYVmXA jNNPH3CDvMNkLkakwgUEtXnnjAucmUXeLgEy9zc4bVXR3pgGfBXMzq5by+k6XtMO3aDL PBXehsPCjA8crzxKwBJ7mP2wz3RO0b9tOId/lW1ZyTy8+LQx3SgR2vQQ43GoHtBd6HBn sLlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=sMKHjFddA59Fu2tCjQihJ8nxGlVMYdkQdMimk4CM++8=; fh=wF9sg2YKRy/mhluOpUwroQPBxl99MdbRccr9km/XeIg=; b=BklMp9YVKXmwKhG9d5dq2GjzMgKO9jBkvOR4DMy53nSmOhy5HIo2BO5fSrjeu3Vw4J 2AMxBMxchYWmmcWOT2Rb6vf8XxiLj+kSex+gLuZNnX/sh/XSqqLx39aDaPZH7BWZujGi r3e8pFHiJ79rpohFbq9a2GZhFGSAEFnxlYtOdaBtBtzye4HF8oAf19kCHRKMmQg4Ms7G XJO8THSDs+rNqEqXBuyPFYXFiNzll3QQu04Gx6WFLzKTsjV9Q0QS7G1CRwJDan1/Oagv NM8zpp7Ad+/O7iTjHBXZvP+TPpk1o8X1JWtrZeVknEezS7Y/18bNRe9OT/RfE2Hv0S5m LEoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NDRYe9Ec; spf=pass (google.com: domain of linux-wireless+bounces-332-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-wireless+bounces-332-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id b15-20020a056402084f00b0052eb0939c82si2944903edz.618.2023.12.02.10.47.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 10:47:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless+bounces-332-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NDRYe9Ec; spf=pass (google.com: domain of linux-wireless+bounces-332-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-wireless+bounces-332-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id AAA3B1F21008 for ; Sat, 2 Dec 2023 18:47:01 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 619D08833; Sat, 2 Dec 2023 18:46:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NDRYe9Ec" X-Original-To: linux-wireless@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 408322F3E; Sat, 2 Dec 2023 18:46:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BD5EC433C7; Sat, 2 Dec 2023 18:46:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701542816; bh=Rgi3ddaSq/HnZV4GLA+Aa7G8rUV64eKojW6PMPBNtlE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NDRYe9EcyY7hvm5QXWy+l2EWvYbBCj/Tqx08098S/0f8IFTnSYllNmnPhOI1twK8i roGybv/M+fJk5vg0Nvr8vx5t6eCFNqeVb8jRtvAYXBtxligNPo5pk9jcyDHkSzRMG0 dJb1t51kj3qsBQc1NtEpeAWzv5pf1ZZtuRROopMUBvFiwyWYJLhHEmr7c8a+N6Ecot neh8uVaH4V4z/ul/8nNp1PTkRSfeqnC68KB3l7am/fwIDmxHooSnh6jZlUHQdno8e+ T1FtyAU4V/4O+4do9ly+ppNIVniyDdED1Pzu7GinmiLaIlda8LKeKRfhvW4JCMp35v Qw8C9pVLoviEQ== Date: Sat, 2 Dec 2023 10:46:55 -0800 From: Jakub Kicinski To: Johannes Berg Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH wireless-next 0/3] netlink carrier race workaround Message-ID: <20231202104655.68138ab4@kernel.org> In-Reply-To: <339c73a6318bf94803a821d5e8ea7d4c736dc78e.camel@sipsolutions.net> References: <346b21d87c69f817ea3c37caceb34f1f56255884.camel@sipsolutions.net> <20231201104329.25898-5-johannes@sipsolutions.net> <20231201162844.14d1bbb0@kernel.org> <339c73a6318bf94803a821d5e8ea7d4c736dc78e.camel@sipsolutions.net> Precedence: bulk X-Mailing-List: linux-wireless@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 02 Dec 2023 11:06:36 +0100 Johannes Berg wrote: > > Would it work if we exposed "linkwatch is pending" / "link is > > transitioning" bit to user space? > > Not sure, not by much or more than what this did? It's basically the > same, I think: I exposed the carrier_up_count at the kernel time, so if > userspace hasn't seen an event with a value >= that it knows the link is > transitioning. The benefit being that it'd work for everyone, without having to add the carrier count in random events? > > Even crazier, would it help if we had rtnl_getlink() run > > linkwatch for the target link if linkwatch is pending? > > Sure, if we were to just synchronize that at the right time (doesn't > even need to be rtnl_getlink, could be a new operation) that'd solve the > issue too, perhaps more easily. I was wondering about the new op, too, but "synchronize things please" op feels a little hacky. rtnl_getlink returns link state, so it feels somewhat natural for it to do the sync, to make sure that what it returns is in fact correct information. No strong feelings, tho. rtnl_getlink does return a lot, so maybe a new rtnl_getcarrier op? Or we can make reading sysfs "carrier" do the sync?