Message ID | 20240220194244.2056384-1-jannh@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-73608-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp627662dyc; Tue, 20 Feb 2024 11:45:51 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUNptr0FIWXAdjRgP2rrK58cbebrZRSyKaJt2laOw5wM4iiRGXIgz96v56sUOU+BK5qoZfbBsYiiHs5yWNAurSIBZdNqQ== X-Google-Smtp-Source: AGHT+IGzJymrLIqK9Whd+VddP7QJtnch+soVWK6PFmdmq3ePq8cKmJSVEnrxcyTwUcaSd9evLkLD X-Received: by 2002:a05:6a20:4a94:b0:19c:955e:7100 with SMTP id fn20-20020a056a204a9400b0019c955e7100mr10495693pzb.62.1708458351334; Tue, 20 Feb 2024 11:45:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708458351; cv=pass; d=google.com; s=arc-20160816; b=TiBJr3IrLFRwvoCJdMGV9/CvaXp2h+IkQqaS+Qqj6nXrDYDWSjuWNHzHG0dsY8SBbb dbydQVXVJ5NEjR4vpAe4wEGiIWJZd4weLmr66IQHK2BkTMhNHDpRzIPrCkkQB0ZGlOUo P41xGQdvHPzRgRknhHlqLuKmzCy7PlIdcMN8YygBJv/K8y7LrrctSNXoWN9Q5x4rg0k2 hlCw12t/YLh0Gif82XL/OTNqVYc9KcVRmvIULFKa5nOgw3FpS35pu0TJfn0oW629Uah4 /Up5BKql9J15c8gE5cNS4988ZE2RWXPaUxDWNpIE/kpMvUJDGfpi2JV/y6Z5i1gbUDtd HQGg== ARC-Message-Signature: i=2; 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:message-id:date:subject:cc:to :from:dkim-signature; bh=7s18ZG9gNKC9uT7R7r7LhtOPq8sUOZ+fxeck077+80w=; fh=HSyhTcwAt4f1kmsu1zC4M9cwrZYtMYckaqK0L8P7ZQo=; b=zJzJKfX4v3ASSS1HSzZlFaUv6MK+U16gpS7Qw+Nocu/QaU5Ch/RqjbaY+QaoWGoVZx x1tMwNmOePqOVhEdZ93RchYKp5wfpleA4uXiEUeuk+jO1UhRIcYO5Ky5Ee2RiWaFwp/h 37S8f48hOP6lh/uAQwW1hZBbJCKLdyAZoXKcZmIGcMUxsCnCi24icNXul7HFuk4IA+UJ j5yv3zohgdxdZdtTpEhPSvK32FSD6RgM67eGkSH2jiDDyJCF7yr2HfFaqX9Nh8nRmcZE nF8RTwqQEuktcuf9cK6zrIgO0d8KDqWCbnT+WzJXoj7TIsy2bQtiOtLOrQEOEbaUhT3l ZF5g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=x3NUHv+Y; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-73608-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-73608-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id s10-20020a056a00194a00b006e116cb1751si6616108pfk.394.2024.02.20.11.45.50 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Feb 2024 11:45:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-73608-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=x3NUHv+Y; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-73608-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-73608-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com 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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 38D24B24E1C for <ouuuleilei@gmail.com>; Tue, 20 Feb 2024 19:43:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4C8DA12EBEC; Tue, 20 Feb 2024 19:42:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="x3NUHv+Y" Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D04336135 for <linux-kernel@vger.kernel.org>; Tue, 20 Feb 2024 19:42:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708458171; cv=none; b=gmRuT3n8D7DtMpoauk4Z4RoigA2nuyGAVpDm0TN6CnXv9IqhxZvxECkD+tGVZR5St754G7mFEVEwJDOf1hPSN2kpY6Tb/X01DU65DvpjcYYOXefBb69a8jDMDpVvHdmiRKBhtfZWbBXrmH7FXREvXKtxlyelFpbMh8o86f1EnyI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708458171; c=relaxed/simple; bh=QWkFrEkzqGLs/fYUGukOscI15ZpBZW3mTKO1W6b7TVM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RC8nLJRYp6lnm5RtmHfAz1QyagMyHxB0IvbdMhqGqdcexuAkXTxkQtmA+8nQEO9JrnOnagd9H79U77cVbli7QSX73nZyhtR6riXcXPvRr2ZAcW7p1S3bbRZylYGHCdlhSM2eOlh4lEvYjsvDo4PrdOAfCqm+7R5oDiEYCT6uf2Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=x3NUHv+Y; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-411d9e901dcso14785e9.1 for <linux-kernel@vger.kernel.org>; Tue, 20 Feb 2024 11:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708458167; x=1709062967; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=7s18ZG9gNKC9uT7R7r7LhtOPq8sUOZ+fxeck077+80w=; b=x3NUHv+YiGbITA9O44l/u70MINCo6vTef9MgMy7kqc1B5JCVOlcbTBYKvGoqQzQwak K5mjS+y3HWWP3S34bqtM3/B2jh8TtzbvF+yHVOkJZ4h3N0ojzxLmKInlvnslRhLz3IvY 2KQGq5MYLWRJmqnQI6V+L/OG+eY51T3zg9t5NqhjR4G0tzxd6eMnHgBzeP6Pd5s5pRhp 6a/NgH3yRw51PIKBcEIYL88En2cDojMKZx8TGJRKKVIVB/S3i3KRENnil1RflsMGSTpF 6v/fc+6t6oldy1EiAOqtwmhuAMUHJAvegspK1ir0tEAbogX+zOor8Qo+X77Ps3fWOK/V BRoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708458167; x=1709062967; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7s18ZG9gNKC9uT7R7r7LhtOPq8sUOZ+fxeck077+80w=; b=ejqpj01+pfXLySS4+uLFeWFtzu4+Rb/FZeJIs/fHxaMQLdWbdMCPfKtGRB3XaS88WB iJpRkY6GapyRw9tye4uI/y/USvCcLe/7ytZAfngRRLIsWbo9ZYWKFyVpyMPuevbP4Gez rqJV3AtTTvwoet9fipsfisc7NzjgtQSO1w93P/+D2+BpHcqCJyPMCKNxvMJfSuGrDw2Y i+GGUasYqfj/4zF9e7g/CwdtGSk+tjO9HTsMRkNCt/viCNXk0BQ7mC8mcq4+P0yTQItt wKkqLP1N/VgF6H0yCLVlfNVH4hu7qfv6BOIv1h7osgW4Gh/1Q0Bz4u/3/cckmG6t0fFT GmGQ== X-Forwarded-Encrypted: i=1; AJvYcCWZ2IJU5x19YmWIRryOfdXQwdsfTyFDVmqf3SBw1rFVnu3VRj/94HkJQAygR6Ll1kCB3W1aDWmQ+0Dko7JH7Zv0byTX+uSsJN6pq5i0 X-Gm-Message-State: AOJu0YxHUth3eMRPclLyFGKurb9fmH9v2ov9z67V8CecVEUbsG9n73Nu +N7PFW2+sF3f21p0FAGFQzty303myY+FFjFm5C0t/JChuZVvihMQ91jVFxQO0A== X-Received: by 2002:a05:600c:1e20:b0:412:730e:5a82 with SMTP id ay32-20020a05600c1e2000b00412730e5a82mr6425wmb.1.1708458166723; Tue, 20 Feb 2024 11:42:46 -0800 (PST) Received: from localhost ([2a02:168:96c5:1:cba0:1b55:6833:859e]) by smtp.gmail.com with ESMTPSA id p17-20020a05600c469100b004120b4c57c9sm15840571wmo.4.2024.02.20.11.42.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Feb 2024 11:42:46 -0800 (PST) From: Jann Horn <jannh@google.com> To: "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Jann Horn <jannh@google.com> Subject: [PATCH] net: ethtool: avoid rebuilds on UTS_RELEASE change Date: Tue, 20 Feb 2024 20:42:44 +0100 Message-ID: <20240220194244.2056384-1-jannh@google.com> X-Mailer: git-send-email 2.44.0.rc0.258.g7320e95886-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791448424071829092 X-GMAIL-MSGID: 1791448424071829092 |
Series |
net: ethtool: avoid rebuilds on UTS_RELEASE change
|
|
Commit Message
Jann Horn
Feb. 20, 2024, 7:42 p.m. UTC
Currently, when you switch between branches or something like that and
rebuild, net/ethtool/ioctl.c has to be built again because it depends
on UTS_RELEASE.
By instead referencing a string variable stored in another object file,
this can be avoided.
Signed-off-by: Jann Horn <jannh@google.com>
---
(alternatively we could also use the utsname info from the current UTS
namespace, but that'd be a bit of a behavior change, and I wanted to
keep this change a no-op)
net/ethtool/ioctl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Comments
On Tue, 20 Feb 2024 20:42:44 +0100 Jann Horn wrote: > Currently, when you switch between branches or something like that and > rebuild, net/ethtool/ioctl.c has to be built again because it depends > on UTS_RELEASE. > > By instead referencing a string variable stored in another object file, > this can be avoided. > > Signed-off-by: Jann Horn <jannh@google.com> > --- > (alternatively we could also use the utsname info from the current UTS > namespace, but that'd be a bit of a behavior change, and I wanted to > keep this change a no-op) Is this related to John's work from: https://lore.kernel.org/all/20240131104851.2311358-1-john.g.garry@oracle.com/ ?
On Wed, Feb 21, 2024 at 8:23 PM Jakub Kicinski <kuba@kernel.org> wrote: > > On Tue, 20 Feb 2024 20:42:44 +0100 Jann Horn wrote: > > Currently, when you switch between branches or something like that and > > rebuild, net/ethtool/ioctl.c has to be built again because it depends > > on UTS_RELEASE. > > > > By instead referencing a string variable stored in another object file, > > this can be avoided. > > > > Signed-off-by: Jann Horn <jannh@google.com> > > --- > > (alternatively we could also use the utsname info from the current UTS > > namespace, but that'd be a bit of a behavior change, and I wanted to > > keep this change a no-op) > > Is this related to John's work from: > https://lore.kernel.org/all/20240131104851.2311358-1-john.g.garry@oracle.com/ > ? Ah, I didn't see his patch, but that seems like he had the same idea (but implemented it less sloppily). You can drop this one then...
On Wed, 21 Feb 2024 20:25:00 +0100 Jann Horn wrote: > > Is this related to John's work from: > > https://lore.kernel.org/all/20240131104851.2311358-1-john.g.garry@oracle.com/ > > ? > > Ah, I didn't see his patch, but that seems like he had the same idea > (but implemented it less sloppily). You can drop this one then... No preference on my side, just wanted to make sure we don't have to decide within netdev which approach is better, not really our wheelhouse :)
On 21/02/2024 19:35, Jakub Kicinski wrote: Thanks for including me > On Wed, 21 Feb 2024 20:25:00 +0100 Jann Horn wrote: >>> Is this related to John's work from: >>> https://urldefense.com/v3/__https://lore.kernel.org/all/20240131104851.2311358-1-john.g.garry@oracle.com/__;!!ACWV5N9M2RV99hQ!IghWg9_5HEQ-ng1XiYH9hes6vmgylmcQF5l2RITIrCSB20BzKzOhWWKHrgQZw_DkgKlZRNllglTanuY$ >>> ? >> >> Ah, I didn't see his patch, but that seems like he had the same idea >> (but implemented it less sloppily). You can drop this one then... > > No preference on my side, just wanted to make sure we don't have > to decide within netdev which approach is better, not really our > wheelhouse :) I was not going to pursue the change to introduce uts_release, as we can instead use init_uts_ns.name.release or init_utsname()->release instead. I think that init_utsname()->release is a bit neater to use, as it slightly hides the init_uts_ns structure. @Jann, please feel free to pursue upstreaming the change in this patch with: Reviewed-by: John Garry <john.g.garry@oracle.com> However, note that I do have many other changes pending on this subject, see: https://github.com/johnpgarry/linux/commits/uts-version-string/ I just need to find a bit of time to update and post them. We also need to be wary of CONFIG_MODVERSIONS, as discussed in that thread. Thanks, John
Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Tue, 20 Feb 2024 20:42:44 +0100 you wrote: > Currently, when you switch between branches or something like that and > rebuild, net/ethtool/ioctl.c has to be built again because it depends > on UTS_RELEASE. > > By instead referencing a string variable stored in another object file, > this can be avoided. > > [...] Here is the summary with links: - net: ethtool: avoid rebuilds on UTS_RELEASE change https://git.kernel.org/netdev/net-next/c/d2efeb52c344 You are awesome, thank you!
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index 7519b0818b91..575642b3070e 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -26,12 +26,12 @@ #include <linux/sched/signal.h> #include <linux/net.h> #include <linux/pm_runtime.h> +#include <linux/utsname.h> #include <net/devlink.h> #include <net/ipv6.h> #include <net/xdp_sock_drv.h> #include <net/flow_offload.h> #include <linux/ethtool_netlink.h> -#include <generated/utsrelease.h> #include "common.h" /* State held across locks and calls for commands which have devlink fallback */ @@ -713,7 +713,8 @@ ethtool_get_drvinfo(struct net_device *dev, struct ethtool_devlink_compat *rsp) struct device *parent = dev->dev.parent; rsp->info.cmd = ETHTOOL_GDRVINFO; - strscpy(rsp->info.version, UTS_RELEASE, sizeof(rsp->info.version)); + strscpy(rsp->info.version, init_uts_ns.name.release, + sizeof(rsp->info.version)); if (ops->get_drvinfo) { ops->get_drvinfo(dev, &rsp->info); if (!rsp->info.bus_info[0] && parent)