* [RFC PATCH 0/6] Provide vcpu dispatch statistics
From: Naveen N. Rao @ 2019-05-06 9:43 UTC (permalink / raw)
To: Michael Ellerman, Nathan Lynch, Mingming Cao, Aneesh Kumar K.V
Cc: linuxppc-dev
This series adds a new procfs file /proc/powerpc/vcpudispatch_stats for
providing statistics around how the LPAR processors are dispatched by
the POWER Hypervisor, in a shared LPAR environment. Patch 6/6 has more
details on how the statistics are gathered.
An example output:
$ sudo cat /proc/powerpc/vcpudispatch_stats
cpu0 6839 4126 0 2683 30 0 6821 18 0
cpu1 2515 1274 0 1229 12 0 2509 6 0
cpu2 2317 1198 0 1109 10 0 2312 5 0
cpu3 2259 1165 0 1088 6 0 2256 3 0
cpu4 2205 1143 0 1056 6 0 2202 3 0
cpu5 2165 1121 0 1038 6 0 2162 3 0
cpu6 2183 1127 0 1050 6 0 2180 3 0
cpu7 2193 1133 0 1052 8 0 2187 6 0
cpu8 2165 1115 0 1032 18 0 2156 9 0
cpu9 2301 1252 0 1033 16 0 2293 8 0
cpu10 2197 1138 0 1041 18 0 2187 10 0
cpu11 2273 1185 0 1062 26 0 2260 13 0
cpu12 2186 1125 0 1043 18 0 2177 9 0
cpu13 2161 1115 0 1030 16 0 2153 8 0
cpu14 2206 1153 0 1033 20 0 2196 10 0
cpu15 2163 1115 0 1032 16 0 2155 8 0
In the output above, for cpu0, we see that there have been 6839 vcpu
dispatches since statistics were enabled. The next 5 numbers represent
dispatch dispersions without taking the vcpu home nodes into account.
- 4126 dispatches were on the same physical cpu as the previous time
- 2683 were on a different core, but within the same chip,
- while 30 times, a vcpu was dispatched on a different chip compared to
its last dispatch.
The next 3 numbers represent statistics in relation to the vcpu home
node. We see that there have been 6821 dispatches in the vcpu home node,
while 18 dispatches were in a different chip.
TODO:
- Consider need for adding cond_resched() in some places.
- More testing, especially on larger machines.
- Naveen
Naveen N. Rao (6):
powerpc/pseries: Use macros for referring to the DTL enable mask
powerpc/pseries: Do not save the previous DTL mask value
powerpc/pseries: Factor out DTL buffer allocation and registration
routines
powerpc/pseries: Generalize hcall_vphn()
powerpc/pseries: Introduce helpers to gatekeep DTLB usage
powerpc/pseries: Provide vcpu dispatch statistics
arch/powerpc/include/asm/lppaca.h | 11 +
arch/powerpc/include/asm/plpar_wrappers.h | 4 +
arch/powerpc/include/asm/topology.h | 4 +
arch/powerpc/mm/book3s64/vphn.h | 8 +
arch/powerpc/mm/numa.c | 139 +++++-
arch/powerpc/platforms/pseries/dtl.c | 22 +-
arch/powerpc/platforms/pseries/lpar.c | 543 +++++++++++++++++++++-
arch/powerpc/platforms/pseries/setup.c | 34 +-
8 files changed, 690 insertions(+), 75 deletions(-)
--
2.21.0
^ permalink raw reply
* [RFC PATCH 1/6] powerpc/pseries: Use macros for referring to the DTL enable mask
From: Naveen N. Rao @ 2019-05-06 9:43 UTC (permalink / raw)
To: Michael Ellerman, Nathan Lynch, Mingming Cao, Aneesh Kumar K.V
Cc: linuxppc-dev
In-Reply-To: <cover.1557134488.git.naveen.n.rao@linux.vnet.ibm.com>
Introduce macros to encode the DTL enable mask fields and use those
instead of hardcoding numbers.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/lppaca.h | 11 +++++++++++
arch/powerpc/platforms/pseries/dtl.c | 8 +-------
arch/powerpc/platforms/pseries/lpar.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 2 +-
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h b/arch/powerpc/include/asm/lppaca.h
index 7c23ce8a5a4c..2c7e31187726 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -154,6 +154,17 @@ struct dtl_entry {
#define DISPATCH_LOG_BYTES 4096 /* bytes per cpu */
#define N_DISPATCH_LOG (DISPATCH_LOG_BYTES / sizeof(struct dtl_entry))
+/*
+ * Dispatch trace log event enable mask:
+ * 0x1: voluntary virtual processor waits
+ * 0x2: time-slice preempts
+ * 0x4: virtual partition memory page faults
+ */
+#define DTL_LOG_CEDE 0x1
+#define DTL_LOG_PREEMPT 0x2
+#define DTL_LOG_FAULT 0x4
+#define DTL_LOG_ALL (DTL_LOG_CEDE | DTL_LOG_PREEMPT | DTL_LOG_FAULT)
+
extern struct kmem_cache *dtl_cache;
/*
diff --git a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
index ef6595153642..051ea2de1e1a 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -40,13 +40,7 @@ struct dtl {
};
static DEFINE_PER_CPU(struct dtl, cpu_dtl);
-/*
- * Dispatch trace log event mask:
- * 0x7: 0x1: voluntary virtual processor waits
- * 0x2: time-slice preempts
- * 0x4: virtual partition memory page faults
- */
-static u8 dtl_event_mask = 0x7;
+static u8 dtl_event_mask = DTL_LOG_ALL;
/*
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 1034ef1fe2b4..23f2ac6793b7 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -126,7 +126,7 @@ void vpa_init(int cpu)
pr_err("WARNING: DTL registration of cpu %d (hw %d) "
"failed with %ld\n", smp_processor_id(),
hwcpu, ret);
- lppaca_of(cpu).dtl_enable_mask = 2;
+ lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
}
}
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index e4f0dfd4ae33..fabaefff8399 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -316,7 +316,7 @@ static int alloc_dispatch_logs(void)
pr_err("WARNING: DTL registration of cpu %d (hw %d) failed "
"with %d\n", smp_processor_id(),
hard_smp_processor_id(), ret);
- get_paca()->lppaca_ptr->dtl_enable_mask = 2;
+ get_paca()->lppaca_ptr->dtl_enable_mask = DTL_LOG_PREEMPT;
return 0;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3 00/26] compat_ioctl: cleanups
From: Andy Shevchenko @ 2019-05-06 9:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux NVMe Mailinglist, linux-iio, linux-remoteproc, linux-fbdev,
dri-devel, Platform Driver, linux-ide,
open list:MEMORY TECHNOLOGY..., sparclinux, linux1394-devel,
devel, linux-s390, linux-scsi, linux-bluetooth, y2038, qat-linux,
amd-gfx, linux-input, Marcel Holtmann, Linux Media Mailing List,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
ALSA Development Mailing List, James E.J. Bottomley,
Alexander Viro, ceph-devel, linux-arm Mailing List, Karsten Keil,
Martin K. Petersen, Greg Kroah-Hartman, USB,
open list:TI WILINK WIRELES..., Linux Kernel Mailing List,
open list:HFI1 DRIVER, linux-crypto, netdev, Linux FS Devel,
linux-integrity, open list:LINUX FOR POWERPC PA SEMI PWRFICIENT,
David S. Miller, linux-btrfs, linux-ppp
In-Reply-To: <20190416202013.4034148-1-arnd@arndb.de>
On Tue, Apr 16, 2019 at 11:23 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> Hi Al,
>
> It took me way longer than I had hoped to revisit this series, see
> https://lore.kernel.org/lkml/20180912150142.157913-1-arnd@arndb.de/
> for the previously posted version.
>
> I've come to the point where all conversion handlers and most
> COMPATIBLE_IOCTL() entries are gone from this file, but for
> now, this series only has the parts that have either been reviewed
> previously, or that are simple enough to include.
>
> The main missing piece is the SG_IO/SG_GET_REQUEST_TABLE conversion.
> I'll post the patches I made for that later, as they need more
> testing and review from the scsi maintainers.
>
> I hope you can still take these for the coming merge window, unless
> new problems come up.
> drivers/platform/x86/wmi.c | 2 +-
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/powernv: remove the unused pnv_pci_set_p2p function
From: Christoph Hellwig @ 2019-05-06 9:02 UTC (permalink / raw)
To: Frederic Barrat; +Cc: linuxppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <99c4c4a9-8a18-61ed-174a-9ffaec3d2e44@linux.ibm.com>
On Mon, May 06, 2019 at 10:46:11AM +0200, Frederic Barrat wrote:
> Hi,
>
> The PCI p2p and tunnel code is used by the Mellanox CX5 driver, at least
> their latest, out of tree version, which is used for CORAL. My
> understanding is that they'll upstream it at some point, though I don't
> know what their schedule is like.
As said before, we only keep exports in tree for in-tree users. If the
CX5 driver grows special P2P support it will have to use the proper
existing kernel infrastructure for that anyway.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/powernv: remove the unused pnv_pci_set_p2p function
From: Frederic Barrat @ 2019-05-06 8:46 UTC (permalink / raw)
To: Christoph Hellwig, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev
In-Reply-To: <20190426124917.23789-2-hch@lst.de>
Hi,
The PCI p2p and tunnel code is used by the Mellanox CX5 driver, at least
their latest, out of tree version, which is used for CORAL. My
understanding is that they'll upstream it at some point, though I don't
know what their schedule is like.
Fred
Le 26/04/2019 à 14:49, Christoph Hellwig a écrit :
> This function has never been used since it has been added to the tree.
> We also now have proper PCIe P2P APIs in the core kernel, and any new
> P2P support should be using those.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/powerpc/include/asm/opal.h | 2 -
> arch/powerpc/include/asm/pnv-pci.h | 2 -
> arch/powerpc/platforms/powernv/opal-call.c | 1 -
> arch/powerpc/platforms/powernv/pci.c | 74 ----------------------
> arch/powerpc/platforms/powernv/pci.h | 5 --
> 5 files changed, 84 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index a55b01c90bb1..16c67f4eeb71 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -279,8 +279,6 @@ int64_t opal_xive_allocate_irq(uint32_t chip_id);
> int64_t opal_xive_free_irq(uint32_t girq);
> int64_t opal_xive_sync(uint32_t type, uint32_t id);
> int64_t opal_xive_dump(uint32_t type, uint32_t id);
> -int64_t opal_pci_set_p2p(uint64_t phb_init, uint64_t phb_target,
> - uint64_t desc, uint16_t pe_number);
>
> int64_t opal_imc_counters_init(uint32_t type, uint64_t address,
> uint64_t cpu_pir);
> diff --git a/arch/powerpc/include/asm/pnv-pci.h b/arch/powerpc/include/asm/pnv-pci.h
> index 630eb8b1b7ed..9fcb0bc462c6 100644
> --- a/arch/powerpc/include/asm/pnv-pci.h
> +++ b/arch/powerpc/include/asm/pnv-pci.h
> @@ -26,8 +26,6 @@ extern int pnv_pci_get_presence_state(uint64_t id, uint8_t *state);
> extern int pnv_pci_get_power_state(uint64_t id, uint8_t *state);
> extern int pnv_pci_set_power_state(uint64_t id, uint8_t state,
> struct opal_msg *msg);
> -extern int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target,
> - u64 desc);
>
> extern int pnv_pci_enable_tunnel(struct pci_dev *dev, uint64_t *asnind);
> extern int pnv_pci_disable_tunnel(struct pci_dev *dev);
> diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c
> index daad8c45c8e7..a89f0e31b468 100644
> --- a/arch/powerpc/platforms/powernv/opal-call.c
> +++ b/arch/powerpc/platforms/powernv/opal-call.c
> @@ -267,7 +267,6 @@ OPAL_CALL(opal_npu_map_lpar, OPAL_NPU_MAP_LPAR);
> OPAL_CALL(opal_imc_counters_init, OPAL_IMC_COUNTERS_INIT);
> OPAL_CALL(opal_imc_counters_start, OPAL_IMC_COUNTERS_START);
> OPAL_CALL(opal_imc_counters_stop, OPAL_IMC_COUNTERS_STOP);
> -OPAL_CALL(opal_pci_set_p2p, OPAL_PCI_SET_P2P);
> OPAL_CALL(opal_get_powercap, OPAL_GET_POWERCAP);
> OPAL_CALL(opal_set_powercap, OPAL_SET_POWERCAP);
> OPAL_CALL(opal_get_power_shift_ratio, OPAL_GET_POWER_SHIFT_RATIO);
> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
> index ef9448a907c6..8d28f2932c3b 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -38,7 +38,6 @@
> #include "powernv.h"
> #include "pci.h"
>
> -static DEFINE_MUTEX(p2p_mutex);
> static DEFINE_MUTEX(tunnel_mutex);
>
> int pnv_pci_get_slot_id(struct device_node *np, uint64_t *id)
> @@ -861,79 +860,6 @@ void pnv_pci_dma_bus_setup(struct pci_bus *bus)
> }
> }
>
> -int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target, u64 desc)
> -{
> - struct pci_controller *hose;
> - struct pnv_phb *phb_init, *phb_target;
> - struct pnv_ioda_pe *pe_init;
> - int rc;
> -
> - if (!opal_check_token(OPAL_PCI_SET_P2P))
> - return -ENXIO;
> -
> - hose = pci_bus_to_host(initiator->bus);
> - phb_init = hose->private_data;
> -
> - hose = pci_bus_to_host(target->bus);
> - phb_target = hose->private_data;
> -
> - pe_init = pnv_ioda_get_pe(initiator);
> - if (!pe_init)
> - return -ENODEV;
> -
> - /*
> - * Configuring the initiator's PHB requires to adjust its
> - * TVE#1 setting. Since the same device can be an initiator
> - * several times for different target devices, we need to keep
> - * a reference count to know when we can restore the default
> - * bypass setting on its TVE#1 when disabling. Opal is not
> - * tracking PE states, so we add a reference count on the PE
> - * in linux.
> - *
> - * For the target, the configuration is per PHB, so we keep a
> - * target reference count on the PHB.
> - */
> - mutex_lock(&p2p_mutex);
> -
> - if (desc & OPAL_PCI_P2P_ENABLE) {
> - /* always go to opal to validate the configuration */
> - rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id,
> - desc, pe_init->pe_number);
> -
> - if (rc != OPAL_SUCCESS) {
> - rc = -EIO;
> - goto out;
> - }
> -
> - pe_init->p2p_initiator_count++;
> - phb_target->p2p_target_count++;
> - } else {
> - if (!pe_init->p2p_initiator_count ||
> - !phb_target->p2p_target_count) {
> - rc = -EINVAL;
> - goto out;
> - }
> -
> - if (--pe_init->p2p_initiator_count == 0)
> - pnv_pci_ioda2_set_bypass(pe_init, true);
> -
> - if (--phb_target->p2p_target_count == 0) {
> - rc = opal_pci_set_p2p(phb_init->opal_id,
> - phb_target->opal_id, desc,
> - pe_init->pe_number);
> - if (rc != OPAL_SUCCESS) {
> - rc = -EIO;
> - goto out;
> - }
> - }
> - }
> - rc = 0;
> -out:
> - mutex_unlock(&p2p_mutex);
> - return rc;
> -}
> -EXPORT_SYMBOL_GPL(pnv_pci_set_p2p);
> -
> struct device_node *pnv_pci_get_phb_node(struct pci_dev *dev)
> {
> struct pci_controller *hose = pci_bus_to_host(dev->bus);
> diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
> index 8e36da379252..fbec1c76d7a7 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -78,9 +78,6 @@ struct pnv_ioda_pe {
> struct pnv_ioda_pe *master;
> struct list_head slaves;
>
> - /* PCI peer-to-peer*/
> - int p2p_initiator_count;
> -
> /* Link in list of PE#s */
> struct list_head list;
> };
> @@ -171,8 +168,6 @@ struct pnv_phb {
> /* PHB and hub diagnostics */
> unsigned int diag_data_size;
> u8 *diag_data;
> -
> - int p2p_target_count;
> };
>
> extern struct pci_ops pnv_pci_ops;
>
^ permalink raw reply
* [PATCH] powerpc/mm: fix section mismatch for setup_kup()
From: Christophe Leroy @ 2019-05-06 8:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
commit b28c97505eb1 ("powerpc/64: Setup KUP on secondary CPUs")
moved setup_kup() out of the __init section. As stated in that commit,
"this is only for 64-bit". But this function is also used on PPC32,
where the two functions called by setup_kup() are in the __init
section, so setup_kup() has to either be kept in the __init
section on PPC32 or marked __ref.
This patch marks it __ref, it fixes the below build warnings.
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x169ec): Section mismatch in reference from the function setup_kup() to the function .init.text:setup_kuep()
The function setup_kup() references
the function __init setup_kuep().
This is often because setup_kup lacks a __init
annotation or the annotation of setup_kuep is wrong.
WARNING: vmlinux.o(.text+0x16a04): Section mismatch in reference from the function setup_kup() to the function .init.text:setup_kuap()
The function setup_kup() references
the function __init setup_kuap().
This is often because setup_kup lacks a __init
annotation or the annotation of setup_kuap is wrong.
Fixes: b28c97505eb1 ("powerpc/64: Setup KUP on secondary CPUs")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/init-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
index 6ea5607fc564..3bcae9e5e954 100644
--- a/arch/powerpc/mm/init-common.c
+++ b/arch/powerpc/mm/init-common.c
@@ -45,7 +45,7 @@ static int __init parse_nosmap(char *p)
}
early_param("nosmap", parse_nosmap);
-void setup_kup(void)
+void __ref setup_kup(void)
{
setup_kuep(disable_kuep);
setup_kuap(disable_kuap);
--
2.13.3
^ permalink raw reply related
* Re: [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS
From: Ingo Molnar @ 2019-05-06 7:48 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Nick Desaulniers, Arnd Bergmann, x86, Will Deacon, linux-kernel,
Linus Torvalds, Jason Baron, Ingo Molnar, Andy Lutomirski,
Andrew Morton, linuxppc-dev, Nathan Chancellor, linux-arm-kernel
In-Reply-To: <25dfde77-fdad-0b99-75ec-4ba480058970@rasmusvillemoes.dk>
* Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> I _am_ bending the C rules a bit with the "extern some_var; asm
> volatile(".section some_section\nsome_var: blabla");". I should
> probably ask on the gcc list whether this way of defining a local
> symbol in inline assembly and referring to it from C is supposed to
> work, or it just happens to work by chance.
Doing that would be rather useful I think.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH V4] ASoC: fsl_esai: Add pm runtime function
From: Mark Brown @ 2019-05-06 3:53 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com,
linux-kernel@vger.kernel.org, Nicolin Chen,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VE1PR04MB64794DF2979F3AD350A9EB3DE3370@VE1PR04MB6479.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
On Sun, May 05, 2019 at 03:28:59AM +0000, S.j. Wang wrote:
> We find that maybe it is caused by the Transfer-Encoding format.
> We sent the patch by the --transfer-encoding=8bit, but in the receiver side
> it shows:
]
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: base64
> It may be caused by our company's mail server. We are checking...
Ah, that looks likely... not sure I have any great suggestions for how
to resolve it but at least it looks like progress on figuring out the
cause, I haven't been able to see anything wrong locally.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS
From: Rasmus Villemoes @ 2019-05-06 7:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: Nick Desaulniers, Arnd Bergmann, x86, Will Deacon, linux-kernel,
Linus Torvalds, Jason Baron, Ingo Molnar, Andy Lutomirski,
Andrew Morton, linuxppc-dev, Nathan Chancellor, linux-arm-kernel
In-Reply-To: <20190506070544.GA66463@gmail.com>
On 06/05/2019 09.05, Ingo Molnar wrote:
>
>
> It's sad to see such nice data footprint savings go the way of the dodo
> just because GCC 4.8 is buggy.
>
> The current compatibility cut-off is GCC 4.6:
>
> GNU C 4.6 gcc --version
>
> Do we know where the GCC bug was fixed, was it in GCC 4.9?
Not sure. The report was from a build on CentOS with gcc 4.8.5, so I
tried installing the gcc-4.8 package on my Ubuntu machine and could
reproduce. Then I tried installed gcc-4.9, and after disabling
CONFIG_RETPOLINE (both CentOS and Ubuntu carry backported retpoline
support in their 4.8, but apparently not 4.9), I could see that the
problem was gone. But whether it's gone because it no longer elides an
asm volatile() on a code path it otherwise emits code for, or because it
simply doesn't emit the unused static inline() at all I don't know.
I thought 0day also tested a range of supported compiler versions, so I
was rather surprised at getting this report at all. But I suppose the
arch/config matrix is already pretty huge. Anyway, the bug certainly
doesn't exist in any of the gcc versions 0day does test.
I _am_ bending the C rules a bit with the "extern some_var; asm
volatile(".section some_section\nsome_var: blabla");". I should probably
ask on the gcc list whether this way of defining a local symbol in
inline assembly and referring to it from C is supposed to work, or it
just happens to work by chance.
Rasmus
^ permalink raw reply
* Re: [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS
From: Ingo Molnar @ 2019-05-06 7:05 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Nick Desaulniers, Arnd Bergmann, x86, Will Deacon, linux-kernel,
Linus Torvalds, Jason Baron, Ingo Molnar, Andy Lutomirski,
Andrew Morton, linuxppc-dev, Nathan Chancellor, linux-arm-kernel
In-Reply-To: <1afb0702-3cc5-ba4f-2bdd-604d9da2b846@rasmusvillemoes.dk>
* Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> On 09/04/2019 23.25, Rasmus Villemoes wrote:
>
> > While refreshing these patches, which were orignally just targeted at
> > x86-64, it occured to me that despite the implementation relying on
> > inline asm, there's nothing x86 specific about it, and indeed it seems
> > to work out-of-the-box for ppc64 and arm64 as well, but those have
> > only been compile-tested.
>
> So, apart from the Clang build failures for non-x86, I now also got a
> report that gcc 4.8 miscompiles this stuff in some cases [1], even for
> x86 - gcc 4.9 does not seem to have the problem. So, given that the 5.2
> merge window just opened, I suppose this is the point where I should
> pull the plug on this experiment :(
>
> Rasmus
>
> [1] Specifically, the problem manifested in net/ipv4/tcp_input.c: Both
> uses of the static inline inet_csk_clear_xmit_timer() pass a
> compile-time constant 'what', so the ifs get folded away and both uses
> are completely inlined. Yet, gcc still decides to emit a copy of the
> final 'else' branch of inet_csk_clear_xmit_timer() as its own
> inet_csk_reset_xmit_timer.part.55 function, which is of course unused.
> And despite the asm() that defines the ddebug descriptor being an "asm
> volatile", gcc thinks it's fine to elide that (the code path is
> unreachable, after all....), so the entire asm for that function is
>
> .section .text.unlikely
> .type inet_csk_reset_xmit_timer.part.55, @function
> inet_csk_reset_xmit_timer.part.55:
> movq $.LC1, %rsi #,
> movq $__UNIQUE_ID_ddebug160, %rdi #,
> xorl %eax, %eax #
> jmp __dynamic_pr_debug #
> .size inet_csk_reset_xmit_timer.part.55,
> .-inet_csk_reset_xmit_timer.part.55
>
> which of course fails to link since the symbol __UNIQUE_ID_ddebug160 is
> nowhere defined.
It's sad to see such nice data footprint savings go the way of the dodo
just because GCC 4.8 is buggy.
The current compatibility cut-off is GCC 4.6:
GNU C 4.6 gcc --version
Do we know where the GCC bug was fixed, was it in GCC 4.9?
According to the GCC release dates:
https://www.gnu.org/software/gcc/releases.html
4.8.0 was released in early-2013, while 4.9.0 was released in early-2014.
So the tooling compatibility window for latest upstream would narrow from
~6 years to ~5 years.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] EDAC, mpc85xx: Prevent building as a module
From: Johannes Thumshirn @ 2019-05-06 6:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-kernel, linuxppc-dev, james.morse, bp, mchehab, linux-edac
In-Reply-To: <20190502141941.12927-1-mpe@ellerman.id.au>
Acked-by: Johannes Thumshirn <jth@kernel.org>
--
Johannes Thumshirn SUSE Labs Filesystems
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS
From: Rasmus Villemoes @ 2019-05-06 6:48 UTC (permalink / raw)
To: Rasmus Villemoes, Andrew Morton
Cc: Nick Desaulniers, Arnd Bergmann, x86, Will Deacon, linux-kernel,
Jason Baron, Ingo Molnar, Nathan Chancellor, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20190409212517.7321-1-linux@rasmusvillemoes.dk>
On 09/04/2019 23.25, Rasmus Villemoes wrote:
> While refreshing these patches, which were orignally just targeted at
> x86-64, it occured to me that despite the implementation relying on
> inline asm, there's nothing x86 specific about it, and indeed it seems
> to work out-of-the-box for ppc64 and arm64 as well, but those have
> only been compile-tested.
So, apart from the Clang build failures for non-x86, I now also got a
report that gcc 4.8 miscompiles this stuff in some cases [1], even for
x86 - gcc 4.9 does not seem to have the problem. So, given that the 5.2
merge window just opened, I suppose this is the point where I should
pull the plug on this experiment :(
Rasmus
[1] Specifically, the problem manifested in net/ipv4/tcp_input.c: Both
uses of the static inline inet_csk_clear_xmit_timer() pass a
compile-time constant 'what', so the ifs get folded away and both uses
are completely inlined. Yet, gcc still decides to emit a copy of the
final 'else' branch of inet_csk_clear_xmit_timer() as its own
inet_csk_reset_xmit_timer.part.55 function, which is of course unused.
And despite the asm() that defines the ddebug descriptor being an "asm
volatile", gcc thinks it's fine to elide that (the code path is
unreachable, after all....), so the entire asm for that function is
.section .text.unlikely
.type inet_csk_reset_xmit_timer.part.55, @function
inet_csk_reset_xmit_timer.part.55:
movq $.LC1, %rsi #,
movq $__UNIQUE_ID_ddebug160, %rdi #,
xorl %eax, %eax #
jmp __dynamic_pr_debug #
.size inet_csk_reset_xmit_timer.part.55,
.-inet_csk_reset_xmit_timer.part.55
which of course fails to link since the symbol __UNIQUE_ID_ddebug160 is
nowhere defined.
^ permalink raw reply
* [PATCH] powerpc/mm: fix redundant inclusion of pgtable-frag.o in Makefile
From: Christophe Leroy @ 2019-05-06 6:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
The patch identified below added pgtable-frag.o to obj-y
but some merge witchery kept it also for obj-CONFIG_PPC_BOOK3S_64
This patch clears the duplication.
Fixes: 737b434d3d55 ("powerpc/mm: convert Book3E 64 to pte_fragment")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 7a7527116c3a..0f499db315d6 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -12,7 +12,6 @@ obj-y := fault.o mem.o pgtable.o mmap.o \
obj-$(CONFIG_PPC_MMU_NOHASH) += nohash/
obj-$(CONFIG_PPC_BOOK3S_32) += book3s32/
obj-$(CONFIG_PPC_BOOK3S_64) += book3s64/
-obj-$(CONFIG_PPC_BOOK3S_64) += pgtable-frag.o
obj-$(CONFIG_NEED_MULTIPLE_NODES) += numa.o
obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v2 03/15] powerpc/mm: convert Book3E 64 to pte_fragment
From: Christophe Leroy @ 2019-05-06 6:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
aneesh.kumar
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c440b242da6de3823c4ef51f35f38405bbd51430.1556293738.git.christophe.leroy@c-s.fr>
Le 26/04/2019 à 17:58, Christophe Leroy a écrit :
> Book3E 64 is the only subarch not using pte_fragment. In order
> to allow refactorisation, this patch converts it to pte_fragment.
>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/include/asm/mmu_context.h | 6 -----
> arch/powerpc/include/asm/nohash/64/mmu.h | 4 +++-
> arch/powerpc/include/asm/nohash/64/pgalloc.h | 33 ++++++++++------------------
> arch/powerpc/mm/Makefile | 4 ++--
> arch/powerpc/mm/mmu_context.c | 2 +-
> 5 files changed, 18 insertions(+), 31 deletions(-)
>
[...]
> diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
> index 3c1bd9fa23cd..138c772d58d1 100644
> --- a/arch/powerpc/mm/Makefile
> +++ b/arch/powerpc/mm/Makefile
> @@ -9,6 +9,7 @@ CFLAGS_REMOVE_slb.o = $(CC_FLAGS_FTRACE)
>
> obj-y := fault.o mem.o pgtable.o mmap.o \
> init_$(BITS).o pgtable_$(BITS).o \
> + pgtable-frag.o \
> init-common.o mmu_context.o drmem.o
> obj-$(CONFIG_PPC_MMU_NOHASH) += mmu_context_nohash.o tlb_nohash.o \
> tlb_nohash_low.o
> @@ -17,8 +18,7 @@ hash64-$(CONFIG_PPC_NATIVE) := hash_native_64.o
> obj-$(CONFIG_PPC_BOOK3E_64) += pgtable-book3e.o
> obj-$(CONFIG_PPC_BOOK3S_64) += pgtable-hash64.o hash_utils_64.o slb.o \
> $(hash64-y) mmu_context_book3s64.o \
> - pgtable-book3s64.o pgtable-frag.o
> -obj-$(CONFIG_PPC32) += pgtable-frag.o
> + pgtable-book3s64.o
Looks like the removal of pgtable-frag.o for CONFIG_PPC_BOOK3S_64 didn't
survive the merge.
Will send a patch to fix that.
Christophe
> obj-$(CONFIG_PPC_RADIX_MMU) += pgtable-radix.o tlb-radix.o
> obj-$(CONFIG_PPC_BOOK3S_32) += ppc_mmu_32.o hash_low_32.o mmu_context_hash32.o
> obj-$(CONFIG_PPC_BOOK3S) += tlb_hash$(BITS).o
^ permalink raw reply
* [PATCH] powerpc/kasan: add missing/lost Makefile
From: Christophe Leroy @ 2019-05-06 6:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
For unknown reason, the new Makefile added via the KASAN suppot patch
didn't land into arch/powerpc/mm/kasan/
This patch restores it.
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/kasan/Makefile | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 arch/powerpc/mm/kasan/Makefile
diff --git a/arch/powerpc/mm/kasan/Makefile b/arch/powerpc/mm/kasan/Makefile
new file mode 100644
index 000000000000..6577897673dd
--- /dev/null
+++ b/arch/powerpc/mm/kasan/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+KASAN_SANITIZE := n
+
+obj-$(CONFIG_PPC32) += kasan_init_32.o
--
2.13.3
^ permalink raw reply related
* [PATCH] powerpc/mm: Fix makefile for KASAN
From: Christophe Leroy @ 2019-05-06 6:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In commit 17312f258cf6 ("powerpc/mm: Move book3s32 specifics in
subdirectory mm/book3s64"), ppc_mmu_32.c was moved and renamed.
This patch fixes Makefiles to disable KASAN instrumentation on
the new name and location.
Fixes: f072015c7b74 ("powerpc: disable KASAN instrumentation on early/critical files.")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/Makefile | 6 ------
arch/powerpc/mm/book3s32/Makefile | 6 ++++++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index d8c0ce9b2557..7a7527116c3a 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -5,12 +5,6 @@
ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
-KASAN_SANITIZE_ppc_mmu_32.o := n
-
-ifdef CONFIG_KASAN
-CFLAGS_ppc_mmu_32.o += -DDISABLE_BRANCH_PROFILING
-endif
-
obj-y := fault.o mem.o pgtable.o mmap.o \
init_$(BITS).o pgtable_$(BITS).o \
pgtable-frag.o \
diff --git a/arch/powerpc/mm/book3s32/Makefile b/arch/powerpc/mm/book3s32/Makefile
index a4e217d0f3b7..1732eaa740a9 100644
--- a/arch/powerpc/mm/book3s32/Makefile
+++ b/arch/powerpc/mm/book3s32/Makefile
@@ -1,3 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
+KASAN_SANITIZE_mmu.o := n
+
+ifdef CONFIG_KASAN
+CFLAGS_mmu.o += -DDISABLE_BRANCH_PROFILING
+endif
+
obj-y += mmu.o hash_low.o mmu_context.o tlb.o
--
2.13.3
^ permalink raw reply related
* Re: [PATCH kernel] prom_init: Fetch flatten device tree from the system firmware
From: Alexey Kardashevskiy @ 2019-05-06 2:21 UTC (permalink / raw)
To: David Gibson, Stewart Smith; +Cc: linuxppc-dev, Suraj Jitindar Singh
In-Reply-To: <20190503023511.GI13618@umbus.fritz.box>
On 03/05/2019 12:35, David Gibson wrote:
> On Fri, May 03, 2019 at 10:10:57AM +1000, Stewart Smith wrote:
>> David Gibson <david@gibson.dropbear.id.au> writes:
>>> On Wed, May 01, 2019 at 01:42:21PM +1000, Alexey Kardashevskiy wrote:
>>>> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
>>>> about 8.5sec to fetch the entire device tree via the client interface
>>>> as the DT is traversed twice - for strings blob and for struct blob.
>>>> Also, "getprop" is quite slow too as SLOF stores properties in a linked
>>>> list.
>>>>
>>>> However, since [1] SLOF builds flattened device tree (FDT) for another
>>>> purpose. [2] adds a new "fdt-fetch" client interface for the OS to fetch
>>>> the FDT.
>>>>
>>>> This tries the new method; if not supported, this falls back to
>>>> the old method.
>>>>
>>>> There is a change in the FDT layout - the old method produced
>>>> (reserved map, strings, structs), the new one receives only strings and
>>>> structs from the firmware and adds the final reserved map to the end,
>>>> so it is (fw reserved map, strings, structs, reserved map).
>>>> This still produces the same unflattened device tree.
>>>>
>>>> This merges the reserved map from the firmware into the kernel's reserved
>>>> map. At the moment SLOF generates an empty reserved map so this does not
>>>> change the existing behaviour in regard of reservations.
>>>>
>>>> This supports only v17 onward as only that version provides dt_struct_size
>>>> which works as "fdt-fetch" only produces v17 blobs.
>>>>
>>>> If "fdt-fetch" is not available, the old method of fetching the DT is used.
>>>>
>>>> [1] https://git.qemu.org/?p=SLOF.git;a=commitdiff;h=e6fc84652c9c00
>>>> [2] https://git.qemu.org/?p=SLOF.git;a=commit;h=ecda95906930b80
>>>>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>
>>> Hrm. I've gotta say I'm not terribly convinced that it's worth adding
>>> a new interface we'll need to maintain to save 8s on a somewhat
>>> contrived testcase.
>>
>> 256CPUs aren't that many anymore though. Although I guess that many PCI
>> devices is still a little uncommon.
>
> Yeah, it was the PCI devices I was meaning, not the cpus.
Each node (device, cpu, memory/numa) has a dozen of properties, so any
500 nodes will slow booting down more or less equally.
>
>> A 4 socket POWER8 or POWER9 can easily be that large, and a small test
>> kernel/userspace will boot in ~2.5-4 seconds. So it's possible that
>> the device tree fetch could be surprisingly non-trivial percentage of boot
>> time at least on some machines.
>>
>>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH] powerpc/64s: support nospectre_v2 cmdline option
From: Andrew Donnellan @ 2019-05-06 1:32 UTC (permalink / raw)
To: Christopher M. Riedl, linuxppc-dev
In-Reply-To: <20190505221048.28212-1-cmr@informatik.wtf>
On 6/5/19 8:10 am, Christopher M. Riedl wrote:
> Add support for disabling the kernel implemented spectre v2 mitigation
> (count cache flush on context switch) via the nospectre_v2 cmdline
> option.
>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
> ---
>
> arch/powerpc/kernel/security.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
> index b33bafb8fcea..f7c34745cd0f 100644
> --- a/arch/powerpc/kernel/security.c
> +++ b/arch/powerpc/kernel/security.c
> @@ -28,7 +28,7 @@ static enum count_cache_flush_type count_cache_flush_type = COUNT_CACHE_FLUSH_NO
> bool barrier_nospec_enabled;
> static bool no_nospec;
> static bool btb_flush_enabled;
> -#ifdef CONFIG_PPC_FSL_BOOK3E
> +#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_BOOK3S_64)
> static bool no_spectrev2;
> #endif
>
> @@ -106,7 +106,7 @@ static __init int barrier_nospec_debugfs_init(void)
> device_initcall(barrier_nospec_debugfs_init);
> #endif /* CONFIG_DEBUG_FS */
>
> -#ifdef CONFIG_PPC_FSL_BOOK3E
> +#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_BOOK3S_64)
> static int __init handle_nospectre_v2(char *p)
> {
> no_spectrev2 = true;
> @@ -114,6 +114,9 @@ static int __init handle_nospectre_v2(char *p)
> return 0;
> }
> early_param("nospectre_v2", handle_nospectre_v2);
> +#endif /* CONFIG_PPC_FSL_BOOK3E || CONFIG_PPC_BOOK3S_64 */
> +
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> void setup_spectre_v2(void)
> {
> if (no_spectrev2)
> @@ -391,6 +394,13 @@ static void toggle_count_cache_flush(bool enable)
>
> void setup_count_cache_flush(void)
> {
> + if (no_spectrev2) {
> + if (security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED)
> + || security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED))
> + pr_warn("Spectre v2 mitigations not under software control, can't disable\n");
If one of those ftrs is set, what's the impact of not calling
toggle_count_cache_flush()?
> + return;
> + }
> +
> toggle_count_cache_flush(true);
> }
>
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH] powerpc/book3s/64: check for NULL pointer in pgd_alloc()
From: Rick Lindsley @ 2019-05-06 0:20 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
When the memset code was added to pgd_alloc(), it failed to consider that kmem_cache_alloc() can return NULL. It's uncommon, but not impossible under heavy memory contention.
Signed-off-by: Rick Lindsley <ricklind@vnet.linux.ibm.com>
Fixes: cf266dbcd2a7 ("Zero PGD pages on allocation")
--- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
@@ -81,6 +81,10 @@ static inline pgd_t *pgd_alloc(struct mm
pgd = kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
pgtable_gfp_flags(mm, GFP_KERNEL));
+
+ if (unlikely(!pgd))
+ return pgd;
+
/*
* Don't scan the PGD for pointers, it contains references to PUDs but
* those references are not full pointers and so can't be recognised by
^ permalink raw reply
* [PATCH] powerpc/64s: support nospectre_v2 cmdline option
From: Christopher M. Riedl @ 2019-05-05 22:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Christopher M. Riedl, andrew.donnellan
Add support for disabling the kernel implemented spectre v2 mitigation
(count cache flush on context switch) via the nospectre_v2 cmdline
option.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
---
reference: https://github.com/linuxppc/issues/issues/236
arch/powerpc/kernel/security.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index b33bafb8fcea..f7c34745cd0f 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -28,7 +28,7 @@ static enum count_cache_flush_type count_cache_flush_type = COUNT_CACHE_FLUSH_NO
bool barrier_nospec_enabled;
static bool no_nospec;
static bool btb_flush_enabled;
-#ifdef CONFIG_PPC_FSL_BOOK3E
+#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_BOOK3S_64)
static bool no_spectrev2;
#endif
@@ -106,7 +106,7 @@ static __init int barrier_nospec_debugfs_init(void)
device_initcall(barrier_nospec_debugfs_init);
#endif /* CONFIG_DEBUG_FS */
-#ifdef CONFIG_PPC_FSL_BOOK3E
+#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_BOOK3S_64)
static int __init handle_nospectre_v2(char *p)
{
no_spectrev2 = true;
@@ -114,6 +114,9 @@ static int __init handle_nospectre_v2(char *p)
return 0;
}
early_param("nospectre_v2", handle_nospectre_v2);
+#endif /* CONFIG_PPC_FSL_BOOK3E || CONFIG_PPC_BOOK3S_64 */
+
+#ifdef CONFIG_PPC_FSL_BOOK3E
void setup_spectre_v2(void)
{
if (no_spectrev2)
@@ -391,6 +394,13 @@ static void toggle_count_cache_flush(bool enable)
void setup_count_cache_flush(void)
{
+ if (no_spectrev2) {
+ if (security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED)
+ || security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED))
+ pr_warn("Spectre v2 mitigations not under software control, can't disable\n");
+ return;
+ }
+
toggle_count_cache_flush(true);
}
--
2.21.0
^ permalink raw reply related
* [Bug 203515] [crypto] alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep"
From: bugzilla-daemon @ 2019-05-05 19:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203515-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203515
--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282625
--> https://bugzilla.kernel.org/attachment.cgi?id=282625&action=edit
kernel .config of the final bisect (5.0.0-rc1+, Talos II)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203515] [crypto] alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep"
From: bugzilla-daemon @ 2019-05-05 19:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203515-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203515
--- Comment #3 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282623
--> https://bugzilla.kernel.org/attachment.cgi?id=282623&action=edit
bisect.log
git-bisect found 4e7babba30d820c4195b1d58cf51dce3c22ecf2b as the 1st bad
commit:
# git bisect good | tee -a ~/bisect01.log
4e7babba30d820c4195b1d58cf51dce3c22ecf2b is the first bad commit
commit 4e7babba30d820c4195b1d58cf51dce3c22ecf2b
Author: Eric Biggers <ebiggers@google.com>
Date: Thu Jan 31 23:51:46 2019 -0800
crypto: testmgr - convert skcipher testing to use testvec_configs
Convert alg_test_skcipher() to use the new test framework, adding a list
of testvec_configs to test by default. When the extra self-tests are
enabled, randomly generated testvec_configs are tested as well.
This improves skcipher test coverage mainly because now all algorithms
have a variety of data layouts tested, whereas before each algorithm was
responsible for declaring its own chunked test cases which were often
missing or provided poor test coverage. The new code also tests both
the MAY_SLEEP and !MAY_SLEEP cases, different IV alignments, and buffers
that cross pages.
This has already found a bug in the arm64 ctr-aes-neonbs algorithm.
It would have easily found many past bugs.
I removed the skcipher chunked test vectors that were the same as
non-chunked ones, but left the ones that were unique.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
:040000 040000 c533a4dce0d9954923cd56a69e0d26eeee5324a3
c199b3af7a05160aede1522c4860abae5fbe2716 M crypto
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 203515] [crypto] alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep"
From: bugzilla-daemon @ 2019-05-05 19:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203515-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203515
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Kernel Version|5.1.0-rc7 |5.1.0-rc1
--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
Did some testing, -rc1 is already is affected.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] net: ucc_geth - fix Oops when changing number of buffers in the ring
From: David Miller @ 2019-05-05 17:33 UTC (permalink / raw)
To: christophe.leroy; +Cc: netdev, linuxppc-dev, linux-kernel, leoyang.li
In-Reply-To: <ba66f38ff44b95e82925fd0500eb32fe03895496.1556889892.git.christophe.leroy@c-s.fr>
From: Christophe Leroy <christophe.leroy@c-s.fr>
Date: Fri, 3 May 2019 13:33:23 +0000 (UTC)
> When changing the number of buffers in the RX ring while the interface
> is running, the following Oops is encountered due to the new number
> of buffers being taken into account immediately while their allocation
> is done when opening the device only.
...
> This patch forbids the modification of the number of buffers in the
> ring while the interface is running.
>
> Fixes: ac421852b3a0 ("ucc_geth: add ethtool support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v3] dpaa_eth: fix SG frame cleanup
From: David Miller @ 2019-05-05 17:31 UTC (permalink / raw)
To: laurentiu.tudor
Cc: madalin.bucur, netdev, linux-kernel, stable, leoyang.li,
camelia.groza, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190503130311.9914-1-laurentiu.tudor@nxp.com>
From: laurentiu.tudor@nxp.com
Date: Fri, 3 May 2019 16:03:11 +0300
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> Fix issue with the entry indexing in the sg frame cleanup code being
> off-by-1. This problem showed up when doing some basic iperf tests and
> manifested in traffic coming to a halt.
>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Acked-by: Madalin Bucur <madalin.bucur@nxp.com>
Applied and queued up for -stable.
^ 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