From: Michael Schaller <misch(a)google.com>
commit 336af6a4686d885a067ecea8c3c3dd129ba4fc75 upstream
Without this patch efivarfs_alloc_dentry creates dentries with slashes in
their name if the respective EFI variable has slashes in its name. This in
turn causes EIO on getdents64, which prevents a complete directory listing
of /sys/firmware/efi/efivars/.
This patch replaces the invalid shlashes with exclamation marks like
kobject_set_name_vargs does for /sys/firmware/efi/vars/ to have consistently
named dentries under /sys/firmware/efi/vars/ and /sys/firmware/efi/efivars/.
Signed-off-by: Michael Schaller <misch(a)google.com>
Link: https://lore.kernel.org/r/20200925074502.150448-1-misch@google.com
Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org>
---
This addresses an issue that breaks Ubuntu installs on platforms that have
variable names as described above. One of our installers needs to sort
the BootOrder to keep BootCurrent at the front, but this fails when the
variable BootCurrent points at appears to not exist due to this issue.
Ref: https://bugs.launchpad.net/bugs/1899993
fs/efivarfs/super.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index 28bb5689333a..15880a68faad 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -141,6 +141,9 @@ static int efivarfs_callback(efi_char16_t *name16, efi_guid_t vendor,
name[len + EFI_VARIABLE_GUID_LEN+1] = '\0';
+ /* replace invalid slashes like kobject_set_name_vargs does for /sys/firmware/efi/vars. */
+ strreplace(name, '/', '!');
+
inode = efivarfs_get_inode(sb, d_inode(root), S_IFREG | 0644, 0,
is_removable);
if (!inode)
--
2.29.1
Hi-
This commit from v4.4.241 breaks the v4.4.y build for powerpc:
217f139551c0 powerpc/powernv/dump: Fix race while processing OPAL dump
Like this:
.../arch/powerpc/platforms/powernv/opal-dump.c:409:7: error: void value not ignored as it ought to be
dump = create_dump_obj(dump_id, dump_size, dump_type);
^
The commit descriptions says:
"... the return value of create_dump_obj() function isn't being used today ..."
But that's only true for kernels >= v4.19, because they carry this commit:
b29336c0e178 powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler
In v4.4 process_dump(), the only caller of create_dump_obj(), still tries to
use the return value (see the error above).
Applying "b29336c0e178 powerpc/powernv/opal-dump : Use IRQ_HANDLED ..." to
v4.4.y fixes the problem.
-Kamal