* pci memory resources not being assigned to bridge
From: Chris Packham @ 2019-07-04 5:11 UTC (permalink / raw)
To: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Hi,
I'm in the process of updating our products from a 4.4 based kernel to
5.1 (and probably 5.2 since that release is imminent).
On one product which uses a Freescale/NXP P2041 CPU, IDT pcie bridge and
Marvell switch chip[1].
Annoyingly the hardware has a reset line that holds the switch chip in
reset but the bridge chip has a separate reset line that is not held
high by default. So when the system starts up the initial scan sees the
bridge and assigns resource to its end points. Later once the switch
chip reset is released (either via a gpio-hog or manually) and the bus
rescanned the switch devices are detected but the host side of the pci
bridge isn't assigned any memory space so pci accesses trigger a master
abort which on that SoC leads to a machine check exception.
[root@linuxbox ~]# uname -a
Linux linuxbox 5.2.0-rc7-at1+ #8 SMP Thu Jul 4 04:26:18 UTC 2019 ppc
GNU/Linu[root@linuxbox ~]# lspci -t
-+-[2000:00]---00.0-[01-06]----00.0-[02-06]--+-02.0-[03]--
| +-03.0-[04]--
| +-04.0-[05]--
| \-05.0-[06]--
\-[0000:00]-
[root@linuxbox ~]# lspci -v -s 2000:01:00
2000:01:00.0 Class 0604: Device 111d:803e (rev 0e)
Flags: bus master, fast devsel, latency 0
Bus: primary=01, secondary=02, subordinate=06, sec-latency=0
I/O behind bridge: None
Memory behind bridge: None
Prefetchable memory behind bridge: None
Capabilities: [40] Express Upstream Port, MSI 00
Capabilities: [c0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [200] Virtual Channel
Kernel driver in use: pcieport
[root@linuxbox ~]# echo 472 >/sys/class/gpio/export
[root@linuxbox ~]# echo out >/sys/class/gpio/gpio472/direction
[root@linuxbox ~]# echo 0 >/sys/class/gpio/gpio472/value
[root@linuxbox ~]# echo 1 >/sys/bus/pci/rescan
pci 2000:03:00.0: [11ab:e097] type 00 class 0x058000
pci 2000:03:00.0: reg 0x10: [mem 0xd0000000-0xd00fffff 64bit pref]
pci 2000:03:00.0: reg 0x18: [mem 0x00000000-0x03ffffff 64bit]
pci 2000:03:00.0: Adding to iommu group 15
pci_bus 2000:03: busn_res: [bus 03] end is updated to 03
pci 2000:04:00.0: [11ab:e097] type 00 class 0x058000
pci 2000:04:00.0: reg 0x10: [mem 0xd0000000-0xd00fffff 64bit pref]
pci 2000:04:00.0: reg 0x18: [mem 0x00000000-0x03ffffff 64bit]
pci 2000:04:00.0: Adding to iommu group 15
pci_bus 2000:04: busn_res: [bus 04] end is updated to 04
pci 2000:05:00.0: [11ab:e097] type 00 class 0x058000
pci 2000:05:00.0: reg 0x10: [mem 0xd0000000-0xd00fffff 64bit pref]
pci 2000:05:00.0: reg 0x18: [mem 0x00000000-0x03ffffff 64bit]
pci 2000:05:00.0: Adding to iommu group 15
pci_bus 2000:05: busn_res: [bus 05] end is updated to 05
pci 2000:06:00.0: [11ab:e097] type 00 class 0x058000
pci 2000:06:00.0: reg 0x10: [mem 0xd0000000-0xd00fffff 64bit pref]
pci 2000:06:00.0: reg 0x18: [mem 0x00000000-0x03ffffff 64bit]
pci 2000:06:00.0: Adding to iommu group 15
pci_bus 2000:06: busn_res: [bus 06] end is updated to 06
pci_bus 2000:02: busn_res: [bus 02-06] end is updated to 06
pci_bus 2000:01: busn_res: [bus 01-06] end is updated to 06
pcieport 2000:00:00.0: BAR 9: no space for [mem size 0x00400000 64bit pref]
pcieport 2000:00:00.0: BAR 9: failed to assign [mem size 0x00400000
64bit pref]
pcieport 2000:01:00.0: BAR 8: assigned [mem 0xc40000000-0xc4fffffff]
pcieport 2000:01:00.0: BAR 9: assigned [mem 0xc50000000-0xc503fffff
64bit pref]
pci 2000:02:02.0: BAR 8: assigned [mem 0xc40000000-0xc43ffffff]
pci 2000:02:03.0: BAR 8: assigned [mem 0xc44000000-0xc47ffffff]
pci 2000:02:04.0: BAR 8: assigned [mem 0xc48000000-0xc4bffffff]
pci 2000:02:05.0: BAR 8: assigned [mem 0xc4c000000-0xc4fffffff]
pci 2000:02:02.0: BAR 9: assigned [mem 0xc50000000-0xc500fffff 64bit pref]
pci 2000:02:03.0: BAR 9: assigned [mem 0xc50100000-0xc501fffff 64bit pref]
pci 2000:02:04.0: BAR 9: assigned [mem 0xc50200000-0xc502fffff 64bit pref]
pci 2000:02:05.0: BAR 9: assigned [mem 0xc50300000-0xc503fffff 64bit pref]
pci 2000:03:00.0: BAR 2: assigned [mem 0xc40000000-0xc43ffffff 64bit]
pci 2000:03:00.0: BAR 0: assigned [mem 0xc50000000-0xc500fffff 64bit pref]
pci 2000:02:02.0: PCI bridge to [bus 03]
pci 2000:02:02.0: bridge window [mem 0xc40000000-0xc43ffffff]
pci 2000:02:02.0: bridge window [mem 0xc50000000-0xc500fffff 64bit pref]
pci 2000:04:00.0: BAR 2: assigned [mem 0xc44000000-0xc47ffffff 64bit]
pci 2000:04:00.0: BAR 0: assigned [mem 0xc50100000-0xc501fffff 64bit pref]
pci 2000:02:03.0: PCI bridge to [bus 04]
pci 2000:02:03.0: bridge window [mem 0xc44000000-0xc47ffffff]
pci 2000:02:03.0: bridge window [mem 0xc50100000-0xc501fffff 64bit pref]
pci 2000:05:00.0: BAR 2: assigned [mem 0xc48000000-0xc4bffffff 64bit]
pci 2000:05:00.0: BAR 0: assigned [mem 0xc50200000-0xc502fffff 64bit pref]
pci 2000:02:04.0: PCI bridge to [bus 05]
pci 2000:02:04.0: bridge window [mem 0xc48000000-0xc4bffffff]
pci 2000:02:04.0: bridge window [mem 0xc50200000-0xc502fffff 64bit pref]
pci 2000:06:00.0: BAR 2: assigned [mem 0xc4c000000-0xc4fffffff 64bit]
pci 2000:06:00.0: BAR 0: assigned [mem 0xc50300000-0xc503fffff 64bit pref]
pci 2000:02:05.0: PCI bridge to [bus 06]
pci 2000:02:05.0: bridge window [mem 0xc4c000000-0xc4fffffff]
pci 2000:02:05.0: bridge window [mem 0xc50300000-0xc503fffff 64bit pref]
[root@linuxbox ~]# lspci -t
-+-[2000:00]---00.0-[01-06]----00.0-[02-06]--+-02.0-[03]----00.0
| +-03.0-[04]----00.0
| +-04.0-[05]----00.0
| \-05.0-[06]----00.0
\-[0000:00]-
[root@linuxbox ~]# lspci -v -s 2000:01:00
2000:01:00.0 Class 0604: Device 111d:803e (rev 0e)
Flags: bus master, fast devsel, latency 0
Bus: primary=01, secondary=02, subordinate=06, sec-latency=0
I/O behind bridge: None
Memory behind bridge: None
Prefetchable memory behind bridge: None
Capabilities: [40] Express Upstream Port, MSI 00
Capabilities: [c0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [200] Virtual Channel
Kernel driver in use: pcieport
[root@linuxbox ~]# modprobe pptest
pptest: loading out-of-tree module taints kernel.
pptest: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
pptest 2000:03:00.0: enabling device (0000 -> 0002)
pptest 2000:03:00.0: resource0 [mem 0xc50000000-0xc500fffff 64bit pref]
mapped to c1980000
pptest 2000:03:00.0: resource2 [mem 0xc40000000-0xc43ffffff 64bit]
mapped to c1b00000
Oops: Machine check, sig: 7 [#1]
BE PAGE_SIZE=4K SMP NR_CPUS=8 CoreNet Generic
Modules linked in: pptest(PO+)
CPU: 0 PID: 417 Comm: modprobe Tainted: P M O 5.2.0-rc7-at1+ #8
NIP: b96fd10c LR: b96fd100 CTR: 80419df0
REGS: af19bf08 TRAP: 0204 Tainted: P M O (5.2.0-rc7-at1+)
MSR: 00029002 <CE,EE,ME> CR: 28228422 XER: 20000000
DEAR: c1b0004c ESR: 00000000
GPR00: b96fd100 ad107c68 ada1dd00 00000055 ae7303c4 ae739ba8 2dd8e000
00021002
GPR08: 00000007 c1b0004c 2dd8e000 000001f8 000001f8 10030838 0000001d
00000003
GPR16: ad107eb0 b96fd68e b96fd61c 0000fff1 ad107e00 00000398 b96bd000
00000017
GPR24: b96fd488 00000002 b96fd308 b96fd308 b96fd280 adb2cd10 a9e55800
a9e55878
NIP [b96fd10c] 0xb96fd10c
LR [b96fd100] 0xb96fd100
Call Trace:
[ad107c68] [b96fd100] 0xb96fd100 (unreliable)
[ad107c88] [803d0344] pci_device_probe+0xc4/0x150
[ad107ca8] [8043898c] really_probe+0x1ec/0x340
[ad107cd8] [8043909c] device_driver_attach+0x7c/0x90
[ad107cf8] [8043916c] __driver_attach+0xbc/0x120
[ad107d18] [804364b8] bus_for_each_dev+0x68/0xc0
[ad107d48] [80437ad8] bus_add_driver+0x178/0x250
[ad107d68] [80439888] driver_register+0x88/0x160
[ad107d78] [80002c00] do_one_initcall+0x40/0x210
[ad107dd8] [800c1218] do_init_module+0x60/0x1e8
[ad107df8] [800c0198] load_module+0x1c68/0x2230
[ad107ea8] [800c0940] sys_finit_module+0xa0/0xd0
[ad107f38] [800111d8] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0xff1ca78
LR = 0x1000edf4
Instruction dump:
7f84e378 38a00000 480000f5 80fd0008 7fe3fb78 7f84e378 38a00002 38de01e0
480000dd 813d0008 3929004c 7c0004ac <7ca04c2c> 0c050000 4c00012c 3c80b970
---[ end trace baaeae7553646d27 ]---
Machine check in kernel mode.
Caused by (from MCSR=a000): Load Error Report
Guarded Load Error Report
Bus error
If I remove the bridge, release the switch reset then rescan the pci bus
the memory space is assigned and things appear to work.
[root@linuxbox ~]# echo 1
>/sys/bus/pci/devices/2000:01:00.0/removepci_bus 2000:03: busn_res:
[bus 03] is released
pci 2000:02:02.0: Removing from iommu group 15
pci_bus 2000:04: busn_res: [bus 04] is released
pci 2000:02:03.0: Removing from iommu group 15
pci_bus 2000:05: busn_res: [bus 05] is released
pci 2000:02:04.0: Removing from iommu group 15
pci_bus 2000:06: busn_res: [bus 06] is released
pci 2000:02:05.0: Removing from iommu group 15
pci_bus 2000:02: busn_res: [bus 02-06] is released
pci 2000:01:00.0: Removing from iommu group 15
[root@linuxbox ~]# echo 472 >/sys/class/gpio/export
[root@linuxbox ~]# echo out >/sys/class/gpio/gpio472/direction
[root@linuxbox ~]# echo 0 >/sys/class/gpio/gpio472/value
[root@linuxbox ~]# echo 1 >/sys/bus/pci/rescan
snip
[root@linuxbox ~]# lspci -t
-+-[2000:00]---00.0-[01-06]----00.0-[02-06]--+-02.0-[03]----00.0
| +-03.0-[04]----00.0
| +-04.0-[05]----00.0
| \-05.0-[06]----00.0
\-[0000:00]-
[root@linuxbox ~]# lspci -v -s 2000:01:00
2000:01:00.0 Class 0604: Device 111d:803e (rev 0e)
Flags: bus master, fast devsel, latency 0
Bus: primary=01, secondary=02, subordinate=06, sec-latency=0
I/O behind bridge: None
Memory behind bridge: e0000000-efffffff [size=256M]
Prefetchable memory behind bridge:
00000000f0000000-00000000f03fffff [size=4M]
Capabilities: [40] Express Upstream Port, MSI 00
Capabilities: [c0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [200] Virtual Channel
Kernel driver in use: pcieport
[root@linuxbox ~]# modprobe pptest
pptest: loading out-of-tree module taints kernel.
pptest: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
pptest 2000:03:00.0: enabling device (0000 -> 0002)
pptest 2000:03:00.0: resource0 [mem 0xc50000000-0xc500fffff 64bit pref]
mapped to c1980000
pptest 2000:03:00.0: resource2 [mem 0xc40000000-0xc43ffffff 64bit]
mapped to c1b00000
pptest 2000:03:00.0: 0x4c = e0973
pptest 2000:03:00.0: 0x50 = 11ab
pptest 2000:04:00.0: enabling device (0000 -> 0002)
pptest 2000:04:00.0: resource0 [mem 0xc50100000-0xc501fffff 64bit pref]
mapped to c5b80000
pptest 2000:04:00.0: resource2 [mem 0xc44000000-0xc47ffffff 64bit]
mapped to c5d00000
pptest 2000:04:00.0: 0x4c = e0973
pptest 2000:04:00.0: 0x50 = 11ab
pptest 2000:05:00.0: enabling device (0000 -> 0002)
pptest 2000:05:00.0: resource0 [mem 0xc50200000-0xc502fffff 64bit pref]
mapped to c9d80000
pptest 2000:05:00.0: resource2 [mem 0xc48000000-0xc4bffffff 64bit]
mapped to c9f00000
pptest 2000:05:00.0: 0x4c = e0973
pptest 2000:05:00.0: 0x50 = 11ab
pptest 2000:06:00.0: enabling device (0000 -> 0002)
pptest 2000:06:00.0: resource0 [mem 0xc50300000-0xc503fffff 64bit pref]
mapped to cdf80000
pptest 2000:06:00.0: resource2 [mem 0xc4c000000-0xc4fffffff 64bit]
mapped to ce100000
pptest 2000:06:00.0: 0x4c = e0973
pptest 2000:06:00.0: 0x50 = 11ab
Previously (under 4.4.x) we were able to get the memory space assigned
by triggering a rescan (i.e. the first case above) but I've always seen
the code that did that as a bit of a hack.
Why would the rescan in the second case assign memory that wasn't
assigned by the first case? Is there any way I can avoid the removal
dance, ideally by assigning reset gpios in the device tree?
Thanks,
Chris
--
[1] - Similar hardware to
https://lore.kernel.org/linux-pci/403548ec3a7543b08ca32e47a1465e70@svr-chch-ex1.atlnz.lc/
but a different CPU and architecture.
^ permalink raw reply
* Re: [PATCH v12 01/11] MODSIGN: Export module signature definitions
From: Thiago Jung Bauermann @ 2019-07-04 6:42 UTC (permalink / raw)
To: Jessica Yu
Cc: Philipp Rudo, linux-s390, Herbert Xu, linux-doc, Dmitry Kasatkin,
David S. Miller, Jonathan Corbet, Heiko Carstens, linux-kernel,
Mimi Zohar, James Morris, David Howells, AKASHI, Takahiro,
linux-security-module, keyrings, linux-crypto, linux-integrity,
linuxppc-dev, David Woodhouse, Serge E. Hallyn
In-Reply-To: <20190701144752.GC25484@linux-8ccs>
Jessica Yu <jeyu@kernel.org> writes:
> +++ Thiago Jung Bauermann [27/06/19 23:19 -0300]:
>>IMA will use the module_signature format for append signatures, so export
>>the relevant definitions and factor out the code which verifies that the
>>appended signature trailer is valid.
>>
>>Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
>>and be able to use mod_check_sig() without having to depend on either
>>CONFIG_MODULE_SIG or CONFIG_MODULES.
>>
>>Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>>Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
>>Cc: Jessica Yu <jeyu@kernel.org>
>>---
>> include/linux/module.h | 3 --
>> include/linux/module_signature.h | 44 +++++++++++++++++++++++++
>> init/Kconfig | 6 +++-
>> kernel/Makefile | 1 +
>> kernel/module.c | 1 +
>> kernel/module_signature.c | 46 ++++++++++++++++++++++++++
>> kernel/module_signing.c | 56 +++++---------------------------
>> scripts/Makefile | 2 +-
>> 8 files changed, 106 insertions(+), 53 deletions(-)
>>
>>diff --git a/include/linux/module.h b/include/linux/module.h
>>index 188998d3dca9..aa56f531cf1e 100644
>>--- a/include/linux/module.h
>>+++ b/include/linux/module.h
>>@@ -25,9 +25,6 @@
>> #include <linux/percpu.h>
>> #include <asm/module.h>
>>
>>-/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
>>-#define MODULE_SIG_STRING "~Module signature appended~\n"
>>-
>
> Hi Thiago, apologies for the delay.
Hello Jessica, thanks for reviewing the patch!
> It looks like arch/s390/kernel/machine_kexec_file.c also relies on
> MODULE_SIG_STRING being defined, so module_signature.h will need to be
> included there too, otherwise we'll run into a compilation error.
Indeed. Thanks for spotting that. The patch below fixes it. It's
identical to the previous version except for the changes in
arch/s390/kernel/machine_kexec_file.c and their description in the
commit message. I'm also copying some s390 people in this email.
> Other than that, the module-related changes look good to me:
>
> Acked-by: Jessica Yu <jeyu@kernel.org>
Thank you very much!
--
Thiago Jung Bauermann
IBM Linux Technology Center
From 0ca180c66f4cff8b1fcd51f3457cc06dac2f0e81 Mon Sep 17 00:00:00 2001
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: Thu, 17 May 2018 21:46:12 -0300
Subject: [PATCH 1/1] MODSIGN: Export module signature definitions
IMA will use the module_signature format for append signatures, so export
the relevant definitions and factor out the code which verifies that the
appended signature trailer is valid.
Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
and be able to use mod_check_sig() without having to depend on either
CONFIG_MODULE_SIG or CONFIG_MODULES.
s390 duplicated the definition of struct module_signature so now they can
use the new <linux/module_signature.h> header instead.
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Acked-by: Jessica Yu <jeyu@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Philipp Rudo <prudo@linux.ibm.com>
---
arch/s390/kernel/machine_kexec_file.c | 24 +-----------
include/linux/module.h | 3 --
include/linux/module_signature.h | 44 +++++++++++++++++++++
init/Kconfig | 6 ++-
kernel/Makefile | 1 +
kernel/module.c | 1 +
kernel/module_signature.c | 46 ++++++++++++++++++++++
kernel/module_signing.c | 56 ++++-----------------------
scripts/Makefile | 2 +-
9 files changed, 107 insertions(+), 76 deletions(-)
create mode 100644 include/linux/module_signature.h
create mode 100644 kernel/module_signature.c
diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
index fbdd3ea73667..1ac9fbc6e01e 100644
--- a/arch/s390/kernel/machine_kexec_file.c
+++ b/arch/s390/kernel/machine_kexec_file.c
@@ -10,7 +10,7 @@
#include <linux/elf.h>
#include <linux/errno.h>
#include <linux/kexec.h>
-#include <linux/module.h>
+#include <linux/module_signature.h>
#include <linux/verification.h>
#include <asm/boot_data.h>
#include <asm/ipl.h>
@@ -23,28 +23,6 @@ const struct kexec_file_ops * const kexec_file_loaders[] = {
};
#ifdef CONFIG_KEXEC_VERIFY_SIG
-/*
- * Module signature information block.
- *
- * The constituents of the signature section are, in order:
- *
- * - Signer's name
- * - Key identifier
- * - Signature data
- * - Information block
- */
-struct module_signature {
- u8 algo; /* Public-key crypto algorithm [0] */
- u8 hash; /* Digest algorithm [0] */
- u8 id_type; /* Key identifier type [PKEY_ID_PKCS7] */
- u8 signer_len; /* Length of signer's name [0] */
- u8 key_id_len; /* Length of key identifier [0] */
- u8 __pad[3];
- __be32 sig_len; /* Length of signature data */
-};
-
-#define PKEY_ID_PKCS7 2
-
int s390_verify_sig(const char *kernel, unsigned long kernel_len)
{
const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
diff --git a/include/linux/module.h b/include/linux/module.h
index 188998d3dca9..aa56f531cf1e 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -25,9 +25,6 @@
#include <linux/percpu.h>
#include <asm/module.h>
-/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
-#define MODULE_SIG_STRING "~Module signature appended~\n"
-
/* Not Yet Implemented */
#define MODULE_SUPPORTED_DEVICE(name)
diff --git a/include/linux/module_signature.h b/include/linux/module_signature.h
new file mode 100644
index 000000000000..523617fc5b6a
--- /dev/null
+++ b/include/linux/module_signature.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Module signature handling.
+ *
+ * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ */
+
+#ifndef _LINUX_MODULE_SIGNATURE_H
+#define _LINUX_MODULE_SIGNATURE_H
+
+/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
+#define MODULE_SIG_STRING "~Module signature appended~\n"
+
+enum pkey_id_type {
+ PKEY_ID_PGP, /* OpenPGP generated key ID */
+ PKEY_ID_X509, /* X.509 arbitrary subjectKeyIdentifier */
+ PKEY_ID_PKCS7, /* Signature in PKCS#7 message */
+};
+
+/*
+ * Module signature information block.
+ *
+ * The constituents of the signature section are, in order:
+ *
+ * - Signer's name
+ * - Key identifier
+ * - Signature data
+ * - Information block
+ */
+struct module_signature {
+ u8 algo; /* Public-key crypto algorithm [0] */
+ u8 hash; /* Digest algorithm [0] */
+ u8 id_type; /* Key identifier type [PKEY_ID_PKCS7] */
+ u8 signer_len; /* Length of signer's name [0] */
+ u8 key_id_len; /* Length of key identifier [0] */
+ u8 __pad[3];
+ __be32 sig_len; /* Length of signature data */
+};
+
+int mod_check_sig(const struct module_signature *ms, size_t file_len,
+ const char *name);
+
+#endif /* _LINUX_MODULE_SIGNATURE_H */
diff --git a/init/Kconfig b/init/Kconfig
index 8b9ffe236e4f..c2286a3c74c5 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1852,6 +1852,10 @@ config BASE_SMALL
default 0 if BASE_FULL
default 1 if !BASE_FULL
+config MODULE_SIG_FORMAT
+ def_bool n
+ select SYSTEM_DATA_VERIFICATION
+
menuconfig MODULES
bool "Enable loadable module support"
option modules
@@ -1929,7 +1933,7 @@ config MODULE_SRCVERSION_ALL
config MODULE_SIG
bool "Module signature verification"
depends on MODULES
- select SYSTEM_DATA_VERIFICATION
+ select MODULE_SIG_FORMAT
help
Check modules for valid signatures upon load: the signature
is simply appended to the module. For more information see
diff --git a/kernel/Makefile b/kernel/Makefile
index 33824f0385b3..f29ae2997a43 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -58,6 +58,7 @@ endif
obj-$(CONFIG_UID16) += uid16.o
obj-$(CONFIG_MODULES) += module.o
obj-$(CONFIG_MODULE_SIG) += module_signing.o
+obj-$(CONFIG_MODULE_SIG_FORMAT) += module_signature.o
obj-$(CONFIG_KALLSYMS) += kallsyms.o
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
obj-$(CONFIG_CRASH_CORE) += crash_core.o
diff --git a/kernel/module.c b/kernel/module.c
index 6e6712b3aaf5..2712f4d217f5 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -19,6 +19,7 @@
#include <linux/export.h>
#include <linux/extable.h>
#include <linux/moduleloader.h>
+#include <linux/module_signature.h>
#include <linux/trace_events.h>
#include <linux/init.h>
#include <linux/kallsyms.h>
diff --git a/kernel/module_signature.c b/kernel/module_signature.c
new file mode 100644
index 000000000000..4224a1086b7d
--- /dev/null
+++ b/kernel/module_signature.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Module signature checker
+ *
+ * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ */
+
+#include <linux/errno.h>
+#include <linux/printk.h>
+#include <linux/module_signature.h>
+#include <asm/byteorder.h>
+
+/**
+ * mod_check_sig - check that the given signature is sane
+ *
+ * @ms: Signature to check.
+ * @file_len: Size of the file to which @ms is appended.
+ * @name: What is being checked. Used for error messages.
+ */
+int mod_check_sig(const struct module_signature *ms, size_t file_len,
+ const char *name)
+{
+ if (be32_to_cpu(ms->sig_len) >= file_len - sizeof(*ms))
+ return -EBADMSG;
+
+ if (ms->id_type != PKEY_ID_PKCS7) {
+ pr_err("%s: Module is not signed with expected PKCS#7 message\n",
+ name);
+ return -ENOPKG;
+ }
+
+ if (ms->algo != 0 ||
+ ms->hash != 0 ||
+ ms->signer_len != 0 ||
+ ms->key_id_len != 0 ||
+ ms->__pad[0] != 0 ||
+ ms->__pad[1] != 0 ||
+ ms->__pad[2] != 0) {
+ pr_err("%s: PKCS#7 signature info has unexpected non-zero params\n",
+ name);
+ return -EBADMSG;
+ }
+
+ return 0;
+}
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 6b9a926fd86b..cdd04a6b8074 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -11,37 +11,13 @@
#include <linux/kernel.h>
#include <linux/errno.h>
+#include <linux/module.h>
+#include <linux/module_signature.h>
#include <linux/string.h>
#include <linux/verification.h>
#include <crypto/public_key.h>
#include "module-internal.h"
-enum pkey_id_type {
- PKEY_ID_PGP, /* OpenPGP generated key ID */
- PKEY_ID_X509, /* X.509 arbitrary subjectKeyIdentifier */
- PKEY_ID_PKCS7, /* Signature in PKCS#7 message */
-};
-
-/*
- * Module signature information block.
- *
- * The constituents of the signature section are, in order:
- *
- * - Signer's name
- * - Key identifier
- * - Signature data
- * - Information block
- */
-struct module_signature {
- u8 algo; /* Public-key crypto algorithm [0] */
- u8 hash; /* Digest algorithm [0] */
- u8 id_type; /* Key identifier type [PKEY_ID_PKCS7] */
- u8 signer_len; /* Length of signer's name [0] */
- u8 key_id_len; /* Length of key identifier [0] */
- u8 __pad[3];
- __be32 sig_len; /* Length of signature data */
-};
-
/*
* Verify the signature on a module.
*/
@@ -49,6 +25,7 @@ int mod_verify_sig(const void *mod, struct load_info *info)
{
struct module_signature ms;
size_t sig_len, modlen = info->len;
+ int ret;
pr_devel("==>%s(,%zu)\n", __func__, modlen);
@@ -56,32 +33,15 @@ int mod_verify_sig(const void *mod, struct load_info *info)
return -EBADMSG;
memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
- modlen -= sizeof(ms);
+
+ ret = mod_check_sig(&ms, modlen, info->name);
+ if (ret)
+ return ret;
sig_len = be32_to_cpu(ms.sig_len);
- if (sig_len >= modlen)
- return -EBADMSG;
- modlen -= sig_len;
+ modlen -= sig_len + sizeof(ms);
info->len = modlen;
- if (ms.id_type != PKEY_ID_PKCS7) {
- pr_err("%s: Module is not signed with expected PKCS#7 message\n",
- info->name);
- return -ENOPKG;
- }
-
- if (ms.algo != 0 ||
- ms.hash != 0 ||
- ms.signer_len != 0 ||
- ms.key_id_len != 0 ||
- ms.__pad[0] != 0 ||
- ms.__pad[1] != 0 ||
- ms.__pad[2] != 0) {
- pr_err("%s: PKCS#7 signature info has unexpected non-zero params\n",
- info->name);
- return -EBADMSG;
- }
-
return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
VERIFY_USE_SECONDARY_KEYRING,
VERIFYING_MODULE_SIGNATURE,
diff --git a/scripts/Makefile b/scripts/Makefile
index 9d442ee050bd..52098b080ab7 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -17,7 +17,7 @@ hostprogs-$(CONFIG_VT) += conmakehash
hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sortextable
hostprogs-$(CONFIG_ASN1) += asn1_compiler
-hostprogs-$(CONFIG_MODULE_SIG) += sign-file
+hostprogs-$(CONFIG_MODULE_SIG_FORMAT) += sign-file
hostprogs-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert
^ permalink raw reply related
* Re: [PATCH v12 00/11] Appended signatures support for IMA appraisal
From: Thiago Jung Bauermann @ 2019-07-04 6:45 UTC (permalink / raw)
To: Mimi Zohar
Cc: Herbert Xu, linux-doc, Dmitry Kasatkin, David S. Miller,
Jonathan Corbet, linux-kernel, James Morris, David Howells,
AKASHI, Takahiro, linux-security-module, keyrings, linux-crypto,
Jessica Yu, linux-integrity, linuxppc-dev, David Woodhouse,
Serge E. Hallyn
In-Reply-To: <1561991934.4067.17.camel@linux.ibm.com>
Mimi Zohar <zohar@linux.ibm.com> writes:
> On Thu, 2019-06-27 at 23:19 -0300, Thiago Jung Bauermann wrote:
>> Hello,
>>
>> This version is essentially identical to the last one.
>>
>> It is only a rebase on top of today's linux-integrity/next-queued-testing,
>> prompted by conflicts with Prakhar Srivastava's patches to measure the
>> kernel command line. It also drops two patches that are already present in
>> that branch.
>
> Thanks, Thiago. These patches are now in next-queued-testing waiting
> for some additional reviews/acks.
Thank you very much, Mimi! Now I think I'm only missing acks for the
PKCS#7 changes in patches 2 and 3, and an ack for the s390 changes in
patch 1.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [PATCH v3 0/3] Forced-wakeup for stop states on Powernv
From: Abhishek Goel @ 2019-07-04 9:18 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: ego, daniel.lezcano, rjw, npiggin, Abhishek Goel, dja
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be busy soon. However, if no new workload is scheduled on that CPU in the
near future, the CPU will end up in the shallow state.
Motivation
----------
In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a shallow stop state on a tickless system. As
we might get stuck into shallow states even for hours, in absence of ticks
or interrupts.
To address this, We forcefully wakeup the cpu by setting the decrementer.
The decrementer is set to a value that corresponds with the residency of
the next available state. Thus firing up a timer that will forcefully
wakeup the cpu. Few such iterations will essentially train the governor to
select a deeper state for that cpu, as the timer here corresponds to the
next available cpuidle state residency. Thus, cpu will eventually end up
in the deepest possible state and we won't get stuck in a shallow state
for long duration.
Experiment
----------
For earlier versions when this feature was meat to be only for shallow lite
states, I performed experiments for three scenarios to collect some data.
case 1 :
Without this patch and without tick retained, i.e. in a upstream kernel,
It would spend more than even a second to get out of stop0_lite.
case 2 : With tick retained in a upstream kernel -
Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
it to take 8 sched tick to get out of stop0_lite. Experimentally,
observation was
=========================================================
sample min max 99percentile
20 4ms 12ms 4ms
=========================================================
It would take atleast one sched tick to get out of stop0_lite.
case 2 : With this patch (not stopping tick, but explicitly queuing a
timer)
============================================================
sample min max 99percentile
============================================================
20 144us 192us 144us
============================================================
Description of current implementation
-------------------------------------
We calculate timeout for the current idle state as the residency value
of the next available idle state. If the decrementer is set to be
greater than this timeout, we update the decrementer value with the
residency of next available idle state. Thus, essentially training the
governor to select the next available deeper state until we reach the
deepest state. Hence, we won't get stuck unnecessarily in shallow states
for longer duration.
--------------------------------
v1 of auto-promotion : https://lkml.org/lkml/2019/3/22/58 This patch was
implemented only for shallow lite state in generic cpuidle driver.
v2 : Removed timeout_needed and rebased to current
upstream kernel
Then,
v1 of forced-wakeup : Moved the code to cpuidle powernv driver and started
as forced wakeup instead of auto-promotion
v2 : Extended the forced wakeup logic for all states.
Setting the decrementer instead of queuing up a hrtimer to implement the
logic.
v3 : 1) Cleanly handle setting the decrementer after exiting out of stop
states.
2) Added a disable_callback feature to compute timeout whenever a
state is enbaled or disabled instead of computing everytime in fast
idle path.
3) Use disable callback to recompute timeout whenever state usage
is changed for a state. Also, cleaned up the get_snooze_timeout
function.
Abhishek Goel (3):
cpuidle-powernv : forced wakeup for stop states
cpuidle : Add callback whenever a state usage is enabled/disabled
cpuidle-powernv : Recompute the idle-state timeouts when state usage
is enabled/disabled
arch/powerpc/include/asm/time.h | 2 ++
arch/powerpc/kernel/time.c | 40 ++++++++++++++++++++++++++
drivers/cpuidle/cpuidle-powernv.c | 47 ++++++++++++++++++++++---------
drivers/cpuidle/sysfs.c | 15 +++++++++-
include/linux/cpuidle.h | 5 ++++
5 files changed, 95 insertions(+), 14 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v3 1/3] cpuidle-powernv : forced wakeup for stop states
From: Abhishek Goel @ 2019-07-04 9:18 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: ego, daniel.lezcano, rjw, npiggin, Abhishek Goel, dja
In-Reply-To: <20190704091827.19555-1-huntbag@linux.vnet.ibm.com>
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be busy soon. However, if no new workload is scheduled on that CPU in the
near future, the CPU may end up in the shallow state.
This is problematic, when the predicted state in the aforementioned
scenario is a shallow stop state on a tickless system. As we might get
stuck into shallow states for hours, in absence of ticks or interrupts.
To address this, We forcefully wakeup the cpu by setting the
decrementer. The decrementer is set to a value that corresponds with the
residency of the next available state. Thus firing up a timer that will
forcefully wakeup the cpu. Few such iterations will essentially train the
governor to select a deeper state for that cpu, as the timer here
corresponds to the next available cpuidle state residency. Thus, cpu will
eventually end up in the deepest possible state.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
Auto-promotion
v1 : started as auto promotion logic for cpuidle states in generic
driver
v2 : Removed timeout_needed and rebased the code to upstream kernel
Forced-wakeup
v1 : New patch with name of forced wakeup started
v2 : Extending the forced wakeup logic for all states. Setting the
decrementer instead of queuing up a hrtimer to implement the logic.
v3 : Cleanly handle setting/resetting of decrementer so as to not break
irq work
arch/powerpc/include/asm/time.h | 2 ++
arch/powerpc/kernel/time.c | 40 +++++++++++++++++++++++++++++++
drivers/cpuidle/cpuidle-powernv.c | 32 +++++++++++++++++++++++++
3 files changed, 74 insertions(+)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 54f4ec1f9..a3bd4f3c0 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -188,6 +188,8 @@ static inline unsigned long tb_ticks_since(unsigned long tstamp)
extern u64 mulhdu(u64, u64);
#endif
+extern int set_dec_before_idle(u64 timeout);
+extern void reset_dec_after_idle(void);
extern void div128_by_32(u64 dividend_high, u64 dividend_low,
unsigned divisor, struct div_result *dr);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 694522308..814de3469 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -576,6 +576,46 @@ void arch_irq_work_raise(void)
#endif /* CONFIG_IRQ_WORK */
+/*
+ * Returns 1 if we have reprogrammed the decrementer for idle.
+ * Returns 0 if the decrementer is unchanged.
+ */
+int set_dec_before_idle(u64 timeout)
+{
+ u64 *next_tb = this_cpu_ptr(&decrementers_next_tb);
+ u64 now = get_tb_or_rtc();
+
+ /*
+ * Ensure that the timeout is at least one microsecond
+ * before the current decrement value. Else, we will
+ * unnecesarily wakeup again within a microsecond.
+ */
+ if (now + timeout + 512 > *next_tb)
+ return 0;
+
+ set_dec(timeout);
+
+ return 1;
+}
+
+void reset_dec_after_idle(void)
+{
+ u64 now;
+ u64 *next_tb;
+
+ if (test_irq_work_pending())
+ return;
+
+ now = get_tb_or_rtc();
+ next_tb = this_cpu_ptr(&decrementers_next_tb);
+ if (now >= *next_tb)
+ return;
+
+ set_dec(*next_tb - now);
+ if (test_irq_work_pending())
+ set_dec(1);
+}
+
/*
* timer_interrupt - gets called when the decrementer overflows,
* with interrupts disabled.
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index 84b1ebe21..f51478460 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -21,6 +21,7 @@
#include <asm/opal.h>
#include <asm/runlatch.h>
#include <asm/cpuidle.h>
+#include <asm/time.h>
/*
* Expose only those Hardware idle states via the cpuidle framework
@@ -46,6 +47,26 @@ static struct stop_psscr_table stop_psscr_table[CPUIDLE_STATE_MAX] __read_mostly
static u64 default_snooze_timeout __read_mostly;
static bool snooze_timeout_en __read_mostly;
+static u64 forced_wakeup_timeout(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int i;
+
+ for (i = index + 1; i < drv->state_count; i++) {
+ struct cpuidle_state *s = &drv->states[i];
+ struct cpuidle_state_usage *su = &dev->states_usage[i];
+
+ if (s->disabled || su->disable)
+ continue;
+
+ return (s->target_residency + 2 * s->exit_latency) *
+ tb_ticks_per_usec;
+ }
+
+ return 0;
+}
+
static u64 get_snooze_timeout(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -144,8 +165,19 @@ static int stop_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
+ u64 timeout_tb;
+ int forced_wakeup = 0;
+
+ timeout_tb = forced_wakeup_timeout(dev, drv, index);
+ if (timeout_tb)
+ forced_wakeup = set_dec_before_idle(timeout_tb);
+
power9_idle_type(stop_psscr_table[index].val,
stop_psscr_table[index].mask);
+
+ if (forced_wakeup)
+ reset_dec_after_idle();
+
return index;
}
--
2.17.1
^ permalink raw reply related
* [RFC v3 2/3] cpuidle : Add callback whenever a state usage is enabled/disabled
From: Abhishek Goel @ 2019-07-04 9:18 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: ego, daniel.lezcano, rjw, npiggin, Abhishek Goel, dja
In-Reply-To: <20190704091827.19555-1-huntbag@linux.vnet.ibm.com>
To force wakeup a cpu, we need to compute the timeout in the fast idle
path as a state may be enabled or disabled but there did not exist a
feedback to driver when a state is enabled or disabled.
This patch adds a callback whenever a state_usage records a store for
disable attribute.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
drivers/cpuidle/sysfs.c | 15 ++++++++++++++-
include/linux/cpuidle.h | 4 ++++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index eb20adb5d..141671a53 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -415,8 +415,21 @@ static ssize_t cpuidle_state_store(struct kobject *kobj, struct attribute *attr,
struct cpuidle_state_usage *state_usage = kobj_to_state_usage(kobj);
struct cpuidle_state_attr *cattr = attr_to_stateattr(attr);
- if (cattr->store)
+ if (cattr->store) {
ret = cattr->store(state, state_usage, buf, size);
+ if (ret == size &&
+ strncmp(cattr->attr.name, "disable",
+ strlen("disable"))) {
+ struct kobject *cpuidle_kobj = kobj->parent;
+ struct cpuidle_device *dev =
+ to_cpuidle_device(cpuidle_kobj);
+ struct cpuidle_driver *drv =
+ cpuidle_get_cpu_driver(dev);
+
+ if (drv->disable_callback)
+ drv->disable_callback(dev, drv);
+ }
+ }
return ret;
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index bb9a0db89..8a0e54bd0 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -119,6 +119,10 @@ struct cpuidle_driver {
/* the driver handles the cpus in cpumask */
struct cpumask *cpumask;
+
+ void (*disable_callback)(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv);
+
};
#ifdef CONFIG_CPU_IDLE
--
2.17.1
^ permalink raw reply related
* [RFC v3 3/3] cpuidle-powernv : Recompute the idle-state timeouts when state usage is enabled/disabled
From: Abhishek Goel @ 2019-07-04 9:18 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: ego, daniel.lezcano, rjw, npiggin, Abhishek Goel, dja
In-Reply-To: <20190704091827.19555-1-huntbag@linux.vnet.ibm.com>
The disable callback can be used to compute timeout for other states
whenever a state is enabled or disabled. We store the computed timeout
in "timeout" defined in cpuidle state strucure. So, we compute timeout
only when some state is enabled or disabled and not every time in the
fast idle path.
We also use the computed timeout to get timeout for snooze, thus getting
rid of get_snooze_timeout for snooze loop.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
drivers/cpuidle/cpuidle-powernv.c | 35 +++++++++++--------------------
include/linux/cpuidle.h | 1 +
2 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index f51478460..7350f404a 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -45,7 +45,6 @@ struct stop_psscr_table {
static struct stop_psscr_table stop_psscr_table[CPUIDLE_STATE_MAX] __read_mostly;
static u64 default_snooze_timeout __read_mostly;
-static bool snooze_timeout_en __read_mostly;
static u64 forced_wakeup_timeout(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
@@ -67,26 +66,13 @@ static u64 forced_wakeup_timeout(struct cpuidle_device *dev,
return 0;
}
-static u64 get_snooze_timeout(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+static void pnv_disable_callback(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv)
{
int i;
- if (unlikely(!snooze_timeout_en))
- return default_snooze_timeout;
-
- for (i = index + 1; i < drv->state_count; i++) {
- struct cpuidle_state *s = &drv->states[i];
- struct cpuidle_state_usage *su = &dev->states_usage[i];
-
- if (s->disabled || su->disable)
- continue;
-
- return s->target_residency * tb_ticks_per_usec;
- }
-
- return default_snooze_timeout;
+ for (i = 0; i < drv->state_count; i++)
+ drv->states[i].timeout = forced_wakeup_timeout(dev, drv, i);
}
static int snooze_loop(struct cpuidle_device *dev,
@@ -94,16 +80,20 @@ static int snooze_loop(struct cpuidle_device *dev,
int index)
{
u64 snooze_exit_time;
+ u64 snooze_timeout = drv->states[index].timeout;
+
+ if (!snooze_timeout)
+ snooze_timeout = default_snooze_timeout;
set_thread_flag(TIF_POLLING_NRFLAG);
local_irq_enable();
- snooze_exit_time = get_tb() + get_snooze_timeout(dev, drv, index);
+ snooze_exit_time = get_tb() + snooze_timeout;
ppc64_runlatch_off();
HMT_very_low();
while (!need_resched()) {
- if (likely(snooze_timeout_en) && get_tb() > snooze_exit_time) {
+ if (get_tb() > snooze_exit_time) {
/*
* Task has not woken up but we are exiting the polling
* loop anyway. Require a barrier after polling is
@@ -168,7 +158,7 @@ static int stop_loop(struct cpuidle_device *dev,
u64 timeout_tb;
int forced_wakeup = 0;
- timeout_tb = forced_wakeup_timeout(dev, drv, index);
+ timeout_tb = drv->states[index].timeout;
if (timeout_tb)
forced_wakeup = set_dec_before_idle(timeout_tb);
@@ -255,6 +245,7 @@ static int powernv_cpuidle_driver_init(void)
*/
drv->cpumask = (struct cpumask *)cpu_present_mask;
+ drv->disable_callback = pnv_disable_callback;
return 0;
}
@@ -414,8 +405,6 @@ static int powernv_idle_probe(void)
/* Device tree can indicate more idle states */
max_idle_state = powernv_add_idle_states();
default_snooze_timeout = TICK_USEC * tb_ticks_per_usec;
- if (max_idle_state > 1)
- snooze_timeout_en = true;
} else
return -ENODEV;
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 8a0e54bd0..31662b657 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -50,6 +50,7 @@ struct cpuidle_state {
int power_usage; /* in mW */
unsigned int target_residency; /* in US */
bool disabled; /* disabled on all CPUs */
+ unsigned long long timeout; /* timeout for exiting out of a state */
int (*enter) (struct cpuidle_device *dev,
struct cpuidle_driver *drv,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v12 01/11] MODSIGN: Export module signature definitions
From: Philipp Rudo @ 2019-07-04 10:54 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: linux-s390, Herbert Xu, linux-doc, Dmitry Kasatkin,
David S. Miller, Jonathan Corbet, Heiko Carstens, linux-kernel,
Mimi Zohar, James Morris, David Howells, AKASHI, Takahiro,
linux-security-module, keyrings, linux-crypto, Jessica Yu,
linux-integrity, linuxppc-dev, David Woodhouse, Serge E. Hallyn
In-Reply-To: <87lfxel2q6.fsf@morokweng.localdomain>
Hi Thiago,
On Thu, 04 Jul 2019 03:42:57 -0300
Thiago Jung Bauermann <bauerman@linux.ibm.com> wrote:
> Jessica Yu <jeyu@kernel.org> writes:
>
> > +++ Thiago Jung Bauermann [27/06/19 23:19 -0300]:
> >>IMA will use the module_signature format for append signatures, so export
> >>the relevant definitions and factor out the code which verifies that the
> >>appended signature trailer is valid.
> >>
> >>Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
> >>and be able to use mod_check_sig() without having to depend on either
> >>CONFIG_MODULE_SIG or CONFIG_MODULES.
> >>
> >>Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> >>Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> >>Cc: Jessica Yu <jeyu@kernel.org>
> >>---
> >> include/linux/module.h | 3 --
> >> include/linux/module_signature.h | 44 +++++++++++++++++++++++++
> >> init/Kconfig | 6 +++-
> >> kernel/Makefile | 1 +
> >> kernel/module.c | 1 +
> >> kernel/module_signature.c | 46 ++++++++++++++++++++++++++
> >> kernel/module_signing.c | 56 +++++---------------------------
> >> scripts/Makefile | 2 +-
> >> 8 files changed, 106 insertions(+), 53 deletions(-)
> >>
> >>diff --git a/include/linux/module.h b/include/linux/module.h
> >>index 188998d3dca9..aa56f531cf1e 100644
> >>--- a/include/linux/module.h
> >>+++ b/include/linux/module.h
> >>@@ -25,9 +25,6 @@
> >> #include <linux/percpu.h>
> >> #include <asm/module.h>
> >>
> >>-/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
> >>-#define MODULE_SIG_STRING "~Module signature appended~\n"
> >>-
> >
> > Hi Thiago, apologies for the delay.
>
> Hello Jessica, thanks for reviewing the patch!
>
> > It looks like arch/s390/kernel/machine_kexec_file.c also relies on
> > MODULE_SIG_STRING being defined, so module_signature.h will need to be
> > included there too, otherwise we'll run into a compilation error.
>
> Indeed. Thanks for spotting that. The patch below fixes it. It's
> identical to the previous version except for the changes in
> arch/s390/kernel/machine_kexec_file.c and their description in the
> commit message. I'm also copying some s390 people in this email.
to me the s390 part looks good but for one minor nit.
In arch/s390/Kconfig KEXEC_VERIFY_SIG currently depends on
SYSTEM_DATA_VERIFICATION. I'd prefer when you update this to the new
MODULE_SIG_FORMAT. It shouldn't make any difference right now, as we don't
use mod_check_sig in our code path. But it could cause problems in the future,
when more code might be shared.
Thanks
Philipp
> > Other than that, the module-related changes look good to me:
> >
> > Acked-by: Jessica Yu <jeyu@kernel.org>
>
> Thank you very much!
>
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries: Fix maximum memory value
From: Michael Ellerman @ 2019-07-04 11:13 UTC (permalink / raw)
To: Naveen N. Rao, Aravinda Prasad, Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <1561743225.hrre8pgw6j.naveen@linux.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> Nathan Lynch wrote:
>> Aravinda Prasad <aravinda@linux.vnet.ibm.com> writes:
>>> Calculating the maximum memory based on the number of lmbs
>>> and lmb size does not account for the RMA region. Hence
>>> use memory_hotplug_max(), which already accounts for the
>>> RMA region, to fetch the maximum memory value. Thanks to
>>> Nathan Lynch for suggesting the memory_hotplug_max()
>>> function.
>>
>> Well, I hope I haven't led you astray... will it give you the desired
>> result on a kernel configured without memory hotplug support, booted in
>> an LPAR with some huge pages configured?
>>
>> If so, then
>> Acked-by: Nathan Lynch <nathanl@linux.ibm.com>
>>
>> It would likely help with review and future maintenance if the semantics
>> and intended use of the MaxMem field are made a little more
>> explicit. For example, is it supposed to include persistent memory?
>> Perhaps a follow-up patch could address this. Or maybe I'm overthinking
>> it.
>
> This was primarily aimed to replicate what AIX lparstat does and
> documentation (*) just says:
>
> Maximum Memory
> Maximum possible amount of Memory.
>
> I think this mirrors the maximum memory value set in the LPAR profile,
> and this provides a way to obtain that value from within the LPAR.
But the doc string for memory_hotplug_max() says:
* memory_hotplug_max - return max address of memory that may be added
ie. maximum *address* not maximum *amount*.
Possibly it turns out to be the same value, but that is just because you
have no holes in your layout.
So I don't think this patch is correct.
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries: Fix maximum memory value
From: Aravinda Prasad @ 2019-07-04 11:30 UTC (permalink / raw)
To: Michael Ellerman, Naveen N. Rao, Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <871rz6qch5.fsf@concordia.ellerman.id.au>
On Thursday 04 July 2019 04:43 PM, Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>> Nathan Lynch wrote:
>>> Aravinda Prasad <aravinda@linux.vnet.ibm.com> writes:
>>>> Calculating the maximum memory based on the number of lmbs
>>>> and lmb size does not account for the RMA region. Hence
>>>> use memory_hotplug_max(), which already accounts for the
>>>> RMA region, to fetch the maximum memory value. Thanks to
>>>> Nathan Lynch for suggesting the memory_hotplug_max()
>>>> function.
>>>
>>> Well, I hope I haven't led you astray... will it give you the desired
>>> result on a kernel configured without memory hotplug support, booted in
>>> an LPAR with some huge pages configured?
>>>
>>> If so, then
>>> Acked-by: Nathan Lynch <nathanl@linux.ibm.com>
>>>
>>> It would likely help with review and future maintenance if the semantics
>>> and intended use of the MaxMem field are made a little more
>>> explicit. For example, is it supposed to include persistent memory?
>>> Perhaps a follow-up patch could address this. Or maybe I'm overthinking
>>> it.
>>
>> This was primarily aimed to replicate what AIX lparstat does and
>> documentation (*) just says:
>>
>> Maximum Memory
>> Maximum possible amount of Memory.
>>
>> I think this mirrors the maximum memory value set in the LPAR profile,
>> and this provides a way to obtain that value from within the LPAR.
>
> But the doc string for memory_hotplug_max() says:
>
> * memory_hotplug_max - return max address of memory that may be added
>
>
> ie. maximum *address* not maximum *amount*.
>
> Possibly it turns out to be the same value, but that is just because you
> have no holes in your layout.
>
> So I don't think this patch is correct.
memory_hotplug_max (in one of the cases) is taking the value from
"ibm,lrdr-capacity" and according to PAPR:
PAPR section C.6.3.1 ibm,lrdr-capacity:
"The phys (of size #address-cells) communicates the maximum address in
bytes and therefore, the most memory that can be allocated to this
partition."
On other cases memory_hotplug_max() is calculating based on the number
of lmbs assigned to the partition, so should still give max mem value
>
> cheers
>
--
Regards,
Aravinda
^ permalink raw reply
* Re: [PATCH] tpm: fixes uninitialized allocated banks for IBM vtpm driver
From: Mimi Zohar @ 2019-07-04 11:59 UTC (permalink / raw)
To: Nayna Jain, linux-integrity, linuxppc-dev
Cc: Sachin Sant, George Wilson, linux-kernel, Jarkko Sakkinen,
Jason Gunthorpe, Peter Huewe, Michal Suchanek
In-Reply-To: <1562211121-2188-1-git-send-email-nayna@linux.ibm.com>
On Wed, 2019-07-03 at 23:32 -0400, Nayna Jain wrote:
> The nr_allocated_banks and allocated banks are initialized as part of
> tpm_chip_register. Currently, this is done as part of auto startup
> function. However, some drivers, like the ibm vtpm driver, do not run
> auto startup during initialization. This results in uninitialized memory
> issue and causes a kernel panic during boot.
>
> This patch moves the pcr allocation outside the auto startup function
> into tpm_chip_register. This ensures that allocated banks are initialized
> in any case.
>
> Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
> PCR read")
> Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] tpm: fixes uninitialized allocated banks for IBM vtpm driver
From: Sachin Sant @ 2019-07-04 13:56 UTC (permalink / raw)
To: Nayna Jain
Cc: Michal Suchanek, linux-kernel, Jarkko Sakkinen, Jason Gunthorpe,
Mimi Zohar, linux-integrity, George Wilson, linuxppc-dev,
Peter Huewe
In-Reply-To: <1562241547.6165.81.camel@linux.ibm.com>
> On 04-Jul-2019, at 5:29 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Wed, 2019-07-03 at 23:32 -0400, Nayna Jain wrote:
>> The nr_allocated_banks and allocated banks are initialized as part of
>> tpm_chip_register. Currently, this is done as part of auto startup
>> function. However, some drivers, like the ibm vtpm driver, do not run
>> auto startup during initialization. This results in uninitialized memory
>> issue and causes a kernel panic during boot.
>>
>> This patch moves the pcr allocation outside the auto startup function
>> into tpm_chip_register. This ensures that allocated banks are initialized
>> in any case.
>>
>> Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
>> PCR read")
>> Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Thanks for the fix. Kernel boots fine with this fix.
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH] mm/nvdimm: Add is_ioremap_addr and use that to check ioremap address
From: Michael Ellerman @ 2019-07-04 14:23 UTC (permalink / raw)
To: Aneesh Kumar K.V, Andrew Morton
Cc: linux-mm, dan.j.williams, linuxppc-dev, linux-nvdimm
In-Reply-To: <87r2792jq5.fsf@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Mon, 1 Jul 2019 19:10:38 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
>>
>>> Architectures like powerpc use different address range to map ioremap
>>> and vmalloc range. The memunmap() check used by the nvdimm layer was
>>> wrongly using is_vmalloc_addr() to check for ioremap range which fails for
>>> ppc64. This result in ppc64 not freeing the ioremap mapping. The side effect
>>> of this is an unbind failure during module unload with papr_scm nvdimm driver
>>
>> The patch applies to 5.1. Does it need a Fixes: and a Cc:stable?
>
> Actually, we want it to be backported to an older kernel possibly one
> that added papr-scm driver, b5beae5e224f ("powerpc/pseries: Add driver
> for PAPR SCM regions"). But that doesn't apply easily. It does apply
> without conflicts to 5.0
Don't worry about where it applies or doesn't, just tag it with the
correct Fixes: and stable versions and then if it doesn't backport
cleanly then we deal with that later.
cheers
^ permalink raw reply
* Re: ["RFC PATCH" 1/2] powerpc/mm: Fix node look up with numa=off boot
From: Michael Ellerman @ 2019-07-04 14:29 UTC (permalink / raw)
To: Nathan Lynch, Aneesh Kumar K.V
Cc: Vaibhav Jain, paulus, linuxppc-dev, npiggin
In-Reply-To: <878stgsa2r.fsf@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>>> Just checking: do people still need numa=off? Seems like it's a
>>> maintenance burden :-)
>>>
>>
>> That is used in kdump kernel.
>
> I see, thanks.
That doesn't mean it's a good idea :)
Does it actually reduce memory usage much? Last time I dug into the
kdump kernel's usage of weird command line flags none of them really did
anything useful.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm/nvdimm: Add an informative message if we fail to allocate altmap block
From: Michael Ellerman @ 2019-07-04 14:32 UTC (permalink / raw)
To: Aneesh Kumar K.V, Oliver O'Halloran
Cc: Paul Mackerras, linuxppc-dev, Nicholas Piggin
In-Reply-To: <874l46nhtj.fsf@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> "Oliver O'Halloran" <oohall@gmail.com> writes:
>
>> On Sat, Jun 29, 2019 at 5:39 PM Aneesh Kumar K.V
>> <aneesh.kumar@linux.ibm.com> wrote:
>>>
>>> Allocation from altmap area can fail based on vmemmap page size used. Add kernel
>>> info message to indicate the failure. That allows the user to identify whether they
>>> are really using persistent memory reserved space for per-page metadata.
>>>
>>> The message looks like:
>>> [ 136.587212] altmap block allocation failed, falling back to system memory
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>> ---
>>> arch/powerpc/mm/init_64.c | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
>>> index a4e17a979e45..57c0573650dc 100644
>>> --- a/arch/powerpc/mm/init_64.c
>>> +++ b/arch/powerpc/mm/init_64.c
>>> @@ -194,8 +194,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>>> * fail due to alignment issues when using 16MB hugepages, so
>>> * fall back to system memory if the altmap allocation fail.
>>> */
>>> - if (altmap)
>>> + if (altmap) {
>>> p = altmap_alloc_block_buf(page_size, altmap);
>>> + if (!p)
>>
>>> + pr_info("altmap block allocation failed, " \
>>> + "falling back to system memory");
>>
>> I think this is kind of misleading. If you're mapping a large amount
>> of memory you can have most of the vmemmap backing allocated from the
>> altmap and one extra block allocated from normal memory. E.g. If you
>> have 32MB of altmap space, one 16MB block will be allocated from the
>> altmap, but the 2nd 16MB block is probably unusable due to the
>> reserved pages at the start of the altmap. Maybe this should be a
>> pr_debug() so it's only printed along with the "vmemmap_populate ..."
>> message above?
>
> Will switch to pr_debug. What I really wanted was an indication of which
> pfn device failed to allocate per page meata data in the device. But
> we really don't have device details here and we don't end up calling
> this function if there is already a 16MB mapping in DRAM for this area.
>
>>
>> Also, isn't kernel style to keep printf()s, even long ones, on one line?
>
> I was not sure. It do print to kernel log in one line.
It should be one line so it's easy to grep for the error string.
cheers
^ permalink raw reply
* [PATCH 0/2] ftrace: two fixes with func_probes handling
From: Naveen N. Rao @ 2019-07-04 14:34 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, linux-kernel
Two patches addressing bugs in ftrace function probe handling. The first
patch addresses a NULL pointer dereference reported by LTP tests, while
the second one is a trivial patch to address a missing check for return
value, found by code inspection.
- Naveen
Naveen N. Rao (2):
ftrace: Fix NULL pointer dereference in t_probe_next()
ftrace: Check for successful allocation of hash
kernel/trace/ftrace.c | 9 +++++++++
1 file changed, 9 insertions(+)
--
2.22.0
^ permalink raw reply
* [PATCH 1/2] ftrace: Fix NULL pointer dereference in t_probe_next()
From: Naveen N. Rao @ 2019-07-04 14:34 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1562249521.git.naveen.n.rao@linux.vnet.ibm.com>
LTP testsuite on powerpc results in the below crash:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc00000000029d800
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
...
CPU: 68 PID: 96584 Comm: cat Kdump: loaded Tainted: G W
NIP: c00000000029d800 LR: c00000000029dac4 CTR: c0000000001e6ad0
REGS: c0002017fae8ba10 TRAP: 0300 Tainted: G W
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 28022422 XER: 20040000
CFAR: c00000000029d90c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
...
NIP [c00000000029d800] t_probe_next+0x60/0x180
LR [c00000000029dac4] t_mod_start+0x1a4/0x1f0
Call Trace:
[c0002017fae8bc90] [c000000000cdbc40] _cond_resched+0x10/0xb0 (unreliable)
[c0002017fae8bce0] [c0000000002a15b0] t_start+0xf0/0x1c0
[c0002017fae8bd30] [c0000000004ec2b4] seq_read+0x184/0x640
[c0002017fae8bdd0] [c0000000004a57bc] sys_read+0x10c/0x300
[c0002017fae8be30] [c00000000000b388] system_call+0x5c/0x70
The test (ftrace_set_ftrace_filter.sh) is part of ftrace stress tests
and the crash happens when the test does 'cat
$TRACING_PATH/set_ftrace_filter'.
The address points to the second line below, in t_probe_next(), where
filter_hash is dereferenced:
hash = iter->probe->ops.func_hash->filter_hash;
size = 1 << hash->size_bits;
This happens due to a race with register_ftrace_function_probe(). A new
ftrace_func_probe is created and added into the func_probes list in
trace_array under ftrace_lock. However, before initializing the filter,
we drop ftrace_lock, and re-acquire it after acquiring regex_lock. If
another process is trying to read set_ftrace_filter, it will be able to
acquire ftrace_lock during this window and it will end up seeing a NULL
filter_hash.
Fix this by just checking for a NULL filter_hash in t_probe_next(). If
the filter_hash is NULL, then this probe is just being added and we can
simply return from here.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
kernel/trace/ftrace.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 7b037295a1f1..0791eafb693d 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3093,6 +3093,10 @@ t_probe_next(struct seq_file *m, loff_t *pos)
hnd = &iter->probe_entry->hlist;
hash = iter->probe->ops.func_hash->filter_hash;
+
+ if (!hash)
+ return NULL;
+
size = 1 << hash->size_bits;
retry:
--
2.22.0
^ permalink raw reply related
* [PATCH 2/2] ftrace: Check for successful allocation of hash
From: Naveen N. Rao @ 2019-07-04 14:34 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1562249521.git.naveen.n.rao@linux.vnet.ibm.com>
In register_ftrace_function_probe(), we are not checking the return
value of alloc_and_copy_ftrace_hash(). The subsequent call to
ftrace_match_records() may end up dereferencing the same. Add a check to
ensure this doesn't happen.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
kernel/trace/ftrace.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 0791eafb693d..0d5f7d4a4936 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4328,6 +4328,11 @@ register_ftrace_function_probe(char *glob, struct trace_array *tr,
old_hash = *orig_hash;
hash = alloc_and_copy_ftrace_hash(FTRACE_HASH_DEFAULT_BITS, old_hash);
+ if (!hash) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
ret = ftrace_match_records(hash, glob, strlen(glob));
/* Nothing found? */
--
2.22.0
^ permalink raw reply related
* Re: [PATCH V2] mm/ioremap: Probe platform for p4d huge map support
From: Anshuman Khandual @ 2019-07-04 15:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, x86, Peter Zijlstra, Catalin Marinas,
Dave Hansen, Will Deacon, Michal Hocko, linux-mm, Ingo Molnar,
linux-arm-kernel, Andy Lutomirski, Thomas Gleixner, linuxppc-dev,
Kirill A . Shutemov
In-Reply-To: <20190702160630.25de5558e9fe2d7d845f3472@linux-foundation.org>
On 07/03/2019 04:36 AM, Andrew Morton wrote:
> On Fri, 28 Jun 2019 10:50:31 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>> Finishing up what the commit c2febafc67734a ("mm: convert generic code to
>> 5-level paging") started out while levelling up P4D huge mapping support
>> at par with PUD and PMD. A new arch call back arch_ioremap_p4d_supported()
>> is being added which just maintains status quo (P4D huge map not supported)
>> on x86, arm64 and powerpc.
>
> Does this have any runtime effects? If so, what are they and why? If
> not, what's the actual point?
It just finishes up what the previous commit c2febafc67734a ("mm: convert
generic code to 5-level paging") left off with respect p4d based huge page
enablement for ioremap. When HAVE_ARCH_HUGE_VMAP is enabled its just a simple
check from the arch about the support, hence runtime effects are minimal.
^ permalink raw reply
* Re: [PATCH] tpm: fixes uninitialized allocated banks for IBM vtpm driver
From: Michal Suchánek @ 2019-07-04 15:32 UTC (permalink / raw)
To: Sachin Sant
Cc: Nayna Jain, linux-kernel, Mimi Zohar, Jason Gunthorpe,
Jarkko Sakkinen, linux-integrity, George Wilson, linuxppc-dev,
Peter Huewe
In-Reply-To: <0EDE02C7-3716-47A2-B7B0-007025F28567@linux.vnet.ibm.com>
On Thu, 4 Jul 2019 19:26:36 +0530
Sachin Sant <sachinp@linux.vnet.ibm.com> wrote:
> > On 04-Jul-2019, at 5:29 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Wed, 2019-07-03 at 23:32 -0400, Nayna Jain wrote:
> >> The nr_allocated_banks and allocated banks are initialized as part of
> >> tpm_chip_register. Currently, this is done as part of auto startup
> >> function. However, some drivers, like the ibm vtpm driver, do not run
> >> auto startup during initialization. This results in uninitialized memory
> >> issue and causes a kernel panic during boot.
> >>
> >> This patch moves the pcr allocation outside the auto startup function
> >> into tpm_chip_register. This ensures that allocated banks are initialized
> >> in any case.
> >>
> >> Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
> >> PCR read")
> >> Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
> > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
>
> Thanks for the fix. Kernel boots fine with this fix.
>
> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
>
Tested-by: Michal Suchánek <msuchanek@suse.de>
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v5 1/2] powerpc: silence a -Wcast-function-type warning in dawr_write_file_bool
From: Michael Ellerman @ 2019-07-04 15:52 UTC (permalink / raw)
To: Michael Neuling; +Cc: Mathieu Malaterre, hch, mikey, linuxppc-dev
In-Reply-To: <20190604030037.9424-1-mikey@neuling.org>
On Tue, 2019-06-04 at 03:00:36 UTC, Michael Neuling wrote:
> From: Mathieu Malaterre <malat@debian.org>
>
> In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
> option") the following piece of code was added:
>
> smp_call_function((smp_call_func_t)set_dawr, &null_brk, 0);
>
> Since GCC 8 this triggers the following warning about incompatible
> function types:
>
> arch/powerpc/kernel/hw_breakpoint.c:408:21: error: cast between incompatible function types from 'int (*)(struct arch_hw_breakpoint *)' to 'void (*)(void *)' [-Werror=cast-function-type]
>
> Since the warning is there for a reason, and should not be hidden behind
> a cast, provide an intermediate callback function to avoid the warning.
>
> Fixes: c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option")
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/548c54acba5bd1388d50727a9a126a42d0cd4ad0
cheers
^ permalink raw reply
* Re: [PATCH 01/28] powerpc/64s/exception: fix line wrap and semicolon inconsistencies in macros
From: Michael Ellerman @ 2019-07-04 15:52 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20190611143040.7834-2-npiggin@gmail.com>
On Tue, 2019-06-11 at 14:30:13 UTC, Nicholas Piggin wrote:
> By convention, all lines should be separated by a semicolons. Last line
> should have neither semicolon or line wrap.
>
> No generated code change.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4b1f5ccc7cdc89fe208e017f9d40d69cb9e160f4
cheers
^ permalink raw reply
* Re: [PATCH v3 01/25] powerpc/64s/exception: remove H concatenation for EXC_HV variants
From: Michael Ellerman @ 2019-07-04 15:52 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20190622131535.20996-2-npiggin@gmail.com>
On Sat, 2019-06-22 at 13:15:11 UTC, Nicholas Piggin wrote:
> Replace all instances of this with gas macros that test the hsrr
> parameter and use the appropriate register names / labels.
>
> No generated code change.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4508a74a63154fea5c2d36d8ad064273c5ea9608
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64s: Rename PPC_INVALIDATE_ERAT to PPC_ARCH_300_INVALIDATE_ERAT
From: Michael Ellerman @ 2019-07-04 15:52 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin, kvm-ppc
In-Reply-To: <20190623104152.13173-1-npiggin@gmail.com>
On Sun, 2019-06-23 at 10:41:51 UTC, Nicholas Piggin wrote:
> This makes it clear to the caller that it can only be used on POWER9
> and later CPUs.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fe7946ce0808eb0e43711f5db7d2d1599b362d02
cheers
^ permalink raw reply
* Re: [PATCH v3 01/13] powerpc/64s/exception: clean up system call entry
From: Michael Ellerman @ 2019-07-04 15:52 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20190628053332.22366-2-npiggin@gmail.com>
On Fri, 2019-06-28 at 05:33:20 UTC, Nicholas Piggin wrote:
> syscall / hcall entry unnecessarily differs between KVM and non-KVM
> builds. Move the SMT priority instruction to the same location
> (after INTERRUPT_TO_KERNEL).
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b0b2a93da4c95ac808c4c43f24a1873ae3166a1a
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox