From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 9A825375AAB for ; Thu, 23 Apr 2026 13:25:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776950745; cv=none; b=RN8WyFGRG6sz5UI/D7dTuJZBDqA3lXWY79FExtgKR8FlhPGu814dUys+2RvEmuFkhiGCJBv6NuyPMlT79h23rKdgooKQdq7NWp1VfrjjGutCFZjPixt2Ai2hJWwninTJUIIhwXu4UCC1bAtcGQhaB0cqNpYtBU9W/RnTPn4bspI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776950745; c=relaxed/simple; bh=iOXfUH/WKbSJ54eCml+PUDIc87lDn2jGS2P0fNvnefg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IbwPMAINGpumyacAB9oPWRef8zA/CKWAdk1uN+m8txG7XrvTS6x3jnNVwKRIZeGqLEfgm5VdN/2AiTJ17dQ4l0xJ0FuU+jkJkpsgiCWMbP4iIdiQELnuhbL6Dxc2hpn61avpVgrh7mWO1ia6sLl6vVUBW9ajtITiJZMRBc2VgRs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IJ8PqxLx; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=gvpbjnVb; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IJ8PqxLx"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="gvpbjnVb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776950742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+/awxEPfobPlUi3oYvFkWwqE7rb6OhetiFwQnKox8Xc=; b=IJ8PqxLxzSe5tG3W5A/6HTe96crAnvz4qJxhbK5Dqe6atfqX0XyzYpxrDzDx7d4KVDaZDF Fwd1U2YTkjbk/pg0dC2TAyM13gzeCiEB9sQ4uLOKDpXGcCADre1bSb8HissPm7LZdqviyw 7MT2HkwBDua+4nT1XEI+WdHb8pGApEM= Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-112-OKy8YzRGMR2twQ-qudnd_w-1; Thu, 23 Apr 2026 09:25:41 -0400 X-MC-Unique: OKy8YzRGMR2twQ-qudnd_w-1 X-Mimecast-MFC-AGG-ID: OKy8YzRGMR2twQ-qudnd_w_1776950740 Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-c79943d2fbfso1518799a12.1 for ; Thu, 23 Apr 2026 06:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776950740; x=1777555540; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+/awxEPfobPlUi3oYvFkWwqE7rb6OhetiFwQnKox8Xc=; b=gvpbjnVbDSJTeroOANZHyALRrLwU0Kd6h/EnfAXiuDgOaloYciuVhAqLeozdaQWPt+ o0HRYMI82zgbKgA984k3qwsxSXJzO18cRSpGUiC89iw8hDzSsbJduDR7xNBXaIjoy9Xc tP8wqvaUsiMGxJ8K4H2J3cZdQrO+ws6BeuqsL/k1jZb8F298VpEHJ5aZtpBF+k6Tg/nQ kX2RaK2P1xWfsSh0m8fR1jSV+y9FgpN+EouIYD8okCymF4kVO6hgp08vxXMqc9U4clEX dAaoHd7HICw2Eim8eDaXQ4IWVm9TxgdeoBjXygaiyAavHNOIFBg4bTyRDQZn5XWit5Jw Q6Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776950740; x=1777555540; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+/awxEPfobPlUi3oYvFkWwqE7rb6OhetiFwQnKox8Xc=; b=p3cXVxtXcW/R9zvpXXVavZOCvqklFHurVDUzZKmkh30fhgZ2dnBitxwenYRhP2E11K xat75RJmWrmrvQoAK4YfRsBP8Vo15T5h+FzigtgMmAK3kVj3ozBs24kkTefKgD/79RK0 ZBCafHVug1KNsPnXw5BdDwq2zioIm/TRc5VAUtJ2IESMDd7zA+QQIYvbFjKm3nYwlj2g vYo/d83mbgxaC3H2eviN5/97icPdQWtkLuPKOtb1TRjIAuDEbO3oeezfuX1mIkdGiBFL n0JgsZpNUYWwyLg6HMFPfEva17toXN3iUlfzr6h9sbUtzfO94HA9PCdVK+AC8SFdjh4d MUWg== X-Forwarded-Encrypted: i=1; AFNElJ91cj7BqEycZSWCoIL4cmjy4hnQOG/+DtvqDDAxxMpL1ONjTVvHT5pCU4mlbaJZVGUiUxSN5F4=@vger.kernel.org X-Gm-Message-State: AOJu0YwLwE8cDRDDzsn2wydnUxo4kDBTlMdn3DbNSEgqbiasvTbgbRgR 1cfmT1zlj3x8rfqyHPy6OhPuZCxfUscKrWSVnhspmeqZtEYvTcLW8cCWebHMEjEssphwudCJqLZ naEPyaMv0IdJKPzb//MeqsBlJWEr+AbYRusyu+o6HATIfVyUX9dXWOFne1A== X-Gm-Gg: AeBDievok6bczI71WTbZWiFweD713guzqcx2IYctCbs15/t5E93xYLwl0q3lWaIG7TO RKl8yWhCadys59QWWjaV39mOomD79ulX0xZ/3UNmIVmWIDcOWSvfUmq1i2ExX5FT06snsrc5LZB tQFQClS/rfeuxeouQjPUL4kMvKSgTwDCJ2clUtzcJ0ixZ9rwVzClLm8eeUoMzASYQ3INGJrEPyR 5HWhYIWYSLTX1KA6Hxocf6qyMuiiHnMn+RhCEQ0CQYWIik9r6zHY39Wy7pG5hfBNYx33KRfVHNb lbvJPTsYkvCRw70gt/Dqs5BiYQXVV/K4s2vohzpRnyVtXkDtAmmcHzEY7I01jqPrUmP0gRJu/7z E5zqI093CCoLniMVBcBedoULA9rZVR/F3PKva5FjFkit1uKaz7BqSAF2lYHIvAK2zRY8= X-Received: by 2002:a05:6a21:9992:b0:398:7769:f869 with SMTP id adf61e73a8af0-3a08d73bff1mr29058691637.20.1776950740239; Thu, 23 Apr 2026 06:25:40 -0700 (PDT) X-Received: by 2002:a05:6a21:9992:b0:398:7769:f869 with SMTP id adf61e73a8af0-3a08d73bff1mr29058632637.20.1776950739551; Thu, 23 Apr 2026 06:25:39 -0700 (PDT) Received: from [192.168.88.32] ([150.228.93.216]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c7991ca66dasm8652747a12.26.2026.04.23.06.25.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Apr 2026 06:25:39 -0700 (PDT) Message-ID: Date: Thu, 23 Apr 2026 15:25:24 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net 4/4] gve: Make ethtool config changes synchronous To: Harshitha Ramamurthy , netdev@vger.kernel.org Cc: joshwash@google.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, willemb@google.com, maolson@google.com, nktgrg@google.com, jfraker@google.com, ziweixiao@google.com, jacob.e.keller@intel.com, pkaligineedi@google.com, shailend@google.com, jordanrhee@google.com, stable@vger.kernel.org, linux-kernel@vger.kernel.org, Pin-yen Lin References: <20260420171837.455487-1-hramamurthy@google.com> <20260420171837.455487-5-hramamurthy@google.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20260420171837.455487-5-hramamurthy@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/20/26 7:18 PM, Harshitha Ramamurthy wrote: > From: Pin-yen Lin > > When modifying device features via ethtool, the driver queues the > carrier status update to its workqueue (gve_wq). This leads to a > short link-down state after running the ethtool command. > > Use `gve_turnup_and_check_status()` instead of `gve_turnup()` in > `gve_queues_start()` to update the carrier status before returning to > the userspace. > > This was discovered by drivers/net/ping.py selftest. The test calls > ping command right after an ethtool configuration, but the interface > could be down without this fix. > > Cc: stable@vger.kernel.org > Fixes: 5f08cd3d6423 ("gve: Alloc before freeing when adjusting queues") > Reviewed-by: Joshua Washington > Signed-off-by: Pin-yen Lin > Signed-off-by: Harshitha Ramamurthy > --- > drivers/net/ethernet/google/gve/gve_main.c | 56 +++++++++++----------- > 1 file changed, 28 insertions(+), 28 deletions(-) > > diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c > index 8617782791e0..d3b4bec38de5 100644 > --- a/drivers/net/ethernet/google/gve/gve_main.c > +++ b/drivers/net/ethernet/google/gve/gve_main.c > @@ -1374,6 +1374,33 @@ static void gve_queues_mem_remove(struct gve_priv *priv) > priv->rx = NULL; > } > > +static void gve_handle_link_status(struct gve_priv *priv, bool link_status) > +{ > + if (!gve_get_napi_enabled(priv)) > + return; > + > + if (link_status == netif_carrier_ok(priv->dev)) > + return; > + > + if (link_status) { > + netdev_info(priv->dev, "Device link is up.\n"); > + netif_carrier_on(priv->dev); > + } else { > + netdev_info(priv->dev, "Device link is down.\n"); > + netif_carrier_off(priv->dev); > + } > +} > + > +static void gve_turnup_and_check_status(struct gve_priv *priv) > +{ > + u32 status; > + > + gve_turnup(priv); > + status = ioread32be(&priv->reg_bar0->device_status); > + gve_handle_link_status(priv, > + GVE_DEVICE_STATUS_LINK_STATUS_MASK & status); > +} > + > /* The passed-in queue memory is stored into priv and the queues are made live. > * No memory is allocated. Passed-in memory is freed on errors. > */ > @@ -1434,8 +1461,7 @@ static int gve_queues_start(struct gve_priv *priv, > round_jiffies(jiffies + > msecs_to_jiffies(priv->stats_report_timer_period))); > > - gve_turnup(priv); > - queue_work(priv->gve_wq, &priv->service_task); > + gve_turnup_and_check_status(priv); Sashiko says: Since gve_handle_link_status() can now be called from process context via gve_turnup_and_check_status(), while also being concurrently executed by gve_service_task() on the workqueue, could this create a time-of-check to time-of-use race? If the physical link toggles rapidly, could the workqueue thread sample the later hardware state (e.g. OFF) but see the software state is already OFF and return early, while the process context thread sampled the earlier state (e.g. ON), evaluated netif_carrier_ok() as OFF, and proceeded to call netif_carrier_on()? This might leave the software carrier state stuck ON when the most recent hardware state is OFF, because the condition check and update are no longer serialized by the workqueue. Notes that there more comments: https://sashiko.dev/#/patchset/20260420171837.455487-1-hramamurthy%40google.com but I'm not sure if they are actual regressions introduced by this series. /P