From: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com>
commit b89b41d0b8414690ec0030c134b8bde209e6d06c upstream
Current cpu_core_id fixup causes downcored F17h configurations to be
incorrect:
NODE: 0
processor 0 core id : 0
processor 1 core id : 1
processor 2 core id : 2
processor 3 core id : 4
processor 4 core id : 5
processor 5 core id : 0
NODE: 1
processor 6 core id : 2
processor 7 core id : 3
processor 8 core id : 4
processor 9 core id : 0
processor 10 core id : 1
processor 11 core id : 2
Code that relies on the cpu_core_id, like match_smt(), for example,
which builds the thread siblings masks used by the scheduler, is
mislead.
So, limit the fixup to pre-F17h machines. The new value for cpu_core_id
for F17h and later will represent the CPUID_Fn8000001E_EBX[CoreId],
which is guaranteed to be unique for each core within a socket.
This way we have:
NODE: 0
processor 0 core id : 0
processor 1 core id : 1
processor 2 core id : 2
processor 3 core id : 4
processor 4 core id : 5
processor 5 core id : 6
NODE: 1
processor 6 core id : 8
processor 7 core id : 9
processor 8 core id : 10
processor 9 core id : 12
processor 10 core id : 13
processor 11 core id : 14
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com>
[ Heavily massaged. ]
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Yazen Ghannam <Yazen.Ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20170731085159.9455-2-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
---
arch/x86/kernel/cpu/amd.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 6de596449488..e864ff6cd8bd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -305,6 +305,22 @@ static void amd_get_topology_early(struct cpuinfo_x86 *c)
}
/*
+ * Fix up cpu_core_id for pre-F17h systems to be in the
+ * [0 .. cores_per_node - 1] range. Not really needed but
+ * kept so as not to break existing setups.
+ */
+static void legacy_fixup_core_id(struct cpuinfo_x86 *c)
+{
+ u32 cus_per_node;
+
+ if (c->x86 >= 0x17)
+ return;
+
+ cus_per_node = c->x86_max_cores / nodes_per_socket;
+ c->cpu_core_id %= cus_per_node;
+}
+
+/*
* Fixup core topology information for
* (1) AMD multi-node processors
* Assumption: Number of cores in each internal node is the same.
@@ -359,15 +375,9 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
} else
return;
- /* fixup multi-node processor information */
if (nodes_per_socket > 1) {
- u32 cus_per_node;
-
set_cpu_cap(c, X86_FEATURE_AMD_DCM);
- cus_per_node = c->x86_max_cores / nodes_per_socket;
-
- /* core id has to be in the [0 .. cores_per_node - 1] range */
- c->cpu_core_id %= cus_per_node;
+ legacy_fixup_core_id(c);
}
}
#endif
--
2.7.4
The commit 8844618d8aa7 ("ext4: only look at the bg_flags field if it
is valid") introduced an issue which are seeing when running "adb
remount" on Android devices with the affected kernels. This change
appears on 4.4.y and later.
> EXT4-fs error (device vdd): ext4_has_uninit_itable:2882: comm remount svc 50: Inode table for bg 0 marked as needing zeroing
> Kernel panic - not syncing: EXT4-fs (device vdd): panic forced after error
Looks like this fix was already picked up for 4.14.y, 4.17.y but
(AFAIK) it isn't on anybody's radar for 4.4 and 4.9. Thanks!
The patch titled
Subject: drivers/block/zram/zram_drv.c: fix bug storing backing_dev
has been added to the -mm tree. Its filename is
zram-fix-bug-storing-backing_dev.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/zram-fix-bug-storing-backing_dev.p…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/zram-fix-bug-storing-backing_dev.p…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Peter Kalauskas <peskal(a)google.com>
Subject: drivers/block/zram/zram_drv.c: fix bug storing backing_dev
The call to strlcpy in backing_dev_store is incorrect. It should take
the size of the destination buffer instead of the size of the source
buffer. Additionally, ignore the newline character (\n) when reading
the new file_name buffer. This makes it possible to set the backing_dev
as follows:
echo /dev/sdX > /sys/block/zram0/backing_dev
The reason it worked before was the fact that strlcpy() copies 'len - 1'
bytes, which is strlen(buf) - 1 in our case, so it accidentally didn't
copy the trailing new line symbol. Which also means that "echo -n
/dev/sdX" most likely was broken.
Signed-off-by: Peter Kalauskas <peskal(a)google.com>
Link: http://lkml.kernel.org/r/20180813061623.GC64836@rodete-desktop-imager.corp.…
Acked-by: Minchan Kim <minchan(a)kernel.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/block/zram/zram_drv.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/block/zram/zram_drv.c~zram-fix-bug-storing-backing_dev
+++ a/drivers/block/zram/zram_drv.c
@@ -337,6 +337,7 @@ static ssize_t backing_dev_store(struct
struct device_attribute *attr, const char *buf, size_t len)
{
char *file_name;
+ size_t sz;
struct file *backing_dev = NULL;
struct inode *inode;
struct address_space *mapping;
@@ -357,7 +358,11 @@ static ssize_t backing_dev_store(struct
goto out;
}
- strlcpy(file_name, buf, len);
+ strlcpy(file_name, buf, PATH_MAX);
+ /* ignore trailing newline */
+ sz = strlen(file_name);
+ if (sz > 0 && file_name[sz - 1] == '\n')
+ file_name[sz - 1] = 0x00;
backing_dev = filp_open(file_name, O_RDWR|O_LARGEFILE, 0);
if (IS_ERR(backing_dev)) {
_
Patches currently in -mm which might be from peskal(a)google.com are
zram-fix-bug-storing-backing_dev.patch
These patches are needed for kasan+clang support. I confirmed they
apply cleanly in order (top to bottom):
4.9:
commit c5caf21ab0cf8 ("kasan: turn on -fsanitize-address-use-after-scope")
commit 0e410e158e5b ("kasan: don't emit builtin calls when sanitization is off")
4.4:
commit c5caf21ab0cf8 ("kasan: turn on -fsanitize-address-use-after-scope")
===
0e410e158e5b is the one I'm interested in. Looks like it landed in
4.16, and got backported to 4.14-stable.
===
c5caf21ab0cf8 depends on c6d308534aef6 ("UBSAN: run-time undefined
behavior sanity checker"), and I don't want to bring in all of UBSAN
to 4.4. I'll send a patch for 0e410e158e5b.
--
Thanks,
~Nick Desaulniers
The function has an inline "return false;" definition with CONFIG_SMP=n but the
"real" definition is also visible leading to "redefinition of
‘apic_id_is_primary_thread’" compiler error. Guard it with #ifdef CONFIG_SMP
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Fixes: 6a4d2657e048 ("x86/smp: Provide topology_is_primary_thread()")
Cc: stable(a)vger.kernel.org
---
arch/x86/kernel/apic/apic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 87ff6235bbfe..84132eddb5a8 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2193,6 +2193,7 @@ static int cpuid_to_apicid[] = {
[0 ... NR_CPUS - 1] = -1,
};
+#ifdef CONFIG_SMP
/**
* apic_id_is_primary_thread - Check whether APIC ID belongs to a primary thread
* @id: APIC ID to check
@@ -2207,6 +2208,7 @@ bool apic_id_is_primary_thread(unsigned int apicid)
mask = (1U << (fls(smp_num_siblings) - 1)) - 1;
return !(apicid & mask);
}
+#endif
/*
* Should use this API to allocate logical CPU IDs to keep nr_logical_cpuids
--
2.18.0