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 9A8B63E1218 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-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-76-r7UPiAGtNyS7Fer5X-Fg8g-1; Thu, 23 Apr 2026 09:25:41 -0400 X-MC-Unique: r7UPiAGtNyS7Fer5X-Fg8g-1 X-Mimecast-MFC-AGG-ID: r7UPiAGtNyS7Fer5X-Fg8g_1776950740 Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-b630b4d8d52so3798936a12.3 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=Ml2oWkPpmc8DLG8zCvrJLGRO4HfsmcCZwmu3GwqCPoK/F1srbKkixweaYbZJnbmDMu e/PydkaVfe+NawL1LmEtQ8K+NE2ggy0R3sOevcylZ1MorKavoQyihEFe4GpUkMVLYGtg rKogtFKWpagLwv5fg5Cf6egGKTYxGQFaKHKu1ozpHvxOwIlELybElixLVujeVG8NGpT7 ROyzUWhI7sFtdWC8MJ7eIHPasuq1CNYipeWGYVQZ+mzqMMPBIIVgxJJZwVVMyd1h5vLZ E2d2D4zMo34bf8YJ++b2XzTu1mrWeYy/dPSS4xb9gMvSYu12bJBeoDUJGInYDyhJ/8Dy j2YA== X-Forwarded-Encrypted: i=1; AFNElJ+biuwl0kc1QWhcKhhkW77GQcEgx6FROSbTeCnxGmvVnfxk4v12VEPcFWl5CR9U/AIoQogWqEUoXZCmEek=@vger.kernel.org X-Gm-Message-State: AOJu0YzP3w06///uegLua+WTl3YEUaYWgSw+UlDc1p6HX9MvI0R1S+uA i0GZt5rKt/e0auZDPrNP7VhsY0oQfEikQODWQS0G65XRoc64tHl8YO0oRVRarlZjcIHVY4qO3i1 gczAWX+tmcD/vju8al+SoMouRQD4Rdf3UglqEseHUWc5sa4z1RVo4smlxU2j1LsipDg== X-Gm-Gg: AeBDiesbyxs1I1D7Q5IW2yjxEC/uN7HpJeoRra7AH6RmmFRkjeLOqAiZZfaMviMnZsX RnbfA5M1CywR2SFJ5jzan6KgbknHJtcV0IbkwPiR7pQrCRjNumsww63ro6qmOyQm0ezUwH2GASm +Un6ltWscWTHc7V0qYRqDfsT3IeLfmaMpF391SOapyvQ5BAdDPynzvtby5QpGs0a5KCs+cBLW89 soSYdFstzdAOEuRooS+q25rx53U9vU0t3BhqyMcBCIIP66VTqonIqWP3nrssEMT2EwR5/hNSOWo W1p7lTdY+m5X+XpRacWSigpsSBsba+98lPv/oxalVKzON+h6E0DV4RPGgr+jW/93dXwgT7+D8lN r9ovBxTVtt0TIhZlxt9RFIKZ0gr344zRipOl9DSi5pM2oYNc4i9CA9GhcV/CIPR7n+Tc= X-Received: by 2002:a05:6a21:9992:b0:398:7769:f869 with SMTP id adf61e73a8af0-3a08d73bff1mr29058684637.20.1776950740231; 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: linux-kernel@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