From: John Garry <john.g.garry@oracle.com>
To: mcgrof@kernel.org, russ.weight@linux.dev,
gregkh@linuxfoundation.org, rafael@kernel.org
Cc: linux-kernel@vger.kernel.org, masahiroy@kernel.org,
John Garry <john.g.garry@oracle.com>
Subject: [PATCH] firmware_loader: Use init_utsname()->release
Date: Thu, 22 Feb 2024 14:58:19 +0000 [thread overview]
Message-ID: <20240222145819.96646-1-john.g.garry@oracle.com> (raw)
Instead of using UTS_RELEASE, use init_utsname()->release, which means
that we don't need to rebuild the code just for the git head commit
changing.
Since UTS_RELEASE is used for fw_path[] and this points to const data,
append init_utsname()->release dynamically to an intermediate string.
The check for appending uts release is if the string in fw_path[] ends
in '/'. Since fw_path[] may include a path from the kernel command line
in fw_path_para, and it would be valid for this string to end in '/',
check for fw_path_para when appending uts release.
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
Note: As mentioned by Masahiro in [0], when CONFIG_MODVERSIONS=y it
could be possible for a driver to be built as a module with a different
kernel baseline and so use a different UTS_RELEASE from the baseline. So
now using init_utsname()->release could lead to a change in behaviour
in this driver. However, considering the nature of this driver and how it
would not make sense to build as module against a different tree, this
change should be ok.
[0] https://lore.kernel.org/lkml/CAK7LNAQ_r5yUjNpOppLkDBQ12sDxBYQTvRZGn1ng8D1POfZr_A@mail.gmail.com/
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index 3c67f24785fc..9a3671659134 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -38,7 +38,7 @@
#include <linux/zstd.h>
#include <linux/xz.h>
-#include <generated/utsrelease.h>
+#include <linux/utsname.h>
#include "../base.h"
#include "firmware.h"
@@ -471,9 +471,9 @@ static int fw_decompress_xz(struct device *dev, struct fw_priv *fw_priv,
static char fw_path_para[256];
static const char * const fw_path[] = {
fw_path_para,
- "/lib/firmware/updates/" UTS_RELEASE,
+ "/lib/firmware/updates/", /* UTS_RELEASE is appended later */
"/lib/firmware/updates",
- "/lib/firmware/" UTS_RELEASE,
+ "/lib/firmware/", /* UTS_RELEASE is appended later */
"/lib/firmware"
};
@@ -496,7 +496,7 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
size_t size;
int i, len, maxlen = 0;
int rc = -ENOENT;
- char *path, *nt = NULL;
+ char *path, *fw_path_string, *nt = NULL;
size_t msize = INT_MAX;
void *buffer = NULL;
dev_err(device, "%s suffix=%s\n", __func__, suffix);
@@ -511,6 +511,12 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
if (!path)
return -ENOMEM;
+ fw_path_string = __getname();
+ if (!fw_path_string) {
+ __putname(path);
+ return -ENOMEM;
+ }
+
wait_for_initramfs();
for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
size_t file_size = 0;
@@ -521,16 +527,32 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
if (!fw_path[i][0])
continue;
+ len = snprintf(fw_path_string, PATH_MAX, "%s", fw_path[i]);
+ if (len >= PATH_MAX) {
+ rc = -ENAMETOOLONG;
+ break;
+ }
+
+ /* Special handling to append UTS_RELEASE */
+ if ((fw_path[i] != fw_path_para) && (fw_path[i][len - 1] == '/')) {
+ len = snprintf(fw_path_string, PATH_MAX, "%s%s",
+ fw_path[i], init_utsname()->release);
+ if (len >= PATH_MAX) {
+ rc = -ENAMETOOLONG;
+ break;
+ }
+ }
+
/* strip off \n from customized path */
- maxlen = strlen(fw_path[i]);
+ maxlen = strlen(fw_path_string);
if (i == 0) {
- nt = strchr(fw_path[i], '\n');
+ nt = strchr(fw_path_string, '\n');
if (nt)
- maxlen = nt - fw_path[i];
+ maxlen = nt - fw_path_string;
}
len = snprintf(path, PATH_MAX, "%.*s/%s%s",
- maxlen, fw_path[i],
+ maxlen, fw_path_string,
fw_priv->fw_name, suffix);
if (len >= PATH_MAX) {
rc = -ENAMETOOLONG;
@@ -588,6 +610,7 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
break;
}
__putname(path);
+ __putname(fw_path_string);
return rc;
}
--
2.31.1
next reply other threads:[~2024-02-22 14:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 14:58 John Garry [this message]
2024-02-22 15:53 ` Luis Chamberlain
2024-02-23 14:29 ` John Garry
2024-02-23 15:34 ` John Garry
2024-02-26 16:34 ` Luis Chamberlain
2024-02-26 17:10 ` Luis Chamberlain
2024-02-26 17:13 ` John Garry
2024-02-27 12:59 ` Luis Chamberlain
2024-02-27 13:02 ` John Garry
2024-02-27 13:50 ` Luis Chamberlain
2024-02-27 13:53 ` Luis Chamberlain
2024-02-28 12:31 ` John Garry
2024-02-28 15:18 ` Luis Chamberlain
2024-02-28 16:12 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240222145819.96646-1-john.g.garry@oracle.com \
--to=john.g.garry@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®