[RFC PATCH] powerpc/fadump: Reservationless firmware assisted dump
From: Mahesh Salgaonkar
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.
In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".
We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump. Fadump can now only capture kernel memory.
Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it.
Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
totalusedfree shared buff/cache available
Mem: 7557 1936822 12 5416725
Swap: 4095 04095
With this patch:
[root@zzxx-yy10 ~]# free -m
totalusedfree shared buff/cache available
Mem: 8133 1947464 12 4757338
Swap: 4095 04095
Changes made here are completely transparent to how fadump has
traditionally worked.
An additional advantage is that this mechanism is immune to DLPAR memory
remove (since the CMA memory cannot be removed).
Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.
TODO:
- Handle case where CMA reservation spans nodes.
Signed-off-by: Ananth N Mavinakayanahalli
Signed-off-by: Mahesh Salgaonkar
---
arch/powerpc/include/asm/fadump.h |3 +
arch/powerpc/kernel/fadump.c | 179 -
2 files changed, 156 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump.h
b/arch/powerpc/include/asm/fadump.h
index 5a23010af600..776cba0baec4 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -119,6 +119,7 @@ struct fadump_mem_struct {
struct fadump_section cpu_state_data;
struct fadump_section hpte_region;
struct fadump_section rmr_region;
+ struct fadump_section metadata_region;
};
/* Firmware-assisted dump configuration details. */
@@ -141,6 +142,8 @@ struct fw_dump {
unsigned long fadump_supported:1;
unsigned long dump_active:1;
unsigned long dump_registered:1;
+ /* flag to indicate fadump metadata area is cma allocated */
+ unsigned long cma_alloc:1;
};
/*
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 3c2c2688918f..5ca0cb1b6028 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -45,11 +46,59 @@
static struct fw_dump fw_dump;
static struct fadump_mem_struct fdm;
static const struct fadump_mem_struct *fdm_active;
+static struct cma *fadump_cma;
static DEFINE_MUTEX(fadump_mutex);
struct fad_crash_memory_ranges crash_memory_ranges[INIT_CRASHMEM_RANGES];
int crash_mem_ranges;
+/**
+ * fadump_cma_reserve() - reserve area for fadump memory reservation
+ *
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the memblock allocator
+ * has been activated.
+ */
+int __init fadump_cma_reserve(void)
+{
+ unsigned long long base, size;
+ int rc;
+
+ if (!fw_dump.fadump_enabled)
+ return 0;
+
+ base = fw_dump.reserve_dump_area_start;
+ size = fw_dump.reserve_dump_area_size;
+ pr_debug("Original reserve area base %ld, size %ld\n",
+ (unsigned long)base >> 20,
+ (unsigned long)size >> 20);
+ if (!size)
+ return 0;
+
+ printk("%s: reserving %ld MiB for firmware-assisted dump area\n"
+ , __func__, (unsigned long)size >> 20);
+ rc = cma_declare_contiguous(base, size, 0, 0, 0, false,
+ "fadump_cma", &fadump_cma);
+ if (rc) {
+ printk(KERN_ERR "fadump: Failed to reserve cma area for "
+ "firmware-assisted dump, %d\n", rc);
+ fw_dump.reserve_dump_area_size = 0;
+ return 0;
+ }
+ /*
+* So we now have cma
Re: [PATCH] cxl: Perform NULL check for 'cxl_afu *' at various places in cxl
Thanks for reviewing this patch Fred, Frederic Barrat writes: > So we are calling functions with an invalid afu argument. We can verify > in the callees the value of the afu pointer, like you're doing here, but > why not tackle it at source and avoid calling the function in the first > place? Couple of reasons: * Having checks for NULL afu at the call sites rather than the functions being called will lead to these checks scattered at more than a few places in code. Many of these functions are called via indirect branch from cxl_backend_ops and have their call sites scattered in the code. Having this check in the called functions is a much smaller change in comparison. * Some of these functions are called are called from outside CXL e.g cxl_dev_context_init(). So putting the NULL check at every caller site might not be possible. * Some funtions need to handle AFU init failures in special way e.g like cxl_vphb_error_detected() need to force a card hotplug so that AFU reinit can be tried. * None of these functions are in any hotpath in the code so having an extra check at the beginning of the code wont have a much performance impact. -- Vaibhav Jain Linux Technology Center, IBM India Pvt. Ltd.
Re: [PATCH kernel] powerpc/npu: Do not try invalidating 32bit table when 64bit table is enabled
I must admit I haven't really looked at the iommu_table_group code in depth so don't fully understand it, but I was wondering why we don't hit this for NVLink1 as well? The error that Skiboot is printing is because the requested page size doesn't match expected so I guess there is a possibility the address might not meet the required alignment (I don't know we don't just check that directly). The reason you don't see this on NVLink1 is that we rely on the kernel to do the TCE invalidate directly rather than via an OPAL call, and the kernel seems to do less checking. So I wonder if there is a bug there as well (invalidate for a mismatched page size/address alignment)? And wether this would also fix that? - Alistair On Tuesday, 13 February 2018 4:51:35 PM AEDT Alexey Kardashevskiy wrote: > GPUs and the corresponding NVLink bridges get different PEs as they have > separate translation validation entries (TVEs). We put these PEs to > the same IOMMU group so they cannot be passed through separately. > So the iommu_table_group_ops::set_window/unset_window for GPUs do set > tables to the NPU PEs as well which means that iommu_table's list of > attached PEs (iommu_table_group_link) has both GPU and NPU PEs linked. > This list is used for TCE cache invalidation. > > The problem is that NPU PE has just a single TVE and can be programmed > to point to 32bit or 64bit windows while GPU PE has two (as any other PCI > device). So we end up having an 32bit iommu_table struct linked to both > PEs even though only the 64bit TCE table cache can be invalidated on NPU. > And a relatively recent skiboot detects this and prints errors. > > This changes GPU's iommu_table_group_ops::set_window/unset_window to make > sure that NPU PE is only linked to the table actually used by the hardware. > If there are two tables used by an IOMMU group, the NPU PE will use > the last programmed one which with the current use scenarios is expected > to be a 64bit one. > > Signed-off-by: Alexey Kardashevskiy > --- > > Do we need BUG_ON(IOMMU_TABLE_GROUP_MAX_TABLES != 2)? > > > This is an example for: > > 0004:04:00.0 3D: NVIDIA Corporation Device 1db1 (rev a1) > 0006:00:00.0 Bridge: IBM Device 04ea (rev 01) > 0006:00:00.1 Bridge: IBM Device 04ea (rev 01) > > Before the patch (npu2_tce_kill messages are from skiboot): > > pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000 > pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000 > pci 0004:04 : [PE# 00] Setting up window#1 > 800..800 pg=1 > pci 0006:00:00.0: [PE# 0d] Setting up window 800..800 > pg=1 > NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1) > NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1) > NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1) > NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1) > NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1) > ... > pci 0004:04 : [PE# 00] Removing DMA window #0 > pci 0006:00:00.0: [PE# 0d] Removing DMA window > pci 0004:04 : [PE# 00] Removing DMA window #1 > pci 0006:00:00.0: [PE# 0d] Removing DMA window > pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000 > pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000 > pci 0004:04 : [PE# 00] Setting up window#1 > 800..800 pg=1 > pci 0006:00:00.0: [PE# 0d] Setting up window 800..800 > pg=1 > > After the patch (no errors here): > > pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000 > pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000 > pci 0004:04 : [PE# 00] Setting up window#1 > 800..800 pg=1 > pci 0006:00:00.0: [PE# 0d] Removing DMA window > pci 0006:00:00.0: [PE# 0d] Setting up window 800..800 > pg=1 > pci 0004:04 : [PE# 00] Removing DMA window #0 > pci 0004:04 : [PE# 00] Removing DMA window #1 > pci 0006:00:00.0: [PE# 0d] Removing DMA window > pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000 > pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000 > pci 0004:04 : [PE# 00] Setting up window#1 > 800..800 pg=1 > pci 0006:00:00.0: [PE# 0d] Removing DMA window > pci 0006:00:00.0: [PE# 0d] Setting up window 800..800 > pg=1 > --- > arch/powerpc/platforms/powernv/pci-ioda.c | 27 --- > 1 file changed, 24 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c > b/arch/powerpc/platforms/powernv/pci-ioda.c > index 496e476..2f91815 100644 > --- a/arch/powerpc/platforms/powernv/pci-ioda.c > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c > @@ -2681,14 +2681,23 @@ static struct pnv_ioda_pe *gpe_table_group_to_npe( > static long pnv_pci_ioda2_npu_set_window(struct iommu_ta
[PATCHv5 3/3] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.
From: Mahesh Salgaonkar
The kernel boot parameter 'nr_cpus=' allows one to specify number of
possible cpus in the system. In the normal scenario the first cpu (cpu0)
that shows up is the boot cpu and hence it gets covered under nr_cpus
limit.
But this assumption will be broken in kdump scenario where kdump kenrel
after a crash can boot up on an non-zero boot cpu. The paca structure
allocation depends on value of nr_cpus and is indexed using logical cpu
ids. This definetly will be an issue if boot cpu id > nr_cpus
This patch modifies allocate_pacas() and smp_setup_cpu_maps() to
accommodate boot cpu for the case where boot_cpuid > nr_cpu_ids.
This change would help to reduce the memory reservation requirement for
kdump on ppc64.
Signed-off-by: Mahesh Salgaonkar
Signed-off-by: Thadeu Lima de Souza Cascardo
Tested-by: Guilherme G. Piccoli
Signed-off-by: Pingfan Liu (separate the logical for
cpu id mapping and stick to the semantics of nr_cpus)
Signed-off-by: Pingfan Liu
---
arch/powerpc/include/asm/paca.h | 3 +++
arch/powerpc/kernel/paca.c | 19 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index b62c310..49ab29d 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -49,6 +49,9 @@ extern unsigned int debug_smp_processor_id(void); /* from
linux/smp.h */
#define get_lppaca() (get_paca()->lppaca_ptr)
#define get_slb_shadow() (get_paca()->slb_shadow_ptr)
+/* Maximum number of threads per core. */
+#defineMAX_SMT 8
+
struct task_struct;
/*
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 95ffedf..9c6f135 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -209,6 +209,7 @@ void __init allocate_pacas(void)
{
u64 limit;
int cpu;
+ unsigned int nr_cpus_aligned;
#ifdef CONFIG_PPC_BOOK3S_64
/*
@@ -220,20 +221,28 @@ void __init allocate_pacas(void)
limit = ppc64_rma_size;
#endif
- paca_size = PAGE_ALIGN(sizeof(struct paca_struct) * nr_cpu_ids);
+ /*
+* Alloc the paca[] align up to SMT threads.
+* This will help us to prepare for a situation where
+* boot cpu id > nr_cpus.
+* We keep the semantics of nr_cpus in kernel cmdline, but
+* waste a bit memory
+*/
+ nr_cpus_aligned = _ALIGN_UP(nr_cpu_ids, MAX_SMT);
+ paca_size = PAGE_ALIGN(sizeof(struct paca_struct) * nr_cpus_aligned);
paca = __va(memblock_alloc_base(paca_size, PAGE_SIZE, limit));
memset(paca, 0, paca_size);
printk(KERN_DEBUG "Allocated %u bytes for %u pacas at %p\n",
- paca_size, nr_cpu_ids, paca);
+ paca_size, nr_cpus_aligned, paca);
- allocate_lppacas(nr_cpu_ids, limit);
+ allocate_lppacas(nr_cpus_aligned, limit);
- allocate_slb_shadows(nr_cpu_ids, limit);
+ allocate_slb_shadows(nr_cpus_aligned, limit);
/* Can't use for_each_*_cpu, as they aren't functional yet */
- for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+ for (cpu = 0; cpu < nr_cpus_aligned; cpu++)
initialise_paca(&paca[cpu], cpu);
}
--
2.7.4
[PATCHv5 2/3] powerpc, cpu: handling the special case when boot_cpuid greater than nr_cpus
For kexec -p, after boot_cpuid is mapping into the range of [0,
threads_per_core), then if nr_cpus is small, we will have the bitmap
[0,..., nr_cpus, ..., boot_cpuid, ...). This patch chooses cpus inside
the range of [boot_cpuid - nr_cpus +1, ..., boot_cpuid] to be online.
With this patch and the next, on a P9 machine with thread_per_core=4,
and set nr_cpus=2 for the crash kernel.
After
taskset -c 11 sh -c "echo c > /proc/sysrq-trigger"
Then
kdump:/sys/devices/system/cpu# cat possible
2-3
kdump:/sys/devices/system/cpu# cat present
2-3
kdump:/sys/devices/system/cpu# cat online
2-3
Signed-off-by: Pingfan Liu
---
arch/powerpc/kernel/setup-common.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index a683ed1..f3aaf9f 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -468,6 +468,7 @@ void __init smp_setup_cpu_maps(void)
int online_num = 0;
int next_cpu = boot_dn_nthreads;
bool btdn_handled = false;
+ int first_threadid = 0;
DBG("smp_setup_cpu_maps()\n");
@@ -497,7 +498,12 @@ void __init smp_setup_cpu_maps(void)
if (boot_cpuid < nthreads &&
be32_to_cpu(intserv[boot_cpuid]) == boot_cpuhwid) {
- cpu = 0;
+ /* choose a bunch of continous threads */
+ if (boot_cpuid > nr_cpu_ids - 1) {
+ first_threadid = boot_cpuid - nr_cpu_ids + 1;
+ }
+ /* keep the mapping of logical and thread */
+ cpu = first_threadid;
btdn_handled = true;
} else if ( !btdn_handled &&
nr_cpu_ids - online_num <= boot_dn_nthreads)
@@ -509,7 +515,8 @@ void __init smp_setup_cpu_maps(void)
}
- for (j = 0; j < nthreads && online_num < nr_cpu_ids; j++) {
+ for (j = first_threadid;
+ j < nthreads && online_num < nr_cpu_ids; j++) {
bool avail;
DBG("thread %d -> cpu %d (hard id %d)\n",
--
2.7.4
[PATCHv5 1/3] powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt
For kexec -p, the boot cpu can be not the cpu0, this causes the problem
to alloc paca[]. In theory, there is no requirement to assign cpu's logical
id as its present seq by device tree. But we have something like
cpu_first_thread_sibling(), which makes assumption on the mapping inside
a core. Hence partially changing the mapping, i.e. unbind the mapping of
core while keep the mapping inside a core. After this patch, boot-cpu
will always be mapped into the range [0,threads_per_core).
Signed-off-by: Pingfan Liu
---
arch/powerpc/include/asm/smp.h | 2 ++
arch/powerpc/kernel/prom.c | 27 ---
arch/powerpc/kernel/setup-common.c | 28 +---
3 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index fac963e..920a927 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -30,6 +30,8 @@
#include
extern int boot_cpuid;
+extern int boot_cpuhwid;
+extern int boot_dn_nthreads;
extern int spinning_secondaries;
extern void cpu_die(void);
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index da67606..aca15c1 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -315,8 +315,7 @@ static int __init early_init_dt_scan_cpus(unsigned long
node,
const __be32 *intserv;
int i, nthreads;
int len;
- int found = -1;
- int found_thread = 0;
+ bool found = false;
/* We are scanning "cpu" nodes only */
if (type == NULL || strcmp(type, "cpu") != 0)
@@ -341,8 +340,12 @@ static int __init early_init_dt_scan_cpus(unsigned long
node,
if (fdt_version(initial_boot_params) >= 2) {
if (be32_to_cpu(intserv[i]) ==
fdt_boot_cpuid_phys(initial_boot_params)) {
- found = boot_cpu_count;
- found_thread = i;
+ /* always map the boot-cpu logical id into the
+* the range of [0, thread_per_core)
+*/
+ boot_cpuid = i;
+ boot_dn_nthreads = nthreads;
+ found = true;
}
} else {
/*
@@ -351,8 +354,11 @@ static int __init early_init_dt_scan_cpus(unsigned long
node,
* off secondary threads.
*/
if (of_get_flat_dt_prop(node,
- "linux,boot-cpu", NULL) != NULL)
- found = boot_cpu_count;
+ "linux,boot-cpu", NULL) != NULL) {
+ boot_cpuid = i;
+ boot_dn_nthreads = nthreads;
+ found = true;
+ }
}
#ifdef CONFIG_SMP
/* logical cpu id is always 0 on UP kernels */
@@ -361,13 +367,12 @@ static int __init early_init_dt_scan_cpus(unsigned long
node,
}
/* Not the boot CPU */
- if (found < 0)
+ if (!found)
return 0;
- DBG("boot cpu: logical %d physical %d\n", found,
- be32_to_cpu(intserv[found_thread]));
- boot_cpuid = found;
- set_hard_smp_processor_id(found, be32_to_cpu(intserv[found_thread]));
+ boot_cpuhwid = be32_to_cpu(intserv[boot_cpuid]);
+ DBG("boot cpu: logical %d physical %d\n", boot_cpuid, boot_cpuhwid);
+ set_hard_smp_processor_id(boot_cpuid, boot_cpuhwid);
/*
* PAPR defines "logical" PVR values for cpus that
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 66f7cc6..a683ed1 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -86,7 +86,11 @@ struct machdep_calls *machine_id;
EXPORT_SYMBOL(machine_id);
int boot_cpuid = -1;
+int boot_cpuhwid = -1;
+int boot_dn_nthreads = -1;
EXPORT_SYMBOL_GPL(boot_cpuid);
+EXPORT_SYMBOL_GPL(boot_cpuhwid);
+EXPORT_SYMBOL_GPL(boot_dn_nthreads);
/*
* These are used in binfmt_elf.c to put aux entries on the stack
@@ -461,6 +465,9 @@ void __init smp_setup_cpu_maps(void)
struct device_node *dn;
int cpu = 0;
int nthreads = 1;
+ int online_num = 0;
+ int next_cpu = boot_dn_nthreads;
+ bool btdn_handled = false;
DBG("smp_setup_cpu_maps()\n");
@@ -488,7 +495,21 @@ void __init smp_setup_cpu_maps(void)
nthreads = len / sizeof(int);
- for (j = 0; j < nthreads && cpu < nr_cpu_ids; j++) {
+ if (boot_cpuid < nthreads &&
+ be32_to_cpu(intserv[boot_cpuid]) == boot_cpuhwid) {
+ cpu = 0;
+ btdn_handled = true;
+
[PATCHv5 0/3] enable nr_cpus for powerpc
This topic has a very long history. It comes from Mahesh Salgaonkar For v3: https://patchwork.ozlabs.org/patch/834860/ I hope we can acquire it for "kexec -p" soon. V4->V5: improve the [1/3] implementation based on Benjamin's suggestion. Mahesh Salgaonkar (1): ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit. Pingfan Liu (2): powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt powerpc, cpu: handling the special case when boot_cpuid greater than nr_cpus arch/powerpc/include/asm/paca.h| 3 +++ arch/powerpc/include/asm/smp.h | 2 ++ arch/powerpc/kernel/paca.c | 19 ++- arch/powerpc/kernel/prom.c | 27 --- arch/powerpc/kernel/setup-common.c | 35 --- 5 files changed, 67 insertions(+), 19 deletions(-) -- 2.7.4
Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h
On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann wrote: > On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani > wrote: >> The file arch/arm64/kernel/process.c needs asm/compat.h also to be >> included directly since this is included conditionally from >> include/compat.h. This does seem to be typical of arm64 as I was not >> completely able to get rid of asm/compat.h includes for arm64 in this >> series. My plan is to have separate patches to get rid of asm/compat.h >> includes for the architectures that are not straight forward to keep >> this series simple. >> I will fix this and update the series. >> > > I ran across the same thing in two more files during randconfig testing on > arm64 now, adding this fixup on top for the moment, but maybe there > is a better way: I was looking at how Al tested his uaccess patches: https://www.spinics.net/lists/linux-fsdevel/msg108752.html He seems to be running the kbuild bot tests on his own git. Is it possible to verify it this way on the 2038 tree? Or, I could host a tree also. Thanks, Deepa
[TESTS] Create 'enabled_flush_types' boot option, and short-circuit LPM
fallback -> fallback:
# dmesg -c | grep rfi-flush
[0.00] rfi-flush (debug): enabled flush types: 0x0
[0.00] rfi-flush: fallback displacement flush available
[0.00] rfi-flush: patched 8 locations (fallback displacement flush)
# echo > /sys/kernel/mobility/migration
# dmesg -c | grep rfi-flush
[ 32.525443] rfi-flush: fallback displacement flush available
[ 32.526269] rfi-flush: patched 8 locations (fallback displacement flush)
fallback -> instructions:
# dmesg -c | grep rfi-flush
[0.00] rfi-flush (debug): enabled flush types: 0x0
[0.00] rfi-flush: fallback displacement flush available
[0.00] rfi-flush: patched 8 locations (fallback displacement flush)
# echo 24 > /sys/kernel/debug/powerpc/rfi_flush
# dmesg -c | grep rfi-flush
[ 30.984247] rfi-flush (debug): enabled flush types: 0xc
# echo > /sys/kernel/mobility/migration
# dmesg -c | grep rfi-flush
[ 51.554357] rfi-flush: fallback displacement flush available
[ 51.554360] rfi-flush: ori type flush available
[ 51.554361] rfi-flush: mttrig type flush available
[ 51.554366] rfi-flush: patched 8 locations (ori+mttrig type flush)
instructions -> instructions:
# dmesg -c | grep rfi-flush
[0.00] rfi-flush (debug): enabled flush types: 0xc
[0.00] rfi-flush: fallback displacement flush available
[0.00] rfi-flush: ori type flush available
[0.00] rfi-flush: mttrig type flush available
[0.00] rfi-flush: patched 8 locations (ori+mttrig type flush)
# echo > /sys/kernel/mobility/migration
# dmesg -c | grep rfi-flush
[ 55.100566] rfi-flush: fallback displacement flush available
[ 55.100570] rfi-flush: ori type flush available
[ 55.100571] rfi-flush: mttrig type flush available
[ 55.100575] rfi-flush: patched 8 locations (ori+mttrig type flush)
instructions -> fallback:
# dmesg -c | grep rfi-flush
[0.00] rfi-flush (debug): enabled flush types: 0xc
[0.00] rfi-flush: fallback displacement flush available
[0.00] rfi-flush: ori type flush available
[0.00] rfi-flush: mttrig type flush available
[0.00] rfi-flush: patched 8 locations (ori+mttrig type flush)
# echo > /sys/kernel/debug/powerpc/rfi_flush
# dmesg -c | grep rfi-flush
[ 18.730782] rfi-flush (debug): enabled flush types: 0x0
# echo > /sys/kernel/mobility/migration
# dmesg -c | grep rfi-flush
[ 27.120071] rfi-flush: fallback displacement flush available
[ 27.120078] rfi-flush: patched 8 locations (fallback displacement flush)
debugfs switch:
# echo 0 > /sys/kernel/debug/powerpc/rfi_flush
# echo 1 > /sys/kernel/debug/powerpc/rfi_flush
# dmesg -c | grep rfi-flush
[ 106.031993] rfi-flush: patched 8 locations (no flush)
[ 109.670966] rfi-flush: patched 8 locations (fallback displacement flush)
ori type only:
# echo 8 > /sys/kernel/debug/powerpc/rfi_flush
# echo 0 > /sys/kernel/debug/powerpc/rfi_flush
# echo 1 > /sys/kernel/debug/powerpc/rfi_flush
# dmesg -c | grep rfi-flush
[ 308.988958] rfi-flush (debug): enabled flush types: 0x4
[ 314.206548] rfi-flush: patched 8 locations (no flush)
[ 316.349916] rfi-flush: patched 8 locations (ori type flush)
mttrig type only:
# echo 16 > /sys/kernel/debug/powerpc/rfi_flush
# echo 0 > /sys/kernel/debug/powerpc/rfi_flush
# echo 1 > /sys/kernel/debug/powerpc/rfi_flush
# dmesg -c | grep rfi-flush
[ 355.993189] rfi-flush (debug): enabled flush types: 0x8
[ 360.644291] rfi-flush: patched 8 locations (no flush)
[ 365.300547] rfi-flush: patched 8 locations (mttrig type flush)
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/setup_64.c| 29 +
arch/powerpc/platforms/pseries/mobility.c | 4
2 files changed, 33 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4ec4a27..9c9568e 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -816,6 +816,24 @@ static void *l1d_flush_fallback_area;
static bool no_rfi_flush;
bool rfi_flush;
+static int __init handle_enabled_flush_types(char *p)
+{
+ int rc;
+ enum l1d_flush_type types;
+
+ rc = kstrtoul(p, 0, (long unsigned int *)&types);
+ if (!rc) {
+ enabled_flush_types = types;
+ pr_info("rfi-flush (debug): enabled flush types: 0x%x\n",
enabled_flush_types);
+ } else {
+ enabled_flush_types = L1D_FLUSH_NONE;
+ pr_info("rfi-flush (debug): enabled flush types is invalid\n");
+ }
+
+ return rc;
+}
+early_param("enabl
[PATCH v3 5/5] rfi-flush: Call setup_rfi_flush() after LPM migration
From: Michael Ellerman
We might have migrated to a machine that uses a different flush type,
or doesn't need flushing at all.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/platforms/pseries/mobility.c | 3 +++
arch/powerpc/platforms/pseries/pseries.h | 2 ++
arch/powerpc/platforms/pseries/setup.c| 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/mobility.c
b/arch/powerpc/platforms/pseries/mobility.c
index 0f7fb71..8a8033a 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -348,6 +348,9 @@ void post_mobility_fixup(void)
printk(KERN_ERR "Post-mobility device tree update "
"failed: %d\n", rc);
+ /* Possibly switch to a new RFI flush type */
+ pseries_setup_rfi_flush();
+
return;
}
diff --git a/arch/powerpc/platforms/pseries/pseries.h
b/arch/powerpc/platforms/pseries/pseries.h
index c73351c..60db2ee 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -108,4 +108,6 @@ static inline unsigned long cmo_get_page_size(void)
int dlpar_workqueue_init(void);
+void pseries_setup_rfi_flush(void);
+
#endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index b20d107..f34f908 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -459,7 +459,7 @@ static void __init find_and_init_phbs(void)
of_pci_check_probe_only();
}
-static void pseries_setup_rfi_flush(void)
+void pseries_setup_rfi_flush(void)
{
struct h_cpu_char_result result;
enum l1d_flush_type types;
--
2.7.4
[PATCH v3 4/5] rfi-flush: Differentiate enabled and patched flush types
Currently the rfi-flush messages print 'Using flush' for all
enabled_flush_types, but that is not necessarily true -- as now the
fallback flush is always enabled on pseries, but the fixup function
overwrites its nop/branch slot with other flush types, if available.
So, replace the 'Using flush' messages with ' flush is
available'.
Also, print the patched flush types in the fixup function, so users
can know what is (not) being used (e.g., the slower, fallback flush,
or no flush type at all if flush is disabled via the debugfs switch).
Suggested-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
P.S.: Michael, you suggested only hunk 1. please feel free to discard
hunk 2 if you don't like it.
arch/powerpc/kernel/setup_64.c| 6 +++---
arch/powerpc/lib/feature-fixups.c | 9 -
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index d60e2f7..4ec4a27 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -884,15 +884,15 @@ static void init_fallback_flush(void)
void setup_rfi_flush(enum l1d_flush_type types, bool enable)
{
if (types & L1D_FLUSH_FALLBACK) {
- pr_info("rfi-flush: Using fallback displacement flush\n");
+ pr_info("rfi-flush: fallback displacement flush available\n");
init_fallback_flush();
}
if (types & L1D_FLUSH_ORI)
- pr_info("rfi-flush: Using ori type flush\n");
+ pr_info("rfi-flush: ori type flush available\n");
if (types & L1D_FLUSH_MTTRIG)
- pr_info("rfi-flush: Using mttrig type flush\n");
+ pr_info("rfi-flush: mttrig type flush available\n");
enabled_flush_types = types;
diff --git a/arch/powerpc/lib/feature-fixups.c
b/arch/powerpc/lib/feature-fixups.c
index 73697c4..35f80ab 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -153,7 +153,14 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
patch_instruction(dest + 2, instrs[2]);
}
- printk(KERN_DEBUG "rfi-flush: patched %d locations\n", i);
+ printk(KERN_DEBUG "rfi-flush: patched %d locations (%s flush)\n", i,
+ (types == L1D_FLUSH_NONE) ? "no" :
+ (types == L1D_FLUSH_FALLBACK) ? "fallback displacement" :
+ (types & L1D_FLUSH_ORI)? (types & L1D_FLUSH_MTTRIG)
+ ? "ori+mttrig type"
+ : "ori type" :
+ (types & L1D_FLUSH_MTTRIG) ? "mttrig type"
+ : "unknown");
}
#endif /* CONFIG_PPC_BOOK3S_64 */
--
2.7.4
[PATCH v3 3/5] rfi-flush: Always enable fallback flush on pseries
From: Michael Ellerman
This ensures the fallback flush area is always allocated on pseries,
so in case a LPAR is migrated from a patched to an unpatched system,
it is possible to enable the fallback flush in the target system.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/platforms/pseries/setup.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index 4642e48..b20d107 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -468,26 +468,18 @@ static void pseries_setup_rfi_flush(void)
/* Enable by default */
enable = true;
+ types = L1D_FLUSH_FALLBACK;
rc = plpar_get_cpu_characteristics(&result);
if (rc == H_SUCCESS) {
- types = L1D_FLUSH_NONE;
-
if (result.character & H_CPU_CHAR_L1D_FLUSH_TRIG2)
types |= L1D_FLUSH_MTTRIG;
if (result.character & H_CPU_CHAR_L1D_FLUSH_ORI30)
types |= L1D_FLUSH_ORI;
- /* Use fallback if nothing set in hcall */
- if (types == L1D_FLUSH_NONE)
- types = L1D_FLUSH_FALLBACK;
-
if ((!(result.behaviour & H_CPU_BEHAV_L1D_FLUSH_PR)) ||
(!(result.behaviour & H_CPU_BEHAV_FAVOUR_SECURITY)))
enable = false;
- } else {
- /* Default to fallback if case hcall is not available */
- types = L1D_FLUSH_FALLBACK;
}
setup_rfi_flush(types, enable);
--
2.7.4
[PATCH v3 2/5] rfi-flush: Make it possible to call setup_rfi_flush() again
From: Michael Ellerman
For PowerVM migration we want to be able to call setup_rfi_flush()
again after we've migrated the partition.
To support that we need to check that we're not trying to allocate the
fallback flush area after memblock has gone away (i.e., boot-time only).
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/kernel/setup_64.c | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 469b7fd..bbcdf92 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -49,7 +49,7 @@ enum l1d_flush_type {
L1D_FLUSH_MTTRIG= 0x8,
};
-void __init setup_rfi_flush(enum l1d_flush_type, bool enable);
+void setup_rfi_flush(enum l1d_flush_type, bool enable);
void do_rfi_flush_fixups(enum l1d_flush_type types);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 3efc01a..d60e2f7 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -860,6 +860,10 @@ static void init_fallback_flush(void)
u64 l1d_size, limit;
int cpu;
+ /* Only allocate the fallback flush area once (at boot time). */
+ if (l1d_flush_fallback_area)
+ return;
+
l1d_size = ppc64_caches.l1d.size;
limit = min(ppc64_bolted_size(), ppc64_rma_size);
@@ -877,7 +881,7 @@ static void init_fallback_flush(void)
}
}
-void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
+void setup_rfi_flush(enum l1d_flush_type types, bool enable)
{
if (types & L1D_FLUSH_FALLBACK) {
pr_info("rfi-flush: Using fallback displacement flush\n");
--
2.7.4
[PATCH v3 1/5] rfi-flush: Move the logic to avoid a redo into the debugfs code
From: Michael Ellerman
rfi_flush_enable() includes a check to see if we're already
enabled (or disabled), and in that case does nothing.
But that means calling setup_rfi_flush() a 2nd time doesn't actually
work, which is a bit confusing.
Move that check into the debugfs code, where it really belongs.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
---
arch/powerpc/kernel/setup_64.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index c388cc3..3efc01a 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -846,9 +846,6 @@ static void do_nothing(void *unused)
void rfi_flush_enable(bool enable)
{
- if (rfi_flush == enable)
- return;
-
if (enable) {
do_rfi_flush_fixups(enabled_flush_types);
on_each_cpu(do_nothing, NULL, 1);
@@ -902,13 +899,19 @@ void __init setup_rfi_flush(enum l1d_flush_type types,
bool enable)
#ifdef CONFIG_DEBUG_FS
static int rfi_flush_set(void *data, u64 val)
{
+ bool enable;
+
if (val == 1)
- rfi_flush_enable(true);
+ enable = true;
else if (val == 0)
- rfi_flush_enable(false);
+ enable = false;
else
return -EINVAL;
+ /* Only do anything if we're changing state */
+ if (enable != rfi_flush)
+ rfi_flush_enable(enable);
+
return 0;
}
--
2.7.4
[PATCH v3 0/5] Setup RFI flush after PowerVM LPM migration
This patchset allows for setup_rfi_flush() to be called again after PowerVM LPM (live partition mobility) aka LPAR migration, in order to possibly switch to a different flush method. The patches are mostly from Michael Ellerman, I have rebased to powerpc/linux.git merge branch as of commit d8443ef (March 14). Testcase and results sent as the last email in the series. v3: add patch 4 to tell flush types are 'available' and not 'Using'. remove plumbing patch. v2: add plumbing patch between platforms and setup code to force init fallback flush. Mauricio Faria de Oliveira (1): rfi-flush: Differentiate enabled and patched flush types Michael Ellerman (4): rfi-flush: Move the logic to avoid a redo into the debugfs code rfi-flush: Make it possible to call setup_rfi_flush() again rfi-flush: Always enable fallback flush on pseries rfi-flush: Call setup_rfi_flush() after LPM migration arch/powerpc/include/asm/setup.h | 2 +- arch/powerpc/kernel/setup_64.c| 25 - arch/powerpc/lib/feature-fixups.c | 9 - arch/powerpc/platforms/pseries/mobility.c | 3 +++ arch/powerpc/platforms/pseries/pseries.h | 2 ++ arch/powerpc/platforms/pseries/setup.c| 12 ++-- 6 files changed, 32 insertions(+), 21 deletions(-) -- 2.7.4
Re: [RFC] powerpc/xive: Remove irq from queue when it is shutdown
On 03/14/2018 05:58 PM, Frederic Barrat wrote:
> If a driver has called free_irq() but an irq is waiting in a queue, an
> error is logged when a cpu processes it:
>
> irq 232, desc: 44e5941a, depth: 1, count: 9823, unhandled: 0
> ->handle_irq(): 23f2e352,
> handle_bad_irq+0x0/0x2e0
> ->irq_data.chip(): 7fd7bf50,
> no_irq_chip+0x0/0x110
> ->action(): (null)
> IRQ_NOREQUEST set
> unexpected IRQ trap at vector e8
>
> In most cases, it's due to a driver bug or a misbehaving device, but
> it can be observed with opencapi with no involvment of a device. AFU
> interrupts are triggered by writing a special page of a process, but
> it's possible for a thread of that process to write to that page as
> well. If that process exits abruptly, the driver will free the AFU
> interrupts resources, but there's no possible quiescing of the
> process, so we may have interrupts in the queue.
>
> This patch adds a scan of the queue when an interrupt is shutdown to
> replace any pending irq with XIVE_BAD_IRQ, since those are ignored.
> Also move when XIVE_BAD_IRQs are ignored closer to reading the queue,
> so that we can reset the CPPR if it's the last interrupt in the queue.
We could also loop on the ESB 'P' bit to wait for the irqs to be handled,
using :
xive_esb_read(irq, XIVE_ESB_GET)
which has no side effect. It looks simpler to me. Is that possible ?
> Signed-off-by: Frederic Barrat
> ---
> arch/powerpc/sysdev/xive/common.c | 69
> ---
> 1 file changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/common.c
> b/arch/powerpc/sysdev/xive/common.c
> index 3459015092fa..91047bc7c731 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -148,8 +148,16 @@ static u32 xive_scan_interrupts(struct xive_cpu *xc,
> bool just_peek)
> prio = ffs(xc->pending_prio) - 1;
> DBG_VERBOSE("scan_irq: trying prio %d\n", prio);
>
> - /* Try to fetch */
> - irq = xive_read_eq(&xc->queue[prio], just_peek);
> + /*
> + * Try to fetch.
> + * When not peeking, drop any BAD_IRQ on the floor
> + * now. If we let it reach get_irq() and it's the last
> + * one, then we'd need to rescan again to reset the
> + * CPPR
> + */
> + do {
> + irq = xive_read_eq(&xc->queue[prio], just_peek);
> + } while (irq == XIVE_BAD_IRQ && !just_peek);
>
> /* Found something ? That's it */
> if (irq)
> @@ -282,8 +290,6 @@ static unsigned int xive_get_irq(void)
> irq, xc->pending_prio);
>
> /* Return pending interrupt if any */
> - if (irq == XIVE_BAD_IRQ)
> - return 0;
> return irq;
> }
>
> @@ -592,6 +598,58 @@ static unsigned int xive_irq_startup(struct irq_data *d)
> return 0;
> }
>
> +static void xive_remove_from_queue(unsigned int hw_irq, int cpu)
> +{
> + struct xive_cpu *xc;
> + struct xive_q *q;
> + u32 irq = 0, cur, idx, toggle, prev;
> + u8 prio;
> + int count;
> +
> + xc = per_cpu(xive_cpu, cpu);
> +
> + /*
> + * Only one queue is really in use, but let's try stay generic, and
> + * check all of them
> + */
nevertheless, we could use some helper routines to manipulate
the xive queues. This is beginning to be cryptic.
> + for (prio = 0; prio < XIVE_MAX_QUEUES; prio++) {
> + q = &xc->queue[prio];
> + if (!q->qpage)
> + continue;
> +
> + /*
> + * We can't read a reliable index and toggle without
> + * locking, as another cpu can process an interrupt
> + * and read the queue at any given time. So use the
> + * toggle from the previous index, which should be ok
> + * as long as the queue doesn't overflow.
> + */
> + idx = q->idx;
> + prev = (idx - 1) & q->msk;
> + cur = be32_to_cpup(q->qpage + prev);
> + toggle = (cur >> 31) ^ 1;
> + count = 0;
> + do {
> + count++;
> + cur = be32_to_cpup(q->qpage + idx);
> + if ((cur >> 31) == toggle)
> + irq = 0;
> + else
> + irq = cur & 0x7fff;
> +
> + if (irq == hw_irq) {
> + cur &= 1 << 31;
> + cur |= XIVE_BAD_IRQ;
> + *(q->qpage + idx) = cpu_to_be32(cur);
Are we sure that the XIVE controller is not updating the queue at
the same time ?
Thanks,
C.
> + }
> +
> + idx = (idx + 1) & q->msk;
> + if (idx == 0)
> +
Re: [PATCH] powerpc: Use common error handling code in setup_new_fdt()
SF Markus Elfring writes: > From: Markus Elfring > Date: Sun, 11 Mar 2018 09:03:42 +0100 > > Add a jump target so that a bit of exception handling can be better reused > at the end of this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > arch/powerpc/kernel/machine_kexec_file_64.c | 28 > 1 file changed, 12 insertions(+), 16 deletions(-) I liked it. Thanks! Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
On 03/14/2018 03:55 PM, Bjorn Helgaas wrote: As far as I'm concerned, we can just remove these messages completely. I don't think there's any real value there. After I found out that this was happening to all PCI devices on powerpc due to the __weak pcibios_default_alignment() interface (necessary for VFIO passthrough and performance), I confess that this was my first approach to this matter; however I couldn't vouch the need of these messages on other architectures. If there are no further concerns, I definitely prefer sending a second version of this patch only eliminating these messages and attesting the reason why. Thank you very much for your review Bjorn, No problem, welcome to PCI, and I hope we see more of your work! Bjorn, Awesome! A second version of this fix has been sent with a new title: "[PATCH, pci, v2] pci: Delete PCI disabling informational messages" Thanks for the review and warm welcome! -- Desnes A. Nunes do Rosário --
[PATCH, pci, v2] pci: Delete PCI disabling informational messages
The disabling informational messages on the PCI subsystem should be deleted
since they do not represent any real value for the system logs.
These messages are either not presented, or presented for all PCI devices
(e.g., powerpc now realigns all PCI devices to its page size). Thus, they
are flooding system logs and can be interpreted as a false positive for
total PCI failure on the system.
[root@system user]# dmesg | grep -i disabling
[0.692270] pci :00:00.0: Disabling memory decoding and releasing memory
resources
[0.692324] pci :00:00.0: disabling bridge mem windows
[0.729134] pci 0001:00:00.0: Disabling memory decoding and releasing memory
resources
[0.737352] pci 0001:00:00.0: disabling bridge mem windows
[0.776295] pci 0002:00:00.0: Disabling memory decoding and releasing memory
resources
[0.784509] pci 0002:00:00.0: disabling bridge mem windows
... and goes on for all PCI devices on the system ...
Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to
force PCI devices to be page aligned")
Signed-off-by: Desnes A. Nunes do Rosario
---
drivers/pci/pci.c | 1 -
drivers/pci/setup-res.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c71d1a66cdd..1563ce1ee091 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5505,7 +5505,6 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
return;
}
- pci_info(dev, "Disabling memory decoding and releasing memory
resources\n");
pci_read_config_word(dev, PCI_COMMAND, &command);
command &= ~PCI_COMMAND_MEMORY;
pci_write_config_word(dev, PCI_COMMAND, command);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 369d48d6c6f1..6bd35e8e7cde 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -172,8 +172,6 @@ EXPORT_SYMBOL(pci_claim_resource);
void pci_disable_bridge_window(struct pci_dev *dev)
{
- pci_info(dev, "disabling bridge mem windows\n");
-
/* MMIO Base/Limit */
pci_write_config_dword(dev, PCI_MEMORY_BASE, 0xfff0);
--
2.14.3
[PATCH v3] powerpc: treat pkey-0 special
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
This patch clarifies the semantics of pkey-0 and provides the
corresponding implementation on powerpc.
Pkey-0 is special with the following semantics.
(a) it is implicitly allocated and can never be freed. It always exists.
(b) it is the default key assigned to any address-range.
(c) it can be explicitly associated with any address-range.
Tested on powerpc.
History:
v3 : added clarification of the semantics of pkey0.
-- suggested by Dave Hansen
v2 : split the patch into two, one for x86 and one for powerpc
-- suggested by Michael Ellermen
cc: Dave Hansen
cc: Michael Ellermen
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/pkeys.h | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..3c1deec 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -101,10 +101,18 @@ static inline u16 pte_to_pkey_bits(u64 pteflags)
static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
{
- /* A reserved key is never considered as 'explicitly allocated' */
- return ((pkey < arch_max_pkey()) &&
- !__mm_pkey_is_reserved(pkey) &&
- __mm_pkey_is_allocated(mm, pkey));
+ /* pkey 0 is allocated by default. */
+ if (!pkey)
+ return true;
+
+ if (pkey < 0 || pkey >= arch_max_pkey())
+ return false;
+
+ /* Reserved keys are never allocated. */
+ if (__mm_pkey_is_reserved(pkey))
+ return false;
+
+ return __mm_pkey_is_allocated(mm, pkey);
}
extern void __arch_activate_pkey(int pkey);
@@ -150,7 +158,8 @@ static inline int mm_pkey_free(struct mm_struct *mm, int
pkey)
if (static_branch_likely(&pkey_disabled))
return -1;
- if (!mm_pkey_is_allocated(mm, pkey))
+ /* pkey 0 cannot be freed */
+ if (!pkey || !mm_pkey_is_allocated(mm, pkey))
return -EINVAL;
/*
--
1.8.3.1
[PATCH v3] x86: treat pkey-0 special
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
This patch clarifies the semantics of pkey-0 and provides the
corresponding implementation on powerpc.
Pkey-0 is special with the following semantics.
(a) it is implicitly allocated and can never be freed. It always exists.
(b) it is the default key assigned to any address-range.
(c) it can be explicitly associated with any address-range.
Tested on x86_64.
History:
v3 : added clarification of the semantics of pkey0.
-- suggested by Dave Hansen
v2 : split the patch into two, one for x86 and one for powerpc
-- suggested by Michael Ellermen
cc: Dave Hansen
cc: Michael Ellermen
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/x86/include/asm/pkeys.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index a0ba1ff..6ea7486 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm/pkeys.h
@@ -52,7 +52,7 @@ bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
* from pkey_alloc(). pkey 0 is special, and never
* returned from pkey_alloc().
*/
- if (pkey <= 0)
+ if (pkey < 0)
return false;
if (pkey >= arch_max_pkey())
return false;
@@ -92,7 +92,8 @@ int mm_pkey_alloc(struct mm_struct *mm)
static inline
int mm_pkey_free(struct mm_struct *mm, int pkey)
{
- if (!mm_pkey_is_allocated(mm, pkey))
+ /* pkey 0 is special and can never be freed */
+ if (!pkey || !mm_pkey_is_allocated(mm, pkey))
return -EINVAL;
mm_set_pkey_free(mm, pkey);
--
1.8.3.1
Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h
On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani wrote: > The file arch/arm64/kernel/process.c needs asm/compat.h also to be > included directly since this is included conditionally from > include/compat.h. This does seem to be typical of arm64 as I was not > completely able to get rid of asm/compat.h includes for arm64 in this > series. My plan is to have separate patches to get rid of asm/compat.h > includes for the architectures that are not straight forward to keep > this series simple. > I will fix this and update the series. > I ran across the same thing in two more files during randconfig testing on arm64 now, adding this fixup on top for the moment, but maybe there is a better way: commit 4f3e9e1211799a79b201a1af309a1ec3864147ec Author: Arnd Bergmann Date: Wed Mar 14 18:23:16 2018 +0100 arm64: fix perf_regs.c arch/arm64/kernel/perf_regs.c: In function 'perf_reg_abi': arch/arm64/kernel/perf_regs.c:50:6: error: implicit declaration of function 'is_compat_thread'; did you mean 'is_compat_task'? [-Werror=implicit-function-declaration] arch/arm64/kernel/hw_breakpoint.c: In function 'is_compat_bp': arch/arm64/kernel/hw_breakpoint.c:182:16: error: implicit declaration of function 'is_compat_thread'; did you mean 'is_compat_task'? [-Werror=implicit-function-declaration] Signed-off-by: Arnd Bergmann diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c index 413dbe530da8..74bb56f656ef 100644 --- a/arch/arm64/kernel/hw_breakpoint.c +++ b/arch/arm64/kernel/hw_breakpoint.c @@ -30,6 +30,7 @@ #include #include +#include #include #include #include diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c index 0bbac612146e..1b463a4efe49 100644 --- a/arch/arm64/kernel/perf_regs.c +++ b/arch/arm64/kernel/perf_regs.c @@ -6,6 +6,7 @@ #include #include +#include #include #include
Re: [GIT PULL] Please pull JSON files for POWR9 PMU events
Em Tue, Mar 13, 2018 at 03:46:47PM -0700, Sukadev Bhattiprolu escreveu: > > Hi Arnaldo, > > Please pull an update to the JSON files for POWER9 PMU events. Can you please be a bit more verbose in the next pull requets, something like describing what is the nature of this specific pull request, say it is to better support some specific measurements, etc, so that people don't have to go and peruse the patches looking for what has changed. If you could even show it being used and drawind some interesting conclusion, even better. Or point to documentation describing it being used, a blog post, whatever that clarifies these updates and encourages potential users to try the perf tools with those events. - Arnaldo > The following changes since commit 90d2614c4d10c2f9d0ada9a3b01e5f43ca8d1ae3: > > perf test: Fix exit code for record+probe_libc_inet_pton.sh (2018-03-13 > 15:14:43 -0300) > > are available in the git repository at: > > https://github.com/sukadev/linux/ p9-json-v5 > > for you to fetch changes up to 99c9dff949f2502964005f9afa8d60c89b446f2c: > > perf vendor events: Update POWER9 events (2018-03-13 16:48:12 -0500) > > > Sukadev Bhattiprolu (1): > perf vendor events: Update POWER9 events > > .../perf/pmu-events/arch/powerpc/power9/cache.json | 25 --- > .../pmu-events/arch/powerpc/power9/frontend.json | 10 - > .../pmu-events/arch/powerpc/power9/marked.json | 5 - > .../pmu-events/arch/powerpc/power9/memory.json | 5 - > .../perf/pmu-events/arch/powerpc/power9/other.json | 241 > ++--- > .../pmu-events/arch/powerpc/power9/pipeline.json | 50 ++--- > tools/perf/pmu-events/arch/powerpc/power9/pmc.json | 5 - > .../arch/powerpc/power9/translation.json | 10 +- > 8 files changed, 178 insertions(+), 173 deletions(-)
Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
On 03/14/2018 11:54 AM, Ram Pai wrote: >>> (e) it bypasses key-permission checks when assigned. >> I don't think this is necessary. I think the only rule we *need* is: >> >> pkey-0 is allocated implicitly at execve() time. You do not >> need to call pkey_alloc() to allocate it. > And can be explicitly associated with any address range ? Yes, it should ideally be available for use just like any other key when allocated.
Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
On Wed, Mar 14, 2018 at 10:51:26AM -0700, Dave Hansen wrote: > On 03/14/2018 10:14 AM, Ram Pai wrote: > > I look at key-0 as 'the key'. It has special status. > > (a) It always exist. > > Do you mean "is always allocated"? always allocated and cannot be freed. Hence always exists. If we let it freed, than yes 'it is always allocated', but may not 'always exist'. > > > (b) it cannot be freed. > > This is the one I'm questioning. this is a philosophical question. Should we allow the application shoot-its-own-feet or help it from doing so. I tend to gravitate towards the later. > > > (c) it is assigned by default. > > I agree on this totally. :) good. we have some common ground :) > > > (d) its permissions cannot be modified. > > Why not? You could pretty easily get a thread going that had its stack > covered with another pkey and that was being very careful what it > accesses. It could pretty easily set pkey-0's access or write-disable bits. ok. I see your point. Will not argue against it. > > > (e) it bypasses key-permission checks when assigned. > > I don't think this is necessary. I think the only rule we *need* is: > > pkey-0 is allocated implicitly at execve() time. You do not > need to call pkey_alloc() to allocate it. And can be explicitly associated with any address range ? > > > An arch need not necessarily map 'the key-0' to its key-0. It could > > internally map it to any of its internal key of its choice, transparent > > to the application. > > I don't understand what you are saying here. I was trying to disassociate the notion that "application's key-0 means hardware's key-0". Nevermind. its not important for this discussion. -- Ram Pai
Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
On Wed, Mar 14, 2018 at 03:22:44PM -0300, Desnes Augusto Nunes do Rosário wrote:
> Hello Bjorn,
>
> On 03/14/2018 03:06 PM, Bjorn Helgaas wrote:
> > On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote:
> > > Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
> > > silent PCI realignment messages if the flag is turned on by a driver.
> > >
> > > Signed-off-by: Desnes A. Nunes do Rosario
> > > ---
> > > drivers/pci/pci.c | 3 ++-
> > > drivers/pci/setup-res.c | 3 ++-
> > > include/linux/pci.h | 2 ++
> > > 3 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 8c71d1a66cdd..be197c944e5f 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct
> > > pci_dev *dev)
> > > return;
> > > }
> > > - pci_info(dev, "Disabling memory decoding and releasing memory
> > > resources\n");
> > > + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> > > + pci_info(dev, "Disabling memory decoding and releasing memory
> > > resources\n");
> > > pci_read_config_word(dev, PCI_COMMAND, &command);
> > > command &= ~PCI_COMMAND_MEMORY;
> > > pci_write_config_word(dev, PCI_COMMAND, command);
> > > diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> > > index 369d48d6c6f1..00a538def763 100644
> > > --- a/drivers/pci/setup-res.c
> > > +++ b/drivers/pci/setup-res.c
> > > @@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
> > > void pci_disable_bridge_window(struct pci_dev *dev)
> > > {
> > > - pci_info(dev, "disabling bridge mem windows\n");
> > > + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> > > + pci_info(dev, "disabling bridge mem windows\n");
> >
> > As far as I'm concerned, we can just remove these messages completely.
> > I don't think there's any real value there.
>
> After I found out that this was happening to all PCI devices on powerpc due
> to the __weak
> pcibios_default_alignment() interface (necessary for VFIO passthrough and
> performance), I confess that this was my first approach to this matter;
> however I couldn't vouch the need of these messages on other architectures.
>
> If there are no further concerns, I definitely prefer sending a second
> version of this patch only eliminating these messages and attesting the
> reason why.
>
> Thank you very much for your review Bjorn,
No problem, welcome to PCI, and I hope we see more of your work!
Re: [PATCH 0/5] DPAA Ethernet fixes
On Wed, 2018-03-14 at 08:37 -0500, Madalin Bucur wrote: > Hi, > > This patch set is addressing several issues in the DPAA Ethernet > driver suite: > > - module unload crash caused by wrong reference to device being left >in the cleanup code after the DSA related changes > - scheduling wile atomic bug in QMan code revealed during dpaa_eth >module unload > - a couple of error counter fixes, a duplicated init in dpaa_eth. hmm, some of these(all?) bugs are in stable too, CC: stable perhaps? > > Madalin > > Camelia Groza (3): > dpaa_eth: remove duplicate initialization > dpaa_eth: increment the RX dropped counter when needed > dpaa_eth: remove duplicate increment of the tx_errors counter > > Madalin Bucur (2): > soc/fsl/qbman: fix issue in qman_delete_cgr_safe() > dpaa_eth: fix error in dpaa_remove() > > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 8 > drivers/soc/fsl/qbman/qman.c | 28 > +- > 2 files changed, 9 insertions(+), 27 deletions(-) > > -- > 2.1.0 >
Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
Hello Bjorn,
On 03/14/2018 03:06 PM, Bjorn Helgaas wrote:
On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote:
Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
silent PCI realignment messages if the flag is turned on by a driver.
Signed-off-by: Desnes A. Nunes do Rosario
---
drivers/pci/pci.c | 3 ++-
drivers/pci/setup-res.c | 3 ++-
include/linux/pci.h | 2 ++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c71d1a66cdd..be197c944e5f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
return;
}
- pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
+ pci_info(dev, "Disabling memory decoding and releasing memory
resources\n");
pci_read_config_word(dev, PCI_COMMAND, &command);
command &= ~PCI_COMMAND_MEMORY;
pci_write_config_word(dev, PCI_COMMAND, command);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 369d48d6c6f1..00a538def763 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
void pci_disable_bridge_window(struct pci_dev *dev)
{
- pci_info(dev, "disabling bridge mem windows\n");
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
+ pci_info(dev, "disabling bridge mem windows\n");
As far as I'm concerned, we can just remove these messages completely.
I don't think there's any real value there.
After I found out that this was happening to all PCI devices on powerpc
due to the __weak
pcibios_default_alignment() interface (necessary for VFIO passthrough
and performance), I confess that this was my first approach to this
matter; however I couldn't vouch the need of these messages on other
architectures.
If there are no further concerns, I definitely prefer sending a second
version of this patch only eliminating these messages and attesting the
reason why.
Thank you very much for your review Bjorn,
--
Desnes A. Nunes do Rosário
Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
Hello Andy,
On 03/14/2018 02:41 PM, Andy Shevchenko wrote:
On Wed, Mar 14, 2018 at 6:34 PM, Desnes A. Nunes do Rosario
wrote:
Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
silent PCI realignment messages if the flag is turned on by a driver.
It doesn't explain "Why?"
Why the driver needs that?
I have written down the reason on the cover letter, but I concur on
creating a second version of the patch's comment. Basically, all PCI
resources on powerpc are printing out expected realignment messages
which are flooding the systems logs.
Perhaps this would be better?
---
"Some architectures such as powerpc has aligned all of its PCI resources
to its PAGE_SIZE during boot, thus the system logs will be flooded by
expected realignment messages, which can be interpreted as a false
positive for total PCI failure on the system.
[root@system user]# dmesg | grep -i disabling
[0.692270] pci :00:00.0: Disabling memory decoding and releasing
memory resources
[0.692324] pci :00:00.0: disabling bridge mem windows
[0.729134] pci 0001:00:00.0: Disabling memory decoding and releasing
memory resources
[0.737352] pci 0001:00:00.0: disabling bridge mem windows
[0.776295] pci 0002:00:00.0: Disabling memory decoding and releasing
memory resources
[0.784509] pci 0002:00:00.0: disabling bridge mem windows
... and goes on for all PCI devices ...
Thus, this patch adds PCI_DEV_FLAGS_NO_REALIGN_MSG to pci_dev_flags and
uses it to silent PCI realignment messages if the flag is turned on by a
driver.
"
---
Another approach is to increase level of the message. Would it be
accepted by you (in case Bjorn agrees)?
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -205,6 +205,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
/* Don't use Relaxed Ordering for TLPs directed at this device */
PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 <<
11),
+ /* Silent PCI resource realignment messages */
+ PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
I would rather name it _NO_PCI_REALIGN_MSG
I concur on changing it to PCI_DEV_FLAGS_NO_REALIGN_MSG in a second
version of the patchset.
};
Thank you very much for your review,
--
Desnes A. Nunes do Rosário
Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote:
> Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
> silent PCI realignment messages if the flag is turned on by a driver.
>
> Signed-off-by: Desnes A. Nunes do Rosario
> ---
> drivers/pci/pci.c | 3 ++-
> drivers/pci/setup-res.c | 3 ++-
> include/linux/pci.h | 2 ++
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 8c71d1a66cdd..be197c944e5f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev
> *dev)
> return;
> }
>
> - pci_info(dev, "Disabling memory decoding and releasing memory
> resources\n");
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> + pci_info(dev, "Disabling memory decoding and releasing memory
> resources\n");
> pci_read_config_word(dev, PCI_COMMAND, &command);
> command &= ~PCI_COMMAND_MEMORY;
> pci_write_config_word(dev, PCI_COMMAND, command);
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 369d48d6c6f1..00a538def763 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
>
> void pci_disable_bridge_window(struct pci_dev *dev)
> {
> - pci_info(dev, "disabling bridge mem windows\n");
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> + pci_info(dev, "disabling bridge mem windows\n");
As far as I'm concerned, we can just remove these messages completely.
I don't think there's any real value there.
> /* MMIO Base/Limit */
> pci_write_config_dword(dev, PCI_MEMORY_BASE, 0xfff0);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e057e8cc63e7..993f9c7dcc00 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -205,6 +205,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
> /* Don't use Relaxed Ordering for TLPs directed at this device */
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
> + /* Silent PCI resource realignment messages */
> + PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
> };
>
> enum pci_irq_reroute_variant {
> --
> 2.14.3
>
Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
On 03/14/2018 10:14 AM, Ram Pai wrote: > I look at key-0 as 'the key'. It has special status. > (a) It always exist. Do you mean "is always allocated"? > (b) it cannot be freed. This is the one I'm questioning. > (c) it is assigned by default. I agree on this totally. :) > (d) its permissions cannot be modified. Why not? You could pretty easily get a thread going that had its stack covered with another pkey and that was being very careful what it accesses. It could pretty easily set pkey-0's access or write-disable bits. > (e) it bypasses key-permission checks when assigned. I don't think this is necessary. I think the only rule we *need* is: pkey-0 is allocated implicitly at execve() time. You do not need to call pkey_alloc() to allocate it. > An arch need not necessarily map 'the key-0' to its key-0. It could > internally map it to any of its internal key of its choice, transparent > to the application. I don't understand what you are saying here.
Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
On Wed, Mar 14, 2018 at 7:41 PM, Andy Shevchenko wrote: > I would rather name it _NO_PCI_REALIGN_MSG I meant _NO_REALIGN_MSG of course (PCI is already at the beginning). -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
On Wed, Mar 14, 2018 at 6:34 PM, Desnes A. Nunes do Rosario
wrote:
> Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
> silent PCI realignment messages if the flag is turned on by a driver.
It doesn't explain "Why?"
Why the driver needs that?
Another approach is to increase level of the message. Would it be
accepted by you (in case Bjorn agrees)?
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -205,6 +205,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
> /* Don't use Relaxed Ordering for TLPs directed at this device */
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 <<
> 11),
> + /* Silent PCI resource realignment messages */
> + PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
I would rather name it _NO_PCI_REALIGN_MSG
> };
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 0/5] DPAA Ethernet fixes
From: Madalin Bucur Date: Wed, 14 Mar 2018 08:37:27 -0500 > This patch set is addressing several issues in the DPAA Ethernet > driver suite: > > - module unload crash caused by wrong reference to device being left >in the cleanup code after the DSA related changes > - scheduling wile atomic bug in QMan code revealed during dpaa_eth >module unload > - a couple of error counter fixes, a duplicated init in dpaa_eth. Series applied, thank you.
Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
On Wed, Mar 14, 2018 at 07:19:23AM -0700, Dave Hansen wrote:
> On 03/14/2018 12:46 AM, Ram Pai wrote:
> > Once an address range is associated with an allocated pkey, it cannot be
> > reverted back to key-0. There is no valid reason for the above behavior. On
> > the contrary applications need the ability to do so.
>
> I'm trying to remember why we cared in the first place. :)
>
> Could you add that to the changelog, please?
>
> > @@ -92,7 +92,8 @@ int mm_pkey_alloc(struct mm_struct *mm)
> > static inline
> > int mm_pkey_free(struct mm_struct *mm, int pkey)
> > {
> > - if (!mm_pkey_is_allocated(mm, pkey))
> > + /* pkey 0 is special and can never be freed */
> > + if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> > return -EINVAL;
>
> If an app was being really careful, couldn't it free up all of the
> implicitly-pkey-0-assigned memory so that it is not in use at all? In
> that case, we might want to allow this.
>
> On the other hand, nobody is likely to _ever_ actually do this so this
> is good shoot-yourself-in-the-foot protection.
I look at key-0 as 'the key'. It has special status.
(a) It always exist.
(b) it cannot be freed.
(c) it is assigned by default.
(d) its permissions cannot be modified.
(e) it bypasses key-permission checks when assigned.
An arch need not necessarily map 'the key-0' to its key-0. It could
internally map it to any of its internal key of its choice, transparent
to the application.
Do you see a problem to this view point?
RP
[PATCH] powerpc/xive: Fix wrong xmon output caused by typo
Signed-off-by: Frederic Barrat
---
arch/powerpc/sysdev/xive/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 40c06110821c..3459015092fa 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -246,7 +246,7 @@ notrace void xmon_xive_do_dump(int cpu)
u64 val = xive_esb_read(&xc->ipi_data, XIVE_ESB_GET);
xmon_printf(" IPI state: %x:%c%c\n", xc->hw_ipi,
val & XIVE_ESB_VAL_P ? 'P' : 'p',
- val & XIVE_ESB_VAL_P ? 'Q' : 'q');
+ val & XIVE_ESB_VAL_Q ? 'Q' : 'q');
}
#endif
}
--
2.14.1
[RFC] powerpc/xive: Remove irq from queue when it is shutdown
If a driver has called free_irq() but an irq is waiting in a queue, an
error is logged when a cpu processes it:
irq 232, desc: 44e5941a, depth: 1, count: 9823, unhandled: 0
->handle_irq(): 23f2e352,
handle_bad_irq+0x0/0x2e0
->irq_data.chip(): 7fd7bf50,
no_irq_chip+0x0/0x110
->action(): (null)
IRQ_NOREQUEST set
unexpected IRQ trap at vector e8
In most cases, it's due to a driver bug or a misbehaving device, but
it can be observed with opencapi with no involvment of a device. AFU
interrupts are triggered by writing a special page of a process, but
it's possible for a thread of that process to write to that page as
well. If that process exits abruptly, the driver will free the AFU
interrupts resources, but there's no possible quiescing of the
process, so we may have interrupts in the queue.
This patch adds a scan of the queue when an interrupt is shutdown to
replace any pending irq with XIVE_BAD_IRQ, since those are ignored.
Also move when XIVE_BAD_IRQs are ignored closer to reading the queue,
so that we can reset the CPPR if it's the last interrupt in the queue.
Signed-off-by: Frederic Barrat
---
arch/powerpc/sysdev/xive/common.c | 69 ---
1 file changed, 65 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 3459015092fa..91047bc7c731 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -148,8 +148,16 @@ static u32 xive_scan_interrupts(struct xive_cpu *xc, bool
just_peek)
prio = ffs(xc->pending_prio) - 1;
DBG_VERBOSE("scan_irq: trying prio %d\n", prio);
- /* Try to fetch */
- irq = xive_read_eq(&xc->queue[prio], just_peek);
+ /*
+* Try to fetch.
+* When not peeking, drop any BAD_IRQ on the floor
+* now. If we let it reach get_irq() and it's the last
+* one, then we'd need to rescan again to reset the
+* CPPR
+*/
+ do {
+ irq = xive_read_eq(&xc->queue[prio], just_peek);
+ } while (irq == XIVE_BAD_IRQ && !just_peek);
/* Found something ? That's it */
if (irq)
@@ -282,8 +290,6 @@ static unsigned int xive_get_irq(void)
irq, xc->pending_prio);
/* Return pending interrupt if any */
- if (irq == XIVE_BAD_IRQ)
- return 0;
return irq;
}
@@ -592,6 +598,58 @@ static unsigned int xive_irq_startup(struct irq_data *d)
return 0;
}
+static void xive_remove_from_queue(unsigned int hw_irq, int cpu)
+{
+ struct xive_cpu *xc;
+ struct xive_q *q;
+ u32 irq = 0, cur, idx, toggle, prev;
+ u8 prio;
+ int count;
+
+ xc = per_cpu(xive_cpu, cpu);
+
+ /*
+* Only one queue is really in use, but let's try stay generic, and
+* check all of them
+*/
+ for (prio = 0; prio < XIVE_MAX_QUEUES; prio++) {
+ q = &xc->queue[prio];
+ if (!q->qpage)
+ continue;
+
+ /*
+* We can't read a reliable index and toggle without
+* locking, as another cpu can process an interrupt
+* and read the queue at any given time. So use the
+* toggle from the previous index, which should be ok
+* as long as the queue doesn't overflow.
+*/
+ idx = q->idx;
+ prev = (idx - 1) & q->msk;
+ cur = be32_to_cpup(q->qpage + prev);
+ toggle = (cur >> 31) ^ 1;
+ count = 0;
+ do {
+ count++;
+ cur = be32_to_cpup(q->qpage + idx);
+ if ((cur >> 31) == toggle)
+ irq = 0;
+ else
+ irq = cur & 0x7fff;
+
+ if (irq == hw_irq) {
+ cur &= 1 << 31;
+ cur |= XIVE_BAD_IRQ;
+ *(q->qpage + idx) = cpu_to_be32(cur);
+ }
+
+ idx = (idx + 1) & q->msk;
+ if (idx == 0)
+ toggle ^= 1;
+ } while (irq && (count < q->msk));
+ }
+}
+
static void xive_irq_shutdown(struct irq_data *d)
{
struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
@@ -624,6 +682,9 @@ static void xive_irq_shutdown(struct irq_data *d)
get_hard_smp_processor_id(xd->target),
0xff, XIVE_BAD_IRQ);
+ /* configure_irq() syncs the queue */
+ xive_remove_from_queue(hw_irq, xd->target);
+
xive_dec_target_count(xd->target);
x
Re: [RESEND PATCH] Input: joystick/analog - Use get_cycles() on PPC
On Wed, Mar 14, 2018 at 10:17:52PM +1100, Michael Ellerman wrote:
> The analog joystick driver spits a warning at us:
>
> drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer
> not defined for this architecture.
>
> PPC has get_cycles() so use that.
>
> Signed-off-by: Michael Ellerman
Applied, thank you.
> ---
> drivers/input/joystick/analog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> This is the third resend, I'll take it via the powerpc tree if no one else
> does.
>
> cheers
>
> diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
> index c868a878c84f..a942c4ccd2af 100644
> --- a/drivers/input/joystick/analog.c
> +++ b/drivers/input/joystick/analog.c
> @@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
> #define GET_TIME(x) do { x = (unsigned int)rdtsc(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME"TSC"
> -#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM)
> || defined(CONFIG_ARM64) || defined(CONFIG_RISCV) || defined(CONFIG_TILE)
> +#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM)
> || defined(CONFIG_ARM64) || defined(CONFIG_PPC) || defined(CONFIG_RISCV) ||
> defined(CONFIG_TILE)
> #define GET_TIME(x) do { x = get_cycles(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME"get_cycles"
> --
> 2.14.1
>
--
Dmitry
[PATCH 2/2, powerpc/powernv] powerpc/powernv: Tweak PCI_DEV_FLAGS_QUIET_PCI_REALIGN on/off during boot
Turn on PCI_DEV_FLAGS_QUIET_PCI_REALIGN flag on powernv's pci driver
to silent PCI realignment messages through a early stage hook, and turn
it off right before the pci device is enabled with a final stage hook.
Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to
force PCI devices to be page aligned")
Signed-off-by: Desnes A. Nunes do Rosario
---
arch/powerpc/platforms/powernv/pci.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 69d102cbf48f..d28ce0899487 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -1108,6 +1108,20 @@ static void pnv_p7ioc_rc_quirk(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x3b9, pnv_p7ioc_rc_quirk);
+/* Fixup that disables PCI realignment menssages for all PCI devices */
+static void disable_realign_menssages(struct pci_dev *dev)
+{
+ dev->dev_flags |= PCI_DEV_FLAGS_QUIET_PCI_REALIGN;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, disable_realign_menssages);
+
+/* Fixup that enables PCI realignment messages for all PCI devices */
+static void enable_realign_menssages(struct pci_dev *dev)
+{
+ dev->dev_flags ^= PCI_DEV_FLAGS_QUIET_PCI_REALIGN;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, enable_realign_menssages);
+
void __init pnv_pci_init(void)
{
struct device_node *np;
--
2.14.3
[PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
silent PCI realignment messages if the flag is turned on by a driver.
Signed-off-by: Desnes A. Nunes do Rosario
---
drivers/pci/pci.c | 3 ++-
drivers/pci/setup-res.c | 3 ++-
include/linux/pci.h | 2 ++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c71d1a66cdd..be197c944e5f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev
*dev)
return;
}
- pci_info(dev, "Disabling memory decoding and releasing memory
resources\n");
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
+ pci_info(dev, "Disabling memory decoding and releasing memory
resources\n");
pci_read_config_word(dev, PCI_COMMAND, &command);
command &= ~PCI_COMMAND_MEMORY;
pci_write_config_word(dev, PCI_COMMAND, command);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 369d48d6c6f1..00a538def763 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
void pci_disable_bridge_window(struct pci_dev *dev)
{
- pci_info(dev, "disabling bridge mem windows\n");
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
+ pci_info(dev, "disabling bridge mem windows\n");
/* MMIO Base/Limit */
pci_write_config_dword(dev, PCI_MEMORY_BASE, 0xfff0);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e057e8cc63e7..993f9c7dcc00 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -205,6 +205,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
/* Don't use Relaxed Ordering for TLPs directed at this device */
PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
+ /* Silent PCI resource realignment messages */
+ PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
};
enum pci_irq_reroute_variant {
--
2.14.3
[PATCH 0/2] Silent PCI realignment messages during boot
This patchset introduces PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute in
pci_dev_flags which informs the pci subsystem to suppress all realignment
messages.
Powerpc has aligned all of its PCI resources to its PAGE_SIZE, and this
feature can be easily used on any other arch through the __weak
pcibios_default_alignment() interface.
However, since all PCI resources will be now realigned during boot, the
following messages will not only flood the system logs, but can be inter-
preted as a false positive for total PCI failure on the system.
[root@system user]# dmesg | grep -i disabling
[0.692270] pci :00:00.0: Disabling memory decoding and releasing memory
resources
[0.692324] pci :00:00.0: disabling bridge mem windows
[0.729134] pci 0001:00:00.0: Disabling memory decoding and releasing memory
resources
[0.737352] pci 0001:00:00.0: disabling bridge mem windows
[0.776295] pci 0002:00:00.0: Disabling memory decoding and releasing memory
resources
[0.784509] pci 0002:00:00.0: disabling bridge mem windows
... and goes on for all PCI devices ...
Thus, this patchset provides a way for drivers to silent these messages if
the PCI_DEV_FLAGS_QUIET_PCI_REALIGN is turned on. Moreover, it also
tweaks this flag during boot on powerpc.
Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to
force PCI devices to be page aligned")
Signed-off-by: Desnes A. Nunes do Rosario
Desnes A. Nunes do Rosario (2):
pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI
subsystem
powerpc/powernv: Tweak PCI_DEV_FLAGS_QUIET_PCI_REALIGN on/off during
boot
arch/powerpc/platforms/powernv/pci.c | 14 ++
drivers/pci/pci.c| 3 ++-
drivers/pci/setup-res.c | 3 ++-
include/linux/pci.h | 2 ++
4 files changed, 20 insertions(+), 2 deletions(-)
--
2.14.3
Re: [PATCH 44/47] tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
On Wed, Mar 14, 2018 at 04:35:57PM +0100, Arnd Bergmann wrote: > The blackfin architecture is getting removed, so these drivers > are not needed any more. > > Signed-off-by: Arnd Bergmann > --- > drivers/tty/Kconfig | 13 -- > drivers/tty/Makefile| 1 - > drivers/tty/bfin_jtag_comm.c| 353 > > drivers/tty/hvc/Kconfig | 9 - > drivers/tty/hvc/Makefile| 1 - > drivers/tty/hvc/hvc_bfin_jtag.c | 104 > 6 files changed, 481 deletions(-) > delete mode 100644 drivers/tty/bfin_jtag_comm.c > delete mode 100644 drivers/tty/hvc/hvc_bfin_jtag.c Acked-by: Greg Kroah-Hartman
Re: [PATCH 45/47] tty: hvc: remove tile driver
On Wed, Mar 14, 2018 at 04:35:58PM +0100, Arnd Bergmann wrote: > The Tile architecture is obsolete and getting removed from the kernel, > this removes the corresponding console driver as well. > > Signed-off-by: Arnd Bergmann > --- > drivers/tty/hvc/Makefile | 1 - > drivers/tty/hvc/hvc_tile.c | 196 > - > 2 files changed, 197 deletions(-) > delete mode 100644 drivers/tty/hvc/hvc_tile.c Acked-by: Greg Kroah-Hartman
Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock
On 14/03/2018 09:48, Peter Zijlstra wrote:
> On Tue, Mar 13, 2018 at 06:59:47PM +0100, Laurent Dufour wrote:
>> This change is inspired by the Peter's proposal patch [1] which was
>> protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in
>> that particular case, and it is introducing major performance degradation
>> due to excessive scheduling operations.
>
> Do you happen to have a little more detail on that?
This has been reported by kemi who find bad performance when running some
benchmarks on top of the v5 series:
https://patchwork.kernel.org/patch/687/
It appears that SRCU is generating a lot of additional scheduling to manage the
freeing of the VMA structure. SRCU is dealing through per cpu ressources but
the SRCU callback is And since we are handling this way a per process
ressource (VMA) through a global resource (SRCU) this leads to a lot of
overhead when scheduling the SRCU callback.
>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>> index 34fde7111e88..28c763ea1036 100644
>> --- a/include/linux/mm_types.h
>> +++ b/include/linux/mm_types.h
>> @@ -335,6 +335,7 @@ struct vm_area_struct {
>> struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
>> #ifdef CONFIG_SPECULATIVE_PAGE_FAULT
>> seqcount_t vm_sequence;
>> +atomic_t vm_ref_count; /* see vma_get(), vma_put() */
>> #endif
>> } __randomize_layout;
>>
>> @@ -353,6 +354,9 @@ struct kioctx_table;
>> struct mm_struct {
>> struct vm_area_struct *mmap;/* list of VMAs */
>> struct rb_root mm_rb;
>> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
>> +rwlock_t mm_rb_lock;
>> +#endif
>> u32 vmacache_seqnum; /* per-thread vmacache */
>> #ifdef CONFIG_MMU
>> unsigned long (*get_unmapped_area) (struct file *filp,
>
> When I tried this, it simply traded contention on mmap_sem for
> contention on these two cachelines.
>
> This was for the concurrent fault benchmark, where mmap_sem is only ever
> acquired for reading (so no blocking ever happens) and the bottle-neck
> was really pure cacheline access.
I'd say that this expected if multiple threads are dealing on the same VMA, but
if the VMA differ then this contention is disappearing while it is remaining
when using the mmap_sem.
This being said, test I did on PowerPC using will-it-scale/page_fault1_threads
showed that the number of caches-misses generated in get_vma() are very low
(less than 5%). Am I missing something ?
> Only by using RCU can you avoid that thrashing.
I agree, but this kind of test is the best use case for SRCU because there are
not so many updates, so not a lot of call to the SRCU asynchronous callback.
Honestly, I can't see an ideal solution here, RCU is not optimal when there is
a high number of updates, and using a rwlock may introduced a bottleneck there.
I get better results when using the rwlock than using SRCU in that case, but if
you have another proposal, please advise, I'll give it a try.
> Also note that if your database allocates the one giant mapping, it'll
> be _one_ VMA and that vm_ref_count gets _very_ hot indeed.
In the case of the database product I mentioned in the series header, that's
the opposite, the VMA number is very high so this doesn't happen. But in the
case of one VMA, it's clear that there will be a contention on vm_ref_count,
but this would be better than blocking on the mmap_sem.
Laurent.
Re: [PATCH v5 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion
On Wed, Mar 14, 2018 at 5:03 AM, Deepa Dinamani wrote: > The series is a preparation series for individual architectures > to use 64 bit time_t syscalls in compat and 32 bit emulation modes. > > This is a follow up to the series Arnd Bergmann posted: > https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1] > > Thomas, Arnd, this seems ready to be merged now. > Can you help get this merged? > > Big picture is as per the lwn article: > https://lwn.net/Articles/643234/ [2] > > The series is directed at converting posix clock syscalls: > clock_gettime, clock_settime, clock_getres and clock_nanosleep > to use a new data structure __kernel_timespec at syscall boundaries. > __kernel_timespec maintains 64 bit time_t across all execution modes. > > vdso will be handled as part of each architecture when they enable > support for 64 bit time_t. > > The compat syscalls are repurposed to provide backward compatibility > by using them as native syscalls as well for 32 bit architectures. > They will continue to use timespec at syscall boundaries. > > CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec > or timespec at syscall boundaries. > > The series does the following: > 1. Enable compat syscalls on 32 bit architectures. > 2. Add a new __kernel_timespec type to be used as the data structure >for all the new syscalls. > 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in >[1] and [2] to switch to new definition of __kernel_timespec. It is >the same as struct timespec otherwise. > 4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls. I've applied all 10 patches to my y2038 git branch [1], which is part of linux-next, to give it a little wider testing. If everything goes well, I'd send a pull request to Thomas next week so he can integrate it into tip from there, or (if he prefers) send it directly to Linus in the merge window. Thanks a lot for your persistence and your work on this! Arnd [1] git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git#y2038
[PATCH 44/47] tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
The blackfin architecture is getting removed, so these drivers are not needed any more. Signed-off-by: Arnd Bergmann --- drivers/tty/Kconfig | 13 -- drivers/tty/Makefile| 1 - drivers/tty/bfin_jtag_comm.c| 353 drivers/tty/hvc/Kconfig | 9 - drivers/tty/hvc/Makefile| 1 - drivers/tty/hvc/hvc_bfin_jtag.c | 104 6 files changed, 481 deletions(-) delete mode 100644 drivers/tty/bfin_jtag_comm.c delete mode 100644 drivers/tty/hvc/hvc_bfin_jtag.c diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig index b68e71751cc5..0840d27381ea 100644 --- a/drivers/tty/Kconfig +++ b/drivers/tty/Kconfig @@ -151,19 +151,6 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. -config BFIN_JTAG_COMM - tristate "Blackfin JTAG Communication" - depends on BLACKFIN - help - Add support for emulating a TTY device over the Blackfin JTAG. - - To compile this driver as a module, choose M here: the - module will be called bfin_jtag_comm. - -config BFIN_JTAG_COMM_CONSOLE - bool "Console on Blackfin JTAG" - depends on BFIN_JTAG_COMM=y - config SERIAL_NONSTANDARD bool "Non-standard serial port support" depends on HAS_IOMEM diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile index 47c71f43a397..c72cafdf32b4 100644 --- a/drivers/tty/Makefile +++ b/drivers/tty/Makefile @@ -20,7 +20,6 @@ obj-$(CONFIG_SERIAL_DEV_BUS) += serdev/ # tty drivers obj-$(CONFIG_AMIGA_BUILTIN_SERIAL) += amiserial.o -obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o obj-$(CONFIG_CYCLADES) += cyclades.o obj-$(CONFIG_ISI) += isicom.o obj-$(CONFIG_MOXA_INTELLIO)+= moxa.o diff --git a/drivers/tty/bfin_jtag_comm.c b/drivers/tty/bfin_jtag_comm.c deleted file mode 100644 index c369bf27a67b.. diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig index fec457edad14..3bade5ad3d71 100644 --- a/drivers/tty/hvc/Kconfig +++ b/drivers/tty/hvc/Kconfig @@ -88,15 +88,6 @@ config HVC_DCC driver. This console is used through a JTAG only on ARM. If you don't have a JTAG then you probably don't want this option. -config HVC_BFIN_JTAG - bool "Blackfin JTAG console" - depends on BLACKFIN - select HVC_DRIVER - help -This console uses the Blackfin JTAG to create a console under the -the HVC driver. If you don't have JTAG, then you probably don't -want this option. - config HVCS tristate "IBM Hypervisor Virtual Console Server support" depends on PPC_PSERIES && HVC_CONSOLE diff --git a/drivers/tty/hvc/Makefile b/drivers/tty/hvc/Makefile index 0b02ec7f1dfd..b82f9f68cd23 100644 --- a/drivers/tty/hvc/Makefile +++ b/drivers/tty/hvc/Makefile @@ -10,5 +10,4 @@ obj-$(CONFIG_HVC_IRQ) += hvc_irq.o obj-$(CONFIG_HVC_XEN) += hvc_xen.o obj-$(CONFIG_HVC_IUCV) += hvc_iucv.o obj-$(CONFIG_HVC_UDBG) += hvc_udbg.o -obj-$(CONFIG_HVC_BFIN_JTAG)+= hvc_bfin_jtag.o obj-$(CONFIG_HVCS) += hvcs.o diff --git a/drivers/tty/hvc/hvc_bfin_jtag.c b/drivers/tty/hvc/hvc_bfin_jtag.c deleted file mode 100644 index dd7cae4c195b.. -- 2.9.0
[PATCH 45/47] tty: hvc: remove tile driver
The Tile architecture is obsolete and getting removed from the kernel, this removes the corresponding console driver as well. Signed-off-by: Arnd Bergmann --- drivers/tty/hvc/Makefile | 1 - drivers/tty/hvc/hvc_tile.c | 196 - 2 files changed, 197 deletions(-) delete mode 100644 drivers/tty/hvc/hvc_tile.c diff --git a/drivers/tty/hvc/Makefile b/drivers/tty/hvc/Makefile index b82f9f68cd23..7da1934d34e8 100644 --- a/drivers/tty/hvc/Makefile +++ b/drivers/tty/hvc/Makefile @@ -3,7 +3,6 @@ obj-$(CONFIG_HVC_CONSOLE) += hvc_vio.o hvsi_lib.o obj-$(CONFIG_HVC_OPAL) += hvc_opal.o hvsi_lib.o obj-$(CONFIG_HVC_OLD_HVSI) += hvsi.o obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o -obj-$(CONFIG_HVC_TILE) += hvc_tile.o obj-$(CONFIG_HVC_DCC) += hvc_dcc.o obj-$(CONFIG_HVC_DRIVER) += hvc_console.o obj-$(CONFIG_HVC_IRQ) += hvc_irq.o diff --git a/drivers/tty/hvc/hvc_tile.c b/drivers/tty/hvc/hvc_tile.c deleted file mode 100644 index b517c0661abb.. -- 2.9.0
Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
On 03/14/2018 12:46 AM, Ram Pai wrote:
> Once an address range is associated with an allocated pkey, it cannot be
> reverted back to key-0. There is no valid reason for the above behavior. On
> the contrary applications need the ability to do so.
I'm trying to remember why we cared in the first place. :)
Could you add that to the changelog, please?
> @@ -92,7 +92,8 @@ int mm_pkey_alloc(struct mm_struct *mm)
> static inline
> int mm_pkey_free(struct mm_struct *mm, int pkey)
> {
> - if (!mm_pkey_is_allocated(mm, pkey))
> + /* pkey 0 is special and can never be freed */
> + if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> return -EINVAL;
If an app was being really careful, couldn't it free up all of the
implicitly-pkey-0-assigned memory so that it is not in use at all? In
that case, we might want to allow this.
On the other hand, nobody is likely to _ever_ actually do this so this
is good shoot-yourself-in-the-foot protection.
Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0
On 03/14/2018 01:00 AM, Florian Weimer wrote: > ... but not the key which is used for PROT_EXEC emulation, which is still > reserved The PROT_EXEC key is dynamically allocated. There is no "the key".
[PATCH 5/5] dpaa_eth: remove duplicate increment of the tx_errors counter
From: Camelia Groza
The tx_errors counter is incremented by the dpaa_xmit caller.
Signed-off-by: Camelia Groza
Signed-off-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 76b3c9e..fd43f98 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2021,7 +2021,6 @@ static inline int dpaa_xmit(struct dpaa_priv *priv,
}
if (unlikely(err < 0)) {
- percpu_stats->tx_errors++;
percpu_stats->tx_fifo_errors++;
return err;
}
--
2.1.0
[PATCH 4/5] dpaa_eth: increment the RX dropped counter when needed
From: Camelia Groza
Signed-off-by: Camelia Groza
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 3e83d79..76b3c9e 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2321,8 +2321,10 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
skb_len = skb->len;
- if (unlikely(netif_receive_skb(skb) == NET_RX_DROP))
+ if (unlikely(netif_receive_skb(skb) == NET_RX_DROP)) {
+ percpu_stats->rx_dropped++;
return qman_cb_dqrr_consume;
+ }
percpu_stats->rx_packets++;
percpu_stats->rx_bytes += skb_len;
--
2.1.0
[PATCH 3/5] dpaa_eth: remove duplicate initialization
From: Camelia Groza The fd_format has already been initialized at this point. Signed-off-by: Camelia Groza --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c index 128e0a4..3e83d79 100644 --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2289,7 +2289,6 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct qman_portal *portal, vaddr = phys_to_virt(addr); prefetch(vaddr + qm_fd_get_offset(fd)); - fd_format = qm_fd_get_format(fd); /* The only FD types that we may receive are contig and S/G */ WARN_ON((fd_format != qm_fd_contig) && (fd_format != qm_fd_sg)); -- 2.1.0
[PATCH 2/5] dpaa_eth: fix error in dpaa_remove()
The recent changes that make the driver probing compatible with DSA were not propagated in the dpa_remove() function, breaking the module unload function. Using the proper device to address the issue. Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c index 159dc2d..128e0a4 100644 --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c @@ -2871,7 +2871,7 @@ static int dpaa_remove(struct platform_device *pdev) struct device *dev; int err; - dev = &pdev->dev; + dev = pdev->dev.parent; net_dev = dev_get_drvdata(dev); priv = netdev_priv(net_dev); -- 2.1.0
[PATCH 1/5] soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
The wait_for_completion() call in qman_delete_cgr_safe()
was triggering a scheduling while atomic bug, replacing the
kthread with a smp_call_function_single() call to fix it.
Signed-off-by: Madalin Bucur
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index e4f5bb0..ba3cfa8 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -2443,39 +2443,21 @@ struct cgr_comp {
struct completion completion;
};
-static int qman_delete_cgr_thread(void *p)
+static void qman_delete_cgr_smp_call(void *p)
{
- struct cgr_comp *cgr_comp = (struct cgr_comp *)p;
- int ret;
-
- ret = qman_delete_cgr(cgr_comp->cgr);
- complete(&cgr_comp->completion);
-
- return ret;
+ qman_delete_cgr((struct qman_cgr *)p);
}
void qman_delete_cgr_safe(struct qman_cgr *cgr)
{
- struct task_struct *thread;
- struct cgr_comp cgr_comp;
-
preempt_disable();
if (qman_cgr_cpus[cgr->cgrid] != smp_processor_id()) {
- init_completion(&cgr_comp.completion);
- cgr_comp.cgr = cgr;
- thread = kthread_create(qman_delete_cgr_thread, &cgr_comp,
- "cgr_del");
-
- if (IS_ERR(thread))
- goto out;
-
- kthread_bind(thread, qman_cgr_cpus[cgr->cgrid]);
- wake_up_process(thread);
- wait_for_completion(&cgr_comp.completion);
+ smp_call_function_single(qman_cgr_cpus[cgr->cgrid],
+qman_delete_cgr_smp_call, cgr, true);
preempt_enable();
return;
}
-out:
+
qman_delete_cgr(cgr);
preempt_enable();
}
--
2.1.0
[PATCH 0/5] DPAA Ethernet fixes
Hi, This patch set is addressing several issues in the DPAA Ethernet driver suite: - module unload crash caused by wrong reference to device being left in the cleanup code after the DSA related changes - scheduling wile atomic bug in QMan code revealed during dpaa_eth module unload - a couple of error counter fixes, a duplicated init in dpaa_eth. Madalin Camelia Groza (3): dpaa_eth: remove duplicate initialization dpaa_eth: increment the RX dropped counter when needed dpaa_eth: remove duplicate increment of the tx_errors counter Madalin Bucur (2): soc/fsl/qbman: fix issue in qman_delete_cgr_safe() dpaa_eth: fix error in dpaa_remove() drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 8 drivers/soc/fsl/qbman/qman.c | 28 +- 2 files changed, 9 insertions(+), 27 deletions(-) -- 2.1.0
Re: [PATCH v9 00/24] Speculative page faults
On 14/03/2018 14:11, Michal Hocko wrote: > On Tue 13-03-18 18:59:30, Laurent Dufour wrote: >> Changes since v8: >> - Don't check PMD when locking the pte when THP is disabled >>Thanks to Daniel Jordan for reporting this. >> - Rebase on 4.16 > > Is this really worth reposting the whole pile? I mean this is at v9, > each doing little changes. It is quite tiresome to barely get to a > bookmarked version just to find out that there are 2 new versions out. I agree, I could have sent only a change for the concerned patch. But the previous series has been sent a month ago and this one is rebased on the 4.16 kernel. > I am sorry to be grumpy and I can understand some frustration it doesn't > move forward that easilly but this is a _big_ change. We should start > with a real high level review rather than doing small changes here and > there and reach v20 quickly. > > I am planning to find some time to look at it but the spare cycles are > so rare these days... I understand that this is a big change and I'll try to not post a new series until I get more feedback from this one. Thanks, Laurent.
Re: [PATCH v9 00/24] Speculative page faults
On Tue 13-03-18 18:59:30, Laurent Dufour wrote: > Changes since v8: > - Don't check PMD when locking the pte when THP is disabled >Thanks to Daniel Jordan for reporting this. > - Rebase on 4.16 Is this really worth reposting the whole pile? I mean this is at v9, each doing little changes. It is quite tiresome to barely get to a bookmarked version just to find out that there are 2 new versions out. I am sorry to be grumpy and I can understand some frustration it doesn't move forward that easilly but this is a _big_ change. We should start with a real high level review rather than doing small changes here and there and reach v20 quickly. I am planning to find some time to look at it but the spare cycles are so rare these days... -- Michal Hocko SUSE Labs
[RESEND PATCH] Input: joystick/analog - Use get_cycles() on PPC
The analog joystick driver spits a warning at us:
drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer
not defined for this architecture.
PPC has get_cycles() so use that.
Signed-off-by: Michael Ellerman
---
drivers/input/joystick/analog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is the third resend, I'll take it via the powerpc tree if no one else
does.
cheers
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index c868a878c84f..a942c4ccd2af 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
#define GET_TIME(x)do { x = (unsigned int)rdtsc(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "TSC"
-#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) ||
defined(CONFIG_ARM64) || defined(CONFIG_RISCV) || defined(CONFIG_TILE)
+#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) ||
defined(CONFIG_ARM64) || defined(CONFIG_PPC) || defined(CONFIG_RISCV) ||
defined(CONFIG_TILE)
#define GET_TIME(x)do { x = get_cycles(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "get_cycles"
--
2.14.1
Re: [PATCH 04/21] powerpc: Mark both tmp variables as unused
Le 25/02/2018 à 18:22, Mathieu Malaterre a écrit :
Since the value of `tmp` is never intended to be read, declare both `tmp`
variables as unused. Fix warning (treated as error in W=1):
What about using fault_in_pages_readable() instead ?
Christophe
CC arch/powerpc/kernel/signal_32.o
arch/powerpc/kernel/signal_32.c: In function ‘sys_swapcontext’:
arch/powerpc/kernel/signal_32.c:1048:16: error: variable ‘tmp’ set but not used
[-Werror=unused-but-set-variable]
unsigned char tmp;
^~~
arch/powerpc/kernel/signal_32.c: In function ‘sys_debug_setcontext’:
arch/powerpc/kernel/signal_32.c:1234:16: error: variable ‘tmp’ set but not used
[-Werror=unused-but-set-variable]
unsigned char tmp;
^~~
cc1: all warnings being treated as errors
Signed-off-by: Mathieu Malaterre
---
arch/powerpc/kernel/signal_32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index a46de0035214..492f03451877 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -1045,7 +1045,7 @@ long sys_swapcontext(struct ucontext __user *old_ctx,
struct ucontext __user *new_ctx,
int ctx_size, int r6, int r7, int r8, struct pt_regs *regs)
{
- unsigned char tmp;
+ unsigned char tmp __maybe_unused;
int ctx_has_vsx_region = 0;
#ifdef CONFIG_PPC64
@@ -1231,7 +1231,7 @@ int sys_debug_setcontext(struct ucontext __user *ctx,
{
struct sig_dbg_op op;
int i;
- unsigned char tmp;
+ unsigned char tmp __maybe_unused;
unsigned long new_msr = regs->msr;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
unsigned long new_dbcr0 = current->thread.debug.dbcr0;
Re: [linux-next][bisected c7c133f3][gcc 4.8.5] build fail with error: first argument to ‘__builtin_choose_expr’ not a constant
On Wed, 2018-03-14 at 19:39 +1100, Stephen Rothwell wrote: > Hi Abdul, > > On Wed, 14 Mar 2018 13:59:54 +0530 Abdul Haleem > wrote: > > > > Today's next kernel fails to build with gcc 4.8.5 on powerpc machine. > > Thanks for the report. Just for the future, please include the > next- tag when making reports about linux-next. Sure, I will. next-20180313 is the bad tag > > > ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: > > ./include/linux/kernel.h:855:2: error: first argument to > > ‘__builtin_choose_expr’ not a constant > > __builtin_choose_expr(__builtin_constant_p(x) && \ > > ^ > > ./include/linux/kernel.h:867:19: note: in expansion of macro ‘__max’ > > #define max(x, y) __max(typeof(x), typeof(y), x, y) > > > > Machine Type: Power8 Baremetal > > gcc: 4.8.5 > > > > > > Builds fine when below patch is reverted > > c7c133f3 kernel.h: skip single-eval logic on literals in min()/max() > > Those patches have been removed from today's linux-next (next-20180314). -- Regard's Abdul Haleem IBM Linux Technology Centre
Re: PCI/hotplug: ppc: correct a php_slot usage after free
On Wed, 2018-03-07 at 08:46:04 UTC, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > In pnv_php_unregister_one(), pnv_php_put_slot() might kfree > php_slot structure. But there is pci_hp_deregister() after > that with php_slot reference. > > This patch moves pnv_php_put_slot() to the end of function. > > Signed-off-by: Simon Guo Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/97c6f25d5828b497e3e802b1f7c701 cheers
Re: [1/4] powerpc/pseries: Move smp_query_cpu_stopped() etc. out of plpar_wrappers.h
On Thu, 2018-03-08 at 02:54:39 UTC, Michael Ellerman wrote: > smp_query_cpu_stopped() and related #defines are currently in > plpar_wrappers.h. The function actually does an RTAS call, not an > hcall, and basically has nothing to do with plpar_wrappers.h > > Move it into pseries.h, where it can easily be used by the only two > callers in pseries/smp.c and pseries/hotplug-cpu.c. > > Signed-off-by: Michael Ellerman Series applied to powerpc next. https://git.kernel.org/powerpc/c/16560e88320d276036b393d4ba51cf cheers
Re: powerpc/powernv/mce: Don't silently restart the machine
On Thu, 2018-03-08 at 00:36:06 UTC, Balbir Singh wrote: > On MCE the current code will restart the machine with > ppc_md.restart(). This case was extremely unlikely since > prior to that a skiboot call is made and that resulted in > a checkstop for analysis. > > With newer skiboots, on P9 we don't checkstop the box by > default, instead we return back to the kernel to extract > useful information at the time of the MCE. While we still > get this information, this patch converts the restart to > a panic(), so that if configured a dump can be taken and > we can track and probably debug the potential issue causing > the MCE. > > Signed-off-by: Balbir Singh > Reviewed-by: Nicholas Piggin > Reviewed-by: Stewart Smith Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/5ee573e8ef034e687c420cb1091137 cheers
Re: [v2] xmon: Setup xmon debugger hooks when first break-point is set
On Sun, 2018-03-04 at 17:30:25 UTC, Vaibhav Jain wrote:
> Presently sysrq key for xmon('x') is registered during kernel init
> irrespective of the value of kernel param 'xmon'. Thus xmon is enabled
> even if 'xmon=off' is passed on the kernel command line. However this
> doesn't enable the kernel debugger hooks needed for instruction or data
> breakpoints. Thus when a break-point is hit with xmon=off a kernel oops
> of the form below is reported:
>
> Oops: Exception in kernel mode, sig: 5 [#1]
> < snip >
> Trace/breakpoint trap
>
> To fix this the patch checks and enables debugger hooks when an
> instruction or data break-point is set via xmon console.
>
> Signed-off-by: Vaibhav Jain
> Reviewed-by: Balbir Singh
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e1368d0c9edbc366e45216e7295fd6
cheers
Re: [v2, 01/10] powerpc/mm/slice: Simplify and optimise slice context initialisation
On Wed, 2018-03-07 at 01:37:09 UTC, Nicholas Piggin wrote: > The slice state of an mm gets zeroed then initialised upon exec. > This is the only caller of slice_set_user_psize now, so that can be > removed and instead implement a faster and simplified approach that > requires no locking or checking existing state. > > This speeds up vfork+exec+exit performance on POWER8 by 3%. > > Signed-off-by: Nicholas Piggin Patches 1-9 applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/1753dd1830367709144f68f539554d cheers
Re: selftests/powerpc: Skip tm-unavailable if TM is not enabled
On Mon, 2018-03-05 at 20:48:55 UTC, Gustavo Romero wrote:
> Some processor revisions do not support transactional memory, and
> additionally kernel support can be disabled. In either case the
> tm-unavailable test should be skipped, otherwise it will fail with
> a SIGILL.
>
> That commit also sets this selftest to be called through the test
> harness as it's done for other TM selftests.
>
> Finally, it avoids using "ping" as a thread name since it's
> ambiguous and can be confusing when shown, for instance,
> in a kernel backtrace log.
>
> Fixes: 77fad8bfb1d2 ("selftests/powerpc: Check FP/VEC on exception in TM")
> Signed-off-by: Gustavo Romero
> Reviewed-by: Cyril Bur
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b395e55b49ecd56ea28dc629f4ca4c
cheers
Re: xmon: Clear all breakpoints when xmon is disabled via debugfs
On Sun, 2018-03-04 at 17:31:32 UTC, Vaibhav Jain wrote: > Presently when xmon is disabled by debugfs any existing > instruction/data-access breakpoints set are not disabled. This may > lead to kernel oops when those breakpoints are hit as the necessary > debugger hooks aren't installed. > > Hence this patch introduces a new function named clear_all_bpt() > which is called when xmon is disabled via debugfs. The function will > unpatch/clear all the trap and ciabr/dab based breakpoints. > > Signed-off-by: Vaibhav Jain > Reviewed-by: Balbir Singh Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/1ff3b404019adf9d605224e1dce067 cheers
Re: [v2, 06/21] powerpc: Avoid comparison of unsigned long >= 0 in __access_ok
On Fri, 2018-03-02 at 19:50:51 UTC, Mathieu Malaterre wrote: > Rewrite function-like macro into regular static inline function to avoid a > warning during macro expansion. > Fix warning (treated as error in W=1): > > CC arch/powerpc/kernel/signal_32.o > In file included from ./include/linux/uaccess.h:14:0, > from ./include/asm-generic/termios-base.h:8, > from ./arch/powerpc/include/asm/termios.h:20, > from ./include/uapi/linux/termios.h:6, > from ./include/linux/tty.h:7, > from arch/powerpc/kernel/signal_32.c:36: > ./include/asm-generic/termios-base.h: In function > âuser_termio_to_kernel_termiosâ: > ./arch/powerpc/include/asm/uaccess.h:52:35: error: comparison of unsigned > expression >= 0 is always true [-Werror=type-limits] >(((size) == 0) || (((size) - 1) <= ((segment).seg - (addr) >^ > ./arch/powerpc/include/asm/uaccess.h:58:3: note: in expansion of macro > â__access_okâ >__access_ok((__force unsigned long)(addr), (size), get_fs())) >^~~ > ./arch/powerpc/include/asm/uaccess.h:262:6: note: in expansion of macro > âaccess_okâ > if (access_ok(VERIFY_READ, __gu_addr, (size))) \ > ^ > ./arch/powerpc/include/asm/uaccess.h:80:2: note: in expansion of macro > â__get_user_checkâ > __get_user_check((x), (ptr), sizeof(*(ptr))) > ^~~~ > ./include/asm-generic/termios-base.h:36:6: note: in expansion of macro > âget_userâ > if (get_user(termios->c_line, &termio->c_line) < 0) > ^~~~ > [...] > cc1: all warnings being treated as errors > > Suggested-by: Segher Boessenkool > Signed-off-by: Mathieu Malaterre > Reviewed-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/ef85dffd4251ff6c23056651f6f83b cheers
Re: [v2, 05/21] powerpc: Avoid comparison of unsigned long >= 0 in pfn_valid
On Wed, 2018-03-07 at 20:34:35 UTC, Mathieu Malaterre wrote: > Rewrite comparison since all values compared are of type `unsigned long`. > > Instead of using unsigned properties and rewriting the original code as: > (originally suggested by Segher Boessenkool ) > > #define pfn_valid(pfn) \ >(((pfn) - ARCH_PFN_OFFSET) < (max_mapnr - ARCH_PFN_OFFSET)) > > Prefer a static inline function to make code as readable as possible. > > Fix a warning (treated as error in W=1): > > CC arch/powerpc/kernel/irq.o > In file included from ./include/linux/bug.h:5:0, > from ./include/linux/cpumask.h:13, > from ./include/linux/smp.h:13, > from ./include/linux/kernel_stat.h:5, > from arch/powerpc/kernel/irq.c:35: > ./include/linux/dma-mapping.h: In function âdma_map_resourceâ: > ./arch/powerpc/include/asm/page.h:129:32: error: comparison of unsigned > expression >= 0 is always true [-Werror=type-limits] > #define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr) > ^ > Suggested-by: Christophe Leroy > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/603b892200e653dd7e86a0e4a31556 cheers
Re: powerpc/mm: Drop the function native_register_proc_table()
On Sat, 2018-03-03 at 09:24:02 UTC, Anshuman Khandual wrote: > This is left over from the segment table implementation and not getting > called from any where now. Hence just drop it. > > Suggested-by: Aneesh Kumar K.V > Signed-off-by: Anshuman Khandual Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/3d4f5f58484c8f86bfd9a97f152db6 cheers
Re: [v2,15/21] powerpc: Make function MMU_setup static
On Wed, 2018-03-07 at 20:32:55 UTC, Mathieu Malaterre wrote: > Since function `MMU_setup` is not meant to be exported, change the > signature to `static`. Fix warning (treated as error with W=1): > > CC kernel/sys.o > arch/powerpc/mm/init_32.c:102:13: error: no previous prototype for > âMMU_setupâ [-Werror=missing-prototypes] > void __init MMU_setup(void) > ^ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/d15a261d876da3267c8c706ef21e7f cheers
Re: powerpc/8xx: fix cpm_cascade() dual end of interrupt
On Tue, 2018-02-27 at 11:25:55 UTC, Christophe Leroy wrote: > cpm_cascade() doesn't have to call eoi() as it is already called > by handle_fasteoi_irq() > > And cpm_get_irq() will always return an unsigned int so the test > is useless > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/c554ac91ce2213faa91c51c4542377 cheers
Re: [v2,01/21] powerpc: Remove warning on array size when empty
On Fri, 2018-03-02 at 19:49:18 UTC, Mathieu Malaterre wrote:
> When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the
> array feature_properties is defined as an empty array, which in turn
> triggers the following warning (treated as error on W=1):
>
> CC arch/powerpc/kernel/prom.o
> arch/powerpc/kernel/prom.c: In function âcheck_cpu_feature_propertiesâ:
> arch/powerpc/kernel/prom.c:298:16: error: comparison of unsigned expression <
> 0 is always false [-Werror=type-limits]
> for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
> ^
> cc1: all warnings being treated as errors
>
> Suggested-by: Michael Ellerman
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4f1f40f7b2b4487f582ecafec64076
cheers
Re: [v3] powerpc/npu-dma.c: Fix deadlock in mmio_invalidate
On Fri, 2018-03-02 at 05:18:45 UTC, Alistair Popple wrote:
> When sending TLB invalidates to the NPU we need to send extra flushes due
> to a hardware issue. The original implementation would lock the all the
> ATSD MMIO registers sequentially before unlocking and relocking each of
> them sequentially to do the extra flush.
>
> This introduced a deadlock as it is possible for one thread to hold one
> ATSD register whilst waiting for another register to be freed while the
> other thread is holding that register waiting for the one in the first
> thread to be freed.
>
> For example if there are two threads and two ATSD registers:
>
> Thread A Thread B
> Acquire 1
> Acquire 2
> Release 1 Acquire 1
> Wait 1Wait 2
>
> Both threads will be stuck waiting to acquire a register resulting in an
> RCU stall warning or soft lockup.
>
> This patch solves the deadlock by refactoring the code to ensure registers
> are not released between flushes and to ensure all registers are either
> acquired or released together and in order.
>
> Fixes: bbd5ff50afff ("powerpc/powernv/npu-dma: Add explicit flush when
> sending an ATSD")
> Signed-off-by: Alistair Popple
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2b74e2a9b39df40a2b489af2d24079
cheers
Re: [v10,1/2] powerpc/powernv: Enable tunneled operations
On Fri, 2018-03-02 at 09:56:11 UTC, Philippe Bergheaud wrote: > P9 supports PCI tunneled operations (atomics and as_notify). This > patch adds support for tunneled operations on powernv, with a new > API, to be called by device drivers: > > pnv_pci_enable_tunnel() >Enable tunnel operations, tell driver the 16-bit ASN indication >used by kernel. > > pnv_pci_disable_tunnel() >Disable tunnel operations. > > pnv_pci_set_tunnel_bar() >Tell kernel the Tunnel BAR Response address used by driver. >This function uses two new OPAL calls, as the PBCQ Tunnel BAR >register is configured by skiboot. > > pnv_pci_get_as_notify_info() >Return the ASN info of the thread to be woken up. > > Signed-off-by: Philippe Bergheaud > Reviewed-by: Frederic Barrat > Reviewed-by: Christophe Lombard Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/d6a90bb83b5084829558788ea5b881 cheers
Re: [21/21] powerpc: Add missing prototypes in setup_32.c
On Sun, 2018-02-25 at 17:22:36 UTC, Mathieu Malaterre wrote: > This commit add the prototypes for the following function: > > - early_init > - machine_init > - ppc_setup_l2cr > - ppc_setup_l3cr > - ppc_init > > the other missing ones were already added in setup.h previously. Fix the > following warnings (treated as error in W=1): > > AR init/built-in.o > arch/powerpc/kernel/setup_32.c:68:30: error: no previous prototype for > âearly_initâ [-Werror=missing-prototypes] > notrace unsigned long __init early_init(unsigned long dt_ptr) > ^~ > arch/powerpc/kernel/setup_32.c:99:21: error: no previous prototype for > âmachine_initâ [-Werror=missing-prototypes] > notrace void __init machine_init(u64 dt_ptr) > ^~~~ > arch/powerpc/kernel/setup_32.c:124:12: error: no previous prototype for > âppc_setup_l2crâ [-Werror=missing-prototypes] > int __init ppc_setup_l2cr(char *str) > ^~ > arch/powerpc/kernel/setup_32.c:137:12: error: no previous prototype for > âppc_setup_l3crâ [-Werror=missing-prototypes] > int __init ppc_setup_l3cr(char *str) > ^~ > arch/powerpc/kernel/setup_32.c:183:12: error: no previous prototype for > âppc_initâ [-Werror=missing-prototypes] > int __init ppc_init(void) > ^~~~ > arch/powerpc/kernel/setup_32.c:198:13: error: no previous prototype for > âirqstack_early_initâ [-Werror=missing-prototypes] > void __init irqstack_early_init(void) > ^~~ > arch/powerpc/kernel/setup_32.c:238:13: error: no previous prototype for > âsetup_power_saveâ [-Werror=missing-prototypes] > void __init setup_power_save(void) > ^~~~ > arch/powerpc/kernel/setup_32.c:253:13: error: no previous prototype for > âinitialize_cache_infoâ [-Werror=missing-prototypes] > __init void initialize_cache_info(void) > ^ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e82d70cf965072a3872ea97b7d8df4 cheers
Re: [08/21] powerpc: Make function __giveup_fpu static
On Sun, 2018-02-25 at 17:22:23 UTC, Mathieu Malaterre wrote: > When CONFIG_PPC_FPU is defined the prototype exposed in asm/switch_to.h is: > > extern void giveup_fpu(struct task_struct *); > > Change the function prototype of __giveup_fpu to static. Fix warning > (treated as error in W=1): > > CC arch/powerpc/kernel/process.o > arch/powerpc/kernel/process.c:176:6: error: no previous prototype for > â__giveup_fpuâ [-Werror=missing-prototypes] > void __giveup_fpu(struct task_struct *tsk) > ^~~~ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/1cdf039bf82a39d816ca4b8161b01c cheers
Re: [20/21] powerpc: Add missing prototypes for ppc_select & ppc_fadvise64_64
On Sun, 2018-02-25 at 17:22:35 UTC, Mathieu Malaterre wrote: > Add missing prototypes for ppc_select & ppc_fadvise64_64 to header > asm-prototypes.h. Fix the following warnings (treated as errors in W=1) > > CC arch/powerpc/kernel/syscalls.o > arch/powerpc/kernel/syscalls.c:87:1: error: no previous prototype for > âppc_selectâ [-Werror=missing-prototypes] > ppc_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user > *exp, struct timeval __user *tvp) > ^~ > arch/powerpc/kernel/syscalls.c:119:6: error: no previous prototype for > âppc_fadvise64_64â [-Werror=missing-prototypes] > long ppc_fadvise64_64(int fd, int advice, u32 offset_high, u32 offset_low, > ^~~~ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/bf7fb32dd5fc8a6bd25aaab05d3acd cheers
Re: [19/21] powerpc: Add missing prototypes for hw_breakpoint_handler & arch_unregister_hw_breakpoint
On Sun, 2018-02-25 at 17:22:34 UTC, Mathieu Malaterre wrote:
> In commit 5aae8a537080 ("powerpc, hw_breakpoints: Implement hw_breakpoints
> for 64-bit server processors") function hw_breakpoint_handler and
> arch_unregister_hw_breakpoint were added without function prototypes in
> hw_breakpoint.h header.
>
> Fix the following warning(s) (treated as error in W=1):
>
> AR init/built-in.o
> arch/powerpc/kernel/hw_breakpoint.c:106:6: error: no previous prototype for
> âarch_unregister_hw_breakpointâ [-Werror=missing-prototypes]
> void arch_unregister_hw_breakpoint(struct perf_event *bp)
> ^
> arch/powerpc/kernel/hw_breakpoint.c:209:5: error: no previous prototype for
> âhw_breakpoint_handlerâ [-Werror=missing-prototypes]
> int hw_breakpoint_handler(struct die_args *args)
> ^
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b0d876da1d1cd33a1c28049512a136
cheers
Re: [17/21] powerpc: Add missing prototype for sys_debug_setcontext
On Sun, 2018-02-25 at 17:22:32 UTC, Mathieu Malaterre wrote:
> In commit 81e7009ea46c ("powerpc: merge ppc signal.c and ppc64 signal32.c")
> the function sys_debug_setcontext was added without a prototype.
>
> Fix compilation warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/signal_32.o
> arch/powerpc/kernel/signal_32.c:1227:5: error: no previous prototype for
> âsys_debug_setcontextâ [-Werror=missing-prototypes]
> int sys_debug_setcontext(struct ucontext __user *ctx,
> ^~~~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0d60619e1c0ca20eb2610361034992
cheers
Re: [18/21] powerpc: Add missing prototypes for sys_sigreturn & sys_rt_sigreturn
On Sun, 2018-02-25 at 17:22:33 UTC, Mathieu Malaterre wrote: > Two functions did not have a prototype defined in signal.h header. Fix the > following two warnings (treated as errors in W=1): > > CC arch/powerpc/kernel/signal_32.o > arch/powerpc/kernel/signal_32.c:1135:6: error: no previous prototype for > âsys_rt_sigreturnâ [-Werror=missing-prototypes] > long sys_rt_sigreturn(int r3, int r4, int r5, int r6, int r7, int r8, > ^~~~ > arch/powerpc/kernel/signal_32.c:1422:6: error: no previous prototype for > âsys_sigreturnâ [-Werror=missing-prototypes] > long sys_sigreturn(int r3, int r4, int r5, int r6, int r7, int r8, > ^ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/b53875c4b4f212a7a8e505e2d10635 cheers
Re: [16/21] powerpc: Add missing prototype for init_IRQ
On Sun, 2018-02-25 at 17:22:31 UTC, Mathieu Malaterre wrote: > A function init_IRQ was added without a prototype declared in header irq.h. > Fix the following warning (treated as error in W=1): > > CC arch/powerpc/kernel/irq.o > arch/powerpc/kernel/irq.c:662:13: error: no previous prototype for > âinit_IRQâ [-Werror=missing-prototypes] > void __init init_IRQ(void) > ^~~~ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/23a6d8b9634897add6ebff32372f34 cheers
Re: [13/21] powerpc: Add missing prototype for arch_dup_task_struct
On Sun, 2018-02-25 at 17:22:28 UTC, Mathieu Malaterre wrote:
> In commit 55ccf3fe3f9a ("fork: move the real prepare_to_copy() users to
> arch_dup_task_struct()") a new arch_dup_task_struct was added without a
> prototype declared in thread_info.h header. Fix the following warning
> (treated as error in W=1):
>
> CC arch/powerpc/kernel/process.o
> arch/powerpc/kernel/process.c:1609:5: error: no previous prototype for
> âarch_dup_task_structâ [-Werror=missing-prototypes]
> int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
> ^~~~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fd70d9f96d8182a67e28b99c999157
cheers
Re: [14/21] powerpc: Add missing prototype for arch_irq_work_raise
On Sun, 2018-02-25 at 17:22:29 UTC, Mathieu Malaterre wrote:
> In commit 4f8b50bbbe63 ("irq_work, ppc: Fix up arch hooks") a new function
> arch_irq_work_raise was added without a prototype in header irq_work.h.
>
> Fix the following warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/time.o
> arch/powerpc/kernel/time.c:523:6: error: no previous prototype for
> âarch_irq_work_raiseâ [-Werror=missing-prototypes]
> void arch_irq_work_raise(void)
> ^~~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f5246862f82f1e16bbf84cda4cddf2
cheers
Re: [12/21] powerpc: Add missing prototype for time_init
On Sun, 2018-02-25 at 17:22:27 UTC, Mathieu Malaterre wrote: > The function time_init did not have a prototype defined in the time.h > header. Fix the following warning (treated as error in W=1): > > CC arch/powerpc/kernel/time.o > arch/powerpc/kernel/time.c:1068:13: error: no previous prototype for > âtime_initâ [-Werror=missing-prototypes] > void __init time_init(void) > ^ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/848092faa0c7687a99bf465808f7da cheers
Re: [11/21] powerpc: Add missing prototype for hdec_interrupt
On Sun, 2018-02-25 at 17:22:26 UTC, Mathieu Malaterre wrote:
> In commit dabe859ec636 ("powerpc: Give hypervisor decrementer interrupts
> their own handler") an empty body function was added, but no prototype was
> declared. Fix warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/time.o
> arch/powerpc/kernel/time.c:629:6: error: no previous prototype for
> âhdec_interruptâ [-Werror=missing-prototypes]
> void hdec_interrupt(struct pt_regs *regs)
> ^~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8b604faff7d421904ebd1fa65d642f
cheers
Re: [10/21] powerpc: Add missing prototype for slb_miss_bad_addr
On Sun, 2018-02-25 at 17:22:25 UTC, Mathieu Malaterre wrote:
> In commit f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused
> by access to bogus address"), the function slb_miss_bad_addr was added
> without a prototype. This commit adds it.
>
> Fix a warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/traps.o
> arch/powerpc/kernel/traps.c:1498:6: error: no previous prototype for
> âslb_miss_bad_addrâ [-Werror=missing-prototypes]
> void slb_miss_bad_addr(struct pt_regs *regs)
> ^
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/45b4d27a3897d6094bcf84bc877439
cheers
Re: [07/21] powerpc: Make functions flipper_pic_init & ug_udbg_putc static
On Sun, 2018-02-25 at 17:22:22 UTC, Mathieu Malaterre wrote: > Change signature of two functions, adding static keyword to prevent the > following two warnings (treated as errors on W=1): > > CC kernel/sys.o > arch/powerpc/platforms/embedded6xx/flipper-pic.c:135:28: error: no previous > prototype for âflipper_pic_initâ [-Werror=missing-prototypes] > struct irq_domain * __init flipper_pic_init(struct device_node *np) > ^~~~ > cc1: all warnings being treated as errors > > and > > CC arch/powerpc/platforms/embedded6xx/usbgecko_udbg.o > arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c:172:6: error: no previous > prototype for âug_udbg_putcâ [-Werror=missing-prototypes] > void ug_udbg_putc(char ch) > ^~~~ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8b51e679a54e808bdf1f2cc6552cf2 cheers
Re: [04/21] powerpc: Mark both tmp variables as unused
On Sun, 2018-02-25 at 17:22:19 UTC, Mathieu Malaterre wrote: > Since the value of `tmp` is never intended to be read, declare both `tmp` > variables as unused. Fix warning (treated as error in W=1): > > CC arch/powerpc/kernel/signal_32.o > arch/powerpc/kernel/signal_32.c: In function âsys_swapcontextâ: > arch/powerpc/kernel/signal_32.c:1048:16: error: variable âtmpâ set but > not used [-Werror=unused-but-set-variable] > unsigned char tmp; > ^~~ > arch/powerpc/kernel/signal_32.c: In function âsys_debug_setcontextâ: > arch/powerpc/kernel/signal_32.c:1234:16: error: variable âtmpâ set but > not used [-Werror=unused-but-set-variable] > unsigned char tmp; > ^~~ > cc1: all warnings being treated as errors > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/67b464a89c21c9edd45ad15c457bb5 cheers
Re: [02/21] powerpc: Move the inline keyword at the beginning of function declaration
On Sun, 2018-02-25 at 17:22:17 UTC, Mathieu Malaterre wrote: > The inline keyword was not at the beginning of the function declaration. > Fix the following warning (treated as error in W=1) > > CC kernel/sys.o > arch/powerpc/lib/sstep.c:283:1: error: âinlineâ is not at beginning of > declaration [-Werror=old-style-declaration] > static int nokprobe_inline copy_mem_in(u8 *dest, unsigned long ea, int nb, > ^~ > arch/powerpc/lib/sstep.c:388:1: error: âinlineâ is not at beginning of > declaration [-Werror=old-style-declaration] > static int nokprobe_inline copy_mem_out(u8 *dest, unsigned long ea, int nb, > ^~ > CC arch/powerpc/kernel/setup_32.o > > Signed-off-by: Mathieu Malaterre Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/174b701d3dcd14514f869e2bc08ac4 cheers
Re: [v2] cxl: Check if PSL data-cache is available before issue flush request
On Thu, 2018-02-15 at 15:49:24 UTC, Vaibhav Jain wrote: > PSL9D doesn't have a data-cache that needs to be flushed before > resetting the card. However when cxl tries to flush data-cache on such > a card, it times-out as PSL_Control register never indicates flush > operation complete due to missing data-cache. This is usually > indicated in the kernel logs with this message: > > "WARNING: cache flush timed out" > > To fix this the patch checks PSL_Debug register CDC-Field(BIT:27) > which indicates the absence of a data-cache and sets a flag > 'no_data_cache' in 'struct cxl_native' to indicate this. When > cxl_data_cache_flush() is called it checks the flag and if set bails > out early without requesting a data-cache flush operation to the PSL. > > Signed-off-by: Vaibhav Jain > Acked-by: Andrew Donnellan > Acked-by: Frederic Barrat Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/94322ed8e857e3b2a33cf75118051a cheers
Re: [v2] cxl: Remove function write_timebase_ctrl_psl9() for PSL9
On Thu, 2018-02-15 at 06:19:36 UTC, Vaibhav Jain wrote: > For PSL9 the contents of PSL_TB_CTLSTAT register have changed in PSL9 > and all of the register is now readonly. Hence we don't need an sl_ops > implementation for 'write_timebase_ctrl' for to populate this register > for PSL9. > > Hence this patch removes function write_timebase_ctrl_psl9() and its > references from the code. > > Signed-off-by: Vaibhav Jain > Acked-by: Andrew Donnellan > Acked-by: Frederic Barrat Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/02b63b420223db3e33e19cc0aaf346 cheers
Re: [v2] powerpc/via-pmu: Fix section mismatch warning
On Wed, 2018-02-14 at 21:15:18 UTC, Mathieu Malaterre wrote: > Make the struct via_pmu_driver const to avoid following warning: > > WARNING: vmlinux.o(.data+0x4739c): Section mismatch in reference from the > variable via_pmu_driver to the function .init.text:pmu_init() > The variable via_pmu_driver references > the function __init pmu_init() > If the reference is valid then annotate the > variable with __init* or __refdata (see linux/init.h) or name the variable: > *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console > > Signed-off-by: Mathieu Malaterre > Suggested-by: Laurent Vivier > Reviewed-by: Laurent Vivier Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/58935176ad17976b7a7f6ea25c0ceb cheers
Re: cxl: Enable NORST bit in PSL_DEBUG register for PSL9
On Fri, 2018-02-09 at 04:09:16 UTC, Vaibhav Jain wrote: > We enable the NORST bit by default for debug afu images to prevent > reset of AFU trace-data on a PCI link drop. For production AFU images > this bit is always ignored and PSL gets reconfigured anyways thereby > resetting the trace data. So setting this bit for non-debug images > doesn't have any impact. > > Signed-off-by: Vaibhav Jain > Reviewed-by: Christophe Lombard > Acked-by: Frederic Barrat > Acked-by: Andrew Donnellan Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/03ebb419b896e0fb2da3f34b57d45e cheers
Re: powerpc/epapr: Move register keyword at the beginning of declaration
On Wed, 2018-01-31 at 07:54:43 UTC, Mathieu Malaterre wrote:
> Fix warning for all register unsigned long (0,3-12) that appear during W=1
> compilation:
>
> ./arch/powerpc/include/asm/epapr_hcalls.h:479:2: warning: âregisterâ is
> not at beginning of declaration [-Wold-style-declaration]
> unsigned long register r[\d] asm("r[\d]");
>
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/65e13c202d7826dc3497c32961008d
cheers
Re: [v2] macintosh: Add module license to ans-lcd
On Tue, 2018-01-30 at 14:23:51 UTC, Larry Finger wrote: > In kernel 4.15, the modprobe step on my PowerBook G4 started complaining that > there was no module license for ans-lcd. > > Signed-off-by: Larry Finger Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/47d703e1d55f068c737c0c9f0c18f0 cheers
Re: [1/5] powerpc/vas: Remove a stray line in Makefile
On Wed, 2018-01-17 at 02:50:39 UTC, Sukadev Bhattiprolu wrote:
> Remove a bogus line from arch/powerpc/platforms/powernv/Makefile that
> was added by commit ece4e51 ("powerpc/vas: Export HVWC to debugfs").
>
> Signed-off-by: Sukadev Bhattiprolu
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2f65272a2a304ec6aa32ad9a45b150
cheers
Re: [1/1] vas: vas_window_init_dbgdir: fix order of cleanup.
On Wed, 2017-12-20 at 01:10:29 UTC, Sukadev Bhattiprolu wrote: > Fix the order of cleanup to ensure we free the name buffer in case > of an error creating 'hvwc' or 'info' files. > > Signed-off-by: Sukadev Bhattiprolu Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/1373cc31074dff09419d616c2ce911 cheers
Re: selftest/powerpc: Add test for sigreturn in transaction
On Mon, 2016-08-22 at 16:53:02 UTC, Laurent Dufour wrote: > Ensure that kernel is throwing away the suspended transaction when > sigreturn() is called otherwise it if fails to restore the signal > frame's TM SPRS. > > Signed-off-by: Laurent Dufour > Reviewed-by: Cyril Bur Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/9c96c932871efeabe82fcfdc952f35 cheers
Re: powerpc/64s: Fix NULL AT_BASE_PLATFORM when using DT CPU features
On Tue, 2018-03-13 at 23:14:11 UTC, Michael Ellerman wrote: > When running virtualised the powerpc kernel is able to run the system > in "compat mode" - which means the kernel and hardware are pretending > to userspace that the CPU is an older version than it actually is. > > AT_BASE_PLATFORM is an AUXV entry that we export to userspace for use > when we're running in that mode, which tells userspace the "platform" > string for the real CPU version, as opposed to the faked version. > > Although we don't support compat mode when using DT CPU features, and > arguably don't need to set AT_BASE_PLATFORM, the existing cputable > based code always sets it even when we're running bare metal. That > means the lack of AT_BASE_PLATFORM is a user-visible artifact of the > fact that the kernel is using DT CPU features, which we don't want. > > So set it in the DT CPU features code also. > > This results in eg: > $ LD_SHOW_AUXV=1 /bin/true | grep "AT_.*PLATFORM" > AT_PLATFORM: power9 > AT_BASE_PLATFORM:power9 > > Signed-off-by: Michael Ellerman > Reviewed-by: Nicholas Piggin Applied to powerpc fixes. https://git.kernel.org/powerpc/c/e4b79900222b8cccd4da4a7a89581f cheers
