* [PATCH v5 06/10] powerpc/pmem: Avoid the barrier in flush routines
From: Aneesh Kumar K.V @ 2020-06-10 6:23 UTC (permalink / raw)
To: linuxppc-dev, mpe, linux-nvdimm, dan.j.williams
Cc: Jan Kara, Jeff Moyer, msuchanek, oohall, Aneesh Kumar K.V
In-Reply-To: <20200610062343.492293-1-aneesh.kumar@linux.ibm.com>
nvdimm expect the flush routines to just mark the cache clean. The barrier
that mark the store globally visible is done in nvdimm_flush().
Update the papr_scm driver to a simplified nvdim_flush callback that do
only the required barrier.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/lib/pmem.c | 6 ------
arch/powerpc/platforms/pseries/papr_scm.c | 13 +++++++++++++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
index 5a61aaeb6930..21210fa676e5 100644
--- a/arch/powerpc/lib/pmem.c
+++ b/arch/powerpc/lib/pmem.c
@@ -19,9 +19,6 @@ static inline void __clean_pmem_range(unsigned long start, unsigned long stop)
for (i = 0; i < size >> shift; i++, addr += bytes)
asm volatile(PPC_DCBSTPS(%0, %1): :"i"(0), "r"(addr): "memory");
-
-
- asm volatile(PPC_PHWSYNC ::: "memory");
}
static inline void __flush_pmem_range(unsigned long start, unsigned long stop)
@@ -34,9 +31,6 @@ static inline void __flush_pmem_range(unsigned long start, unsigned long stop)
for (i = 0; i < size >> shift; i++, addr += bytes)
asm volatile(PPC_DCBFPS(%0, %1): :"i"(0), "r"(addr): "memory");
-
-
- asm volatile(PPC_PHWSYNC ::: "memory");
}
static inline void clean_pmem_range(unsigned long start, unsigned long stop)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f35592423380..ad506e7003c9 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -285,6 +285,18 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
return 0;
}
+/*
+ * We have made sure the pmem writes are done such that before calling this
+ * all the caches are flushed/clean. We use dcbf/dcbfps to ensure this. Here
+ * we just need to add the necessary barrier to make sure the above flushes
+ * are have updated persistent storage before any data access or data transfer
+ * caused by subsequent instructions is initiated.
+ */
+static int papr_scm_flush_sync(struct nd_region *nd_region, struct bio *bio)
+{
+ arch_pmem_flush_barrier();
+ return 0;
+}
static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
{
@@ -340,6 +352,7 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
ndr_desc.mapping = &mapping;
ndr_desc.num_mappings = 1;
ndr_desc.nd_set = &p->nd_set;
+ ndr_desc.flush = papr_scm_flush_sync;
if (p->is_volatile)
p->region = nvdimm_volatile_region_create(p->bus, &ndr_desc);
--
2.26.2
^ permalink raw reply related
* [PATCH v5 05/10] powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction.
From: Aneesh Kumar K.V @ 2020-06-10 6:23 UTC (permalink / raw)
To: linuxppc-dev, mpe, linux-nvdimm, dan.j.williams
Cc: Jan Kara, Jeff Moyer, msuchanek, oohall, Aneesh Kumar K.V
In-Reply-To: <20200610062343.492293-1-aneesh.kumar@linux.ibm.com>
of_pmem on POWER10 can now use phwsync instead of hwsync to ensure
all previous writes are architecturally visible for the platform
buffer flush.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/cacheflush.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/cacheflush.h b/arch/powerpc/include/asm/cacheflush.h
index 81808d1b54ca..bb56a49c9a66 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -120,6 +120,13 @@ static inline void invalidate_dcache_range(unsigned long start,
#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
memcpy(dst, src, len)
+
+#define arch_pmem_flush_barrier arch_pmem_flush_barrier
+static inline void arch_pmem_flush_barrier(void)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ asm volatile(PPC_PHWSYNC ::: "memory");
+}
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHEFLUSH_H */
--
2.26.2
^ permalink raw reply related
* [PATCH v5 02/10] powerpc/pmem: Add new instructions for persistent storage and sync
From: Aneesh Kumar K.V @ 2020-06-10 6:23 UTC (permalink / raw)
To: linuxppc-dev, mpe, linux-nvdimm, dan.j.williams
Cc: Jan Kara, Jeff Moyer, msuchanek, oohall, Aneesh Kumar K.V
In-Reply-To: <20200610062343.492293-1-aneesh.kumar@linux.ibm.com>
POWER10 introduces two new variants of dcbf instructions (dcbstps and dcbfps)
that can be used to write modified locations back to persistent storage.
Additionally, POWER10 also introduce phwsync and plwsync which can be used
to establish order of these writes to persistent storage.
This patch exposes these instructions to the rest of the kernel. The existing
dcbf and hwsync instructions in P8 and P9 are adequate to enable appropriate
synchronization with OpenCAPI-hosted persistent storage. Hence the new
instructions are added as a variant of the old ones that old hardware
won't differentiate.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/ppc-opcode.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 2a39c716c343..1ad014e4633e 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -219,6 +219,8 @@
#define PPC_INST_STWCX 0x7c00012d
#define PPC_INST_LWSYNC 0x7c2004ac
#define PPC_INST_SYNC 0x7c0004ac
+#define PPC_INST_PHWSYNC 0x7c8004ac
+#define PPC_INST_PLWSYNC 0x7ca004ac
#define PPC_INST_SYNC_MASK 0xfc0007fe
#define PPC_INST_ISYNC 0x4c00012c
#define PPC_INST_LXVD2X 0x7c000698
@@ -284,6 +286,8 @@
#define PPC_INST_TABORT 0x7c00071d
#define PPC_INST_TSR 0x7c0005dd
+#define PPC_INST_DCBF 0x7c0000ac
+
#define PPC_INST_NAP 0x4c000364
#define PPC_INST_SLEEP 0x4c0003a4
#define PPC_INST_WINKLE 0x4c0003e4
@@ -532,6 +536,14 @@
#define STBCIX(s,a,b) stringify_in_c(.long PPC_INST_STBCIX | \
__PPC_RS(s) | __PPC_RA(a) | __PPC_RB(b))
+#define PPC_DCBFPS(a, b) stringify_in_c(.long PPC_INST_DCBF | \
+ ___PPC_RA(a) | ___PPC_RB(b) | (4 << 21))
+#define PPC_DCBSTPS(a, b) stringify_in_c(.long PPC_INST_DCBF | \
+ ___PPC_RA(a) | ___PPC_RB(b) | (6 << 21))
+
+#define PPC_PHWSYNC stringify_in_c(.long PPC_INST_PHWSYNC)
+#define PPC_PLWSYNC stringify_in_c(.long PPC_INST_PLWSYNC)
+
/*
* Define what the VSX XX1 form instructions will look like, then add
* the 128 bit load store instructions based on that.
--
2.26.2
^ permalink raw reply related
* [PATCH v5 03/10] powerpc/pmem: Add flush routines using new pmem store and sync instruction
From: Aneesh Kumar K.V @ 2020-06-10 6:23 UTC (permalink / raw)
To: linuxppc-dev, mpe, linux-nvdimm, dan.j.williams
Cc: Jan Kara, Jeff Moyer, msuchanek, oohall, Aneesh Kumar K.V
In-Reply-To: <20200610062343.492293-1-aneesh.kumar@linux.ibm.com>
Start using dcbstps; phwsync; sequence for flushing persistent memory range.
The new instructions are implemented as a variant of dcbf and hwsync and on
P8 and P9 they will be executed as those instructions. We avoid using them on
older hardware. This helps to avoid difficult to debug bugs.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/cacheflush.h | 1 +
arch/powerpc/lib/pmem.c | 50 ++++++++++++++++++++++++---
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h b/arch/powerpc/include/asm/cacheflush.h
index e92191b390f3..81808d1b54ca 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -8,6 +8,7 @@
#include <linux/mm.h>
#include <asm/cputable.h>
+#include <asm/cpu_has_feature.h>
/*
* No cache flushing is required when address mappings are changed,
diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
index 0666a8d29596..5a61aaeb6930 100644
--- a/arch/powerpc/lib/pmem.c
+++ b/arch/powerpc/lib/pmem.c
@@ -9,20 +9,62 @@
#include <asm/cacheflush.h>
+static inline void __clean_pmem_range(unsigned long start, unsigned long stop)
+{
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
+ void *addr = (void *)(start & ~(bytes - 1));
+ unsigned long size = stop - (unsigned long)addr + (bytes - 1);
+ unsigned long i;
+
+ for (i = 0; i < size >> shift; i++, addr += bytes)
+ asm volatile(PPC_DCBSTPS(%0, %1): :"i"(0), "r"(addr): "memory");
+
+
+ asm volatile(PPC_PHWSYNC ::: "memory");
+}
+
+static inline void __flush_pmem_range(unsigned long start, unsigned long stop)
+{
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
+ void *addr = (void *)(start & ~(bytes - 1));
+ unsigned long size = stop - (unsigned long)addr + (bytes - 1);
+ unsigned long i;
+
+ for (i = 0; i < size >> shift; i++, addr += bytes)
+ asm volatile(PPC_DCBFPS(%0, %1): :"i"(0), "r"(addr): "memory");
+
+
+ asm volatile(PPC_PHWSYNC ::: "memory");
+}
+
+static inline void clean_pmem_range(unsigned long start, unsigned long stop)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ return __clean_pmem_range(start, stop);
+}
+
+static inline void flush_pmem_range(unsigned long start, unsigned long stop)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ return __flush_pmem_range(start, stop);
+}
+
/*
* CONFIG_ARCH_HAS_PMEM_API symbols
*/
void arch_wb_cache_pmem(void *addr, size_t size)
{
unsigned long start = (unsigned long) addr;
- flush_dcache_range(start, start + size);
+ clean_pmem_range(start, start + size);
}
EXPORT_SYMBOL_GPL(arch_wb_cache_pmem);
void arch_invalidate_pmem(void *addr, size_t size)
{
unsigned long start = (unsigned long) addr;
- flush_dcache_range(start, start + size);
+ flush_pmem_range(start, start + size);
}
EXPORT_SYMBOL_GPL(arch_invalidate_pmem);
@@ -35,7 +77,7 @@ long __copy_from_user_flushcache(void *dest, const void __user *src,
unsigned long copied, start = (unsigned long) dest;
copied = __copy_from_user(dest, src, size);
- flush_dcache_range(start, start + size);
+ clean_pmem_range(start, start + size);
return copied;
}
@@ -45,7 +87,7 @@ void *memcpy_flushcache(void *dest, const void *src, size_t size)
unsigned long start = (unsigned long) dest;
memcpy(dest, src, size);
- flush_dcache_range(start, start + size);
+ clean_pmem_range(start, start + size);
return dest;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v5 00/10] Support new pmem flush and sync instructions for POWER
From: Aneesh Kumar K.V @ 2020-06-10 6:23 UTC (permalink / raw)
To: linuxppc-dev, mpe, linux-nvdimm, dan.j.williams
Cc: Jan Kara, Jeff Moyer, msuchanek, oohall, Aneesh Kumar K.V
This patch series enables the usage os new pmem flush and sync instructions on POWER
architecture. POWER10 introduces two new variants of dcbf instructions (dcbstps and dcbfps)
that can be used to write modified locations back to persistent storage. Additionally,
POWER10 also introduce phwsync and plwsync which can be used to establish order of these
writes to persistent storage.
This series exposes these instructions to the rest of the kernel. The existing
dcbf and hwsync instructions in P8 and P9 are adequate to enable appropriate
synchronization with OpenCAPI-hosted persistent storage. Hence the new instructions
are added as a variant of the old ones that old hardware won't differentiate.
On POWER10, pmem devices will be represented by a different device tree compat
strings. This ensures that older kernels won't initialize pmem devices on POWER10.
W.r.t userspace we want to make sure applications are enabled to use MAP_SYNC only
if they are using the new instructions. To avoid the wrong usage of MAP_SYNC on
newer hardware, we disable MAP_SYNC by default on newer hardware. The namespace specific
attribute /sys/block/pmem0/dax/sync_fault can be used to enable MAP_SYNC later.
With this:
1) vPMEM continues to work since it is a volatile region. That
doesn't need any flush instructions.
2) pmdk and other user applications get updated to use new instructions
and updated packages are made available to all distributions
3) On newer hardware, the device will appear with a new compat string.
Hence older distributions won't initialize pmem on newer hardware.
4) If we have a newer kernel with an older distro, we use the per
namespace sysfs knob that prevents the usage of MAP_SYNC.
5) Sometime in the future, we mark the CONFIG_ARCH_MAP_SYNC_DISABLE=n
on ppc64 when we are confident that everybody is using the new flush
instruction.
Chaanges from V4:
* Add namespace specific sychronous fault control.
Changes from V3:
* Add new compat string to be used for the device.
* Use arch_pmem_flush_barrier() in dm-writecache.
Aneesh Kumar K.V (10):
powerpc/pmem: Restrict papr_scm to P8 and above.
powerpc/pmem: Add new instructions for persistent storage and sync
powerpc/pmem: Add flush routines using new pmem store and sync
instruction
libnvdimm/nvdimm/flush: Allow architecture to override the flush
barrier
powerpc/pmem/of_pmem: Update of_pmem to use the new barrier
instruction.
powerpc/pmem: Avoid the barrier in flush routines
powerpc/book3s/pmem: Add WARN_ONCE to catch the wrong usage of pmem
flush functions.
libnvdimm/dax: Add a dax flag to control synchronous fault support
powerpc/pmem: Disable synchronous fault by default
powerpc/pmem: Initialize pmem device on newer hardware
arch/powerpc/include/asm/cacheflush.h | 10 ++++
arch/powerpc/include/asm/ppc-opcode.h | 12 ++++
arch/powerpc/lib/pmem.c | 46 ++++++++++++--
arch/powerpc/platforms/Kconfig.cputype | 9 +++
arch/powerpc/platforms/pseries/papr_scm.c | 31 +++++++++-
arch/powerpc/platforms/pseries/pmem.c | 6 ++
drivers/dax/bus.c | 2 +-
drivers/dax/super.c | 73 +++++++++++++++++++++++
drivers/md/dm-writecache.c | 2 +-
drivers/nvdimm/of_pmem.c | 8 +++
drivers/nvdimm/pmem.c | 4 ++
drivers/nvdimm/region_devs.c | 24 ++++++--
include/linux/dax.h | 16 +++++
include/linux/libnvdimm.h | 8 +++
mm/Kconfig | 3 +
15 files changed, 243 insertions(+), 11 deletions(-)
--
2.26.2
^ permalink raw reply
* Re: ipr crashes due to NULL dma_need_drain since cc97923a5bcc ("block: move dma drain handling to scsi")
From: Michael Ellerman @ 2020-06-10 5:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-scsi, LKML, linux-block, linux-ide, brking,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <20200609154230.GA18426@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> Can you try this patch?
>
> ---
> From 1c9913360a0494375c5655b133899cb4323bceb4 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 9 Jun 2020 14:07:31 +0200
> Subject: scsi: wire up ata_scsi_dma_need_drain for SAS HBA drivers
>
> We need ata_scsi_dma_need_drain for all drivers wired up to drive ATAPI
> devices through libata. That also includes the SAS HBA drivers in
> addition to native libata HBA drivers.
>
> Fixes: cc97923a5bcc ("block: move dma drain handling to scsi")
> Reported-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Yep that works for me here with ipr.
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* Re: [PATCH v3 0/7] Base support for POWER10
From: Michael Ellerman @ 2020-06-10 5:30 UTC (permalink / raw)
To: Murilo Opsfelder Araújo
Cc: Alistair Popple, mikey, linuxppc-dev, npiggin, aneesh.kumar
In-Reply-To: <20200609165135.GA12260@kermit.br.ibm.com>
Murilo Opsfelder Araújo <mopsfelder@gmail.com> writes:
> On Tue, Jun 09, 2020 at 03:28:31PM +1000, Michael Ellerman wrote:
>> On Thu, 21 May 2020 11:43:34 +1000, Alistair Popple wrote:
>> > This series brings together several previously posted patches required for
>> > POWER10 support and introduces a new patch enabling POWER10 architected
>> > mode to enable booting as a POWER10 pseries guest.
>> >
>> > It includes support for enabling facilities related to MMA and prefix
>> > instructions.
>> >
>> > [...]
>>
>> Patches 1-3 and 5-7 applied to powerpc/next.
>>
>> [1/7] powerpc: Add new HWCAP bits
>> https://git.kernel.org/powerpc/c/ee988c11acf6f9464b7b44e9a091bf6afb3b3a49
>> [2/7] powerpc: Add support for ISA v3.1
>> https://git.kernel.org/powerpc/c/3fd5836ee801ab9ac5b314c26550e209bafa5eaa
>> [3/7] powerpc/dt_cpu_ftrs: Advertise support for ISA v3.1 if selected
>> https://git.kernel.org/powerpc/c/43d0d37acbe40a9a93d9891ca670638cd22116b1
>
> Just out of curiosity, why do we define ISA_V3_0B and ISA_V3_1 macros
> and don't use them anywhere else in the code?
Because we're sloppy :/
> Can't they be used in cpufeatures_setup_start() instead of 3000 and
> 3100 literals?
Yes please.
cheers
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/ppc-opcode: move ppc instruction encoding from test_emulate_step
From: Sandipan Das @ 2020-06-10 5:19 UTC (permalink / raw)
To: Balamuruhan S
Cc: christophe.leroy, ravi.bangoria, paulus, jniethe5, naveen.n.rao,
linuxppc-dev
In-Reply-To: <20200526081523.92463-3-bala24@linux.ibm.com>
On 26/05/20 1:45 pm, Balamuruhan S wrote:
> Few ppc instructions are encoded in test_emulate_step.c, consolidate
> them and use it from ppc-opcode.h
>
> Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
> Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 35 ++++++
> arch/powerpc/lib/test_emulate_step.c | 155 ++++++++++----------------
> 2 files changed, 91 insertions(+), 99 deletions(-)
> [...]
>
Acked-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/ppc-opcode: consolidate powerpc instructions from bpf_jit.h
From: Sandipan Das @ 2020-06-10 5:18 UTC (permalink / raw)
To: Balamuruhan S
Cc: christophe.leroy, ravi.bangoria, paulus, jniethe5, naveen.n.rao,
linuxppc-dev
In-Reply-To: <20200526081523.92463-5-bala24@linux.ibm.com>
On 26/05/20 1:45 pm, Balamuruhan S wrote:
> move macro definitions of powerpc instructions from bpf_jit.h to ppc-opcode.h
> and adopt the users of the macros accordingly. `PPC_MR()` is defined twice in
> bpf_jit.h, remove the duplicate one.
>
> Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
> Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 139 +++++++++++++
> arch/powerpc/net/bpf_jit.h | 166 ++-------------
> arch/powerpc/net/bpf_jit32.h | 24 +--
> arch/powerpc/net/bpf_jit64.h | 12 +-
> arch/powerpc/net/bpf_jit_comp.c | 132 ++++++------
> arch/powerpc/net/bpf_jit_comp64.c | 278 +++++++++++++-------------
> 6 files changed, 378 insertions(+), 373 deletions(-)
> [...]
>
Acked-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/bpf_jit: reuse instruction macros from ppc-opcode.h
From: Sandipan Das @ 2020-06-10 5:17 UTC (permalink / raw)
To: Balamuruhan S, mpe
Cc: christophe.leroy, ravi.bangoria, jniethe5, paulus, naveen.n.rao,
linuxppc-dev
In-Reply-To: <20200526081523.92463-4-bala24@linux.ibm.com>
On 26/05/20 1:45 pm, Balamuruhan S wrote:
> remove duplicate macro definitions from bpf_jit.h and reuse the macros from
> ppc-opcode.h
>
> Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
> Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/net/bpf_jit.h | 18 +-----------------
> arch/powerpc/net/bpf_jit32.h | 10 +++++-----
> arch/powerpc/net/bpf_jit64.h | 4 ++--
> arch/powerpc/net/bpf_jit_comp.c | 2 +-
> arch/powerpc/net/bpf_jit_comp64.c | 20 ++++++++++----------
> 5 files changed, 19 insertions(+), 35 deletions(-)
> [...]
>
Acked-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/svm: Fixup align argument in alloc_shared_lppaca() function
From: Thiago Jung Bauermann @ 2020-06-10 4:19 UTC (permalink / raw)
To: Satheesh Rajendran
Cc: Ram Pai, Laurent Dufour, Sukadev Bhattiprolu, linuxppc-dev,
linux-kernel
In-Reply-To: <20200609113909.17236-1-sathnaga@linux.vnet.ibm.com>
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> writes:
> Argument "align" in alloc_shared_lppaca() function was unused inside the
> function. Let's fix it and update code comment.
>
> Cc: linux-kernel@vger.kernel.org
> Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> Cc: Ram Pai <linuxram@us.ibm.com>
> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Cc: Laurent Dufour <ldufour@linux.ibm.com>
> Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/paca.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
Nice. I agree it's a good code cleanup.
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/svm: Remove unwanted check for shared_lppaca_size
From: Thiago Jung Bauermann @ 2020-06-10 4:15 UTC (permalink / raw)
To: Satheesh Rajendran
Cc: Ram Pai, Laurent Dufour, Sukadev Bhattiprolu, linuxppc-dev,
linux-kernel
In-Reply-To: <20200609105731.14032-1-sathnaga@linux.vnet.ibm.com>
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> writes:
> Early secure guest boot hits the below crash while booting with
> vcpus numbers aligned with page boundary for PAGE size of 64k
> and LPPACA size of 1k i.e 64, 128 etc, due to the BUG_ON assert
> for shared_lppaca_total_size equal to shared_lppaca_size,
>
> [ 0.000000] Partition configured for 64 cpus.
> [ 0.000000] CPU maps initialized for 1 thread per core
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] kernel BUG at arch/powerpc/kernel/paca.c:89!
> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 0.000000] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
>
> which is not necessary, let's remove it.
>
> Cc: linux-kernel@vger.kernel.org
> Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> Cc: Ram Pai <linuxram@us.ibm.com>
> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Cc: Laurent Dufour <ldufour@linux.ibm.com>
> Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/paca.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks for fixing this bug! I would only add:
Fixes: bd104e6db6f0 ("powerpc/pseries/svm: Use shared memory for LPPACA structures")
In any case:
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] ibmvscsi: don't send host info in adapter info MAD after LPM
From: Martin K. Petersen @ 2020-06-10 2:02 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, Martin K . Petersen
In-Reply-To: <20200603203632.18426-1-tyreld@linux.ibm.com>
On Wed, 3 Jun 2020 15:36:32 -0500, Tyrel Datwyler wrote:
> The adatper info MAD is used to send the client info and receive the
> host info as a response. A peristent buffer is used and as such the
> client info is overwritten after the response. During the course of
> a normal adapter reset the client info is refreshed in the buffer in
> preparation for sending the adapter info MAD.
>
> However, in the special case of LPM where we reenable the CRQ instead
> of a full CRQ teardown and reset we fail to refresh the client info in
> the adapter info buffer. As a result after Live Partition Migration
> (LPM) we erroneously report the hosts info as our own.
Applied to 5.8/scsi-queue, thanks!
[1/1] scsi: ibmvscsi: Don't send host info in adapter info MAD after LPM
https://git.kernel.org/mkp/scsi/c/4919b33b63c8
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* PowerPC KVM-PR issue
From: Christian Zigotzky @ 2020-06-09 22:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Christian Zigotzky
In-Reply-To: <87tuznq89p.fsf@linux.ibm.com>
Hello,
KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that the
Git kernels and the kernel 5.7 are affected.
Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 700
failed (00000000)
I can boot virtual QEMU PowerPC machines with KVM-PR with the kernel 5.6
without any problems on my Nemo board.
I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.
Could you please check KVM-PR on your PowerPC machine?
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
^ permalink raw reply
* Re: [PATCH v11 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
From: Dan Williams @ 2020-06-09 18:53 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, kbuild-all, kernel test robot, linux-nvdimm,
Aneesh Kumar K . V, Linux Kernel Mailing List, Steven Rostedt,
clang-built-linux, Oliver O'Halloran, linuxppc-dev
In-Reply-To: <87mu5cw2gl.fsf@linux.ibm.com>
On Tue, Jun 9, 2020 at 10:54 AM Vaibhav Jain <vaibhav@linux.ibm.com> wrote:
>
> Thanks Dan for the consideration and taking time to look into this.
>
> My responses below:
>
> Dan Williams <dan.j.williams@intel.com> writes:
>
> > On Mon, Jun 8, 2020 at 5:16 PM kernel test robot <lkp@intel.com> wrote:
> >>
> >> Hi Vaibhav,
> >>
> >> Thank you for the patch! Perhaps something to improve:
> >>
> >> [auto build test WARNING on powerpc/next]
> >> [also build test WARNING on linus/master v5.7 next-20200605]
> >> [cannot apply to linux-nvdimm/libnvdimm-for-next scottwood/next]
> >> [if your patch is applied to the wrong git tree, please drop us a note to help
> >> improve the system. BTW, we also suggest to use '--base' option to specify the
> >> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> >>
> >> url: https://github.com/0day-ci/linux/commits/Vaibhav-Jain/powerpc-papr_scm-Add-support-for-reporting-nvdimm-health/20200607-211653
> >> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
> >> config: powerpc-randconfig-r016-20200607 (attached as .config)
> >> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project e429cffd4f228f70c1d9df0e5d77c08590dd9766)
> >> reproduce (this is a W=1 build):
> >> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >> chmod +x ~/bin/make.cross
> >> # install powerpc cross compiling tool for clang build
> >> # apt-get install binutils-powerpc-linux-gnu
> >> # save the attached .config to linux build tree
> >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
> >>
> >> If you fix the issue, kindly add following tag as appropriate
> >> Reported-by: kernel test robot <lkp@intel.com>
> >>
> >> All warnings (new ones prefixed by >>, old ones prefixed by <<):
> >>
> >> In file included from <built-in>:1:
> >> >> ./usr/include/asm/papr_pdsm.h:69:20: warning: field 'hdr' with variable sized type 'struct nd_cmd_pkg' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
> >> struct nd_cmd_pkg hdr; /* Package header containing sub-cmd */
> >
> > Hi Vaibhav,
> >
> [.]
> > This looks like it's going to need another round to get this fixed. I
> > don't think 'struct nd_pdsm_cmd_pkg' should embed a definition of
> > 'struct nd_cmd_pkg'. An instance of 'struct nd_cmd_pkg' carries a
> > payload that is the 'pdsm' specifics. As the code has it now it's
> > defined as a superset of 'struct nd_cmd_pkg' and the compiler warning
> > is pointing out a real 'struct' organization problem.
> >
> > Given the soak time needed in -next after the code is finalized this
> > there's no time to do another round of updates and still make the v5.8
> > merge window.
>
> Agreed that this looks bad, a solution will probably need some more
> review cycles resulting in this series missing the merge window.
>
> I am investigating into the possible solutions for this reported issue
> and made few observations:
>
> I see command pkg for Intel, Hpe, Msft and Hyperv families using a
> similar layout of embedding nd_cmd_pkg at the head of the
> command-pkg. struct nd_pdsm_cmd_pkg is following the same pattern.
>
> struct nd_pdsm_cmd_pkg {
> struct nd_cmd_pkg hdr;
> /* other members */
> };
>
> struct ndn_pkg_msft {
> struct nd_cmd_pkg gen;
> /* other members */
> };
> struct nd_pkg_intel {
> struct nd_cmd_pkg gen;
> /* other members */
> };
> struct ndn_pkg_hpe1 {
> struct nd_cmd_pkg gen;
> /* other members */
In those cases the other members are a union and there is no second
variable length array. Perhaps that is why those definitions are not
getting flagged? I'm not seeing anything in ndctl build options that
would explicitly disable this warning, but I'm not sure if the ndctl
build environment is missing this build warning by accident.
Those variable size payloads are also not being used in any code paths
that would look at the size of the command payload, like the kernel
ioctl() path. The payload validation code needs static sizes and the
payload parsing code wants to cast the payload to a known type. I
don't think you can use the same struct definition for both those
cases which is why the ndctl parsing code uses the union layout, but
the kernel command marshaling code does strict layering.
> };
>
> Even though other command families implement similar command-package
> layout they were not flagged (yet) as they are (I am guessing) serviced
> in vendor acpi drivers rather than in kernel like in case of papr-scm
> command family.
I sincerely hope there are no vendor acpi kernel drivers outside of
the upstream one.
>
> So, I think this issue is not just specific to papr-scm command family
> introduced in this patch series but rather across all other command
> families. Every other command family assumes 'struct nd_cmd_pkg_hdr' to
> be embeddable and puts it at the beginning of their corresponding
> command-packages. And its only a matter of time when someone tries
> filtering/handling of vendor specific commands in nfit module when they
> hit similar issue.
>
> Possible Solutions:
>
> * One way would be to redefine 'struct nd_cmd_pkg' to mark field
> 'nd_payload[]' from a flexible array to zero sized array as
> 'nd_payload[0]'.
I just went through a round of removing the usage of buf[0] in ndctl
since gcc10 now warns about that too.
> This should make 'struct nd_cmd_pkg' embeddable and
> clang shouldn't report 'gnu-variable-sized-type-not-at-end'
> warning. Also I think this change shouldn't introduce any ABI change.
>
> * Another way to solve this issue might be to redefine 'struct
> nd_pdsm_cmd_pkg' to below removing the 'struct nd_cmd_pkg' member. This
> struct should immediately follow the 'struct nd_cmd_pkg' command package
> when sent to libnvdimm:
>
> struct nd_pdsm_cmd_pkg {
> __s32 cmd_status; /* Out: Sub-cmd status returned back */
> __u16 reserved[2]; /* Ignored and to be used in future */
> __u8 payload[];
> };
>
> This should remove the flexible member nc_cmd_pkg.nd_payload from the
> struct with just one remaining at the end. However this would make
> accessing the [in|out|fw]_size members of 'struct nd_cmd_pkg'
> difficult for the pdsm servicing functions.
>
>
> Any other solution that you think, may solve this issue ?
The union might help, but per the above I think only for parsing the
command at which point I don't think the kernel needs a unified
structure defining both the generic envelope and the end-point
specific payload at once.
^ permalink raw reply
* Re: [PATCH v11 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
From: Vaibhav Jain @ 2020-06-09 17:53 UTC (permalink / raw)
To: Dan Williams, kernel test robot
Cc: Santosh Sivaraj, kbuild-all, linux-nvdimm, Aneesh Kumar K . V,
Linux Kernel Mailing List, Steven Rostedt, clang-built-linux,
Oliver O'Halloran, linuxppc-dev
In-Reply-To: <CAPcyv4iQo_xgRGPx_j+RPzgWGZaigGRbc_kRzKEFePfVHenx5g@mail.gmail.com>
Thanks Dan for the consideration and taking time to look into this.
My responses below:
Dan Williams <dan.j.williams@intel.com> writes:
> On Mon, Jun 8, 2020 at 5:16 PM kernel test robot <lkp@intel.com> wrote:
>>
>> Hi Vaibhav,
>>
>> Thank you for the patch! Perhaps something to improve:
>>
>> [auto build test WARNING on powerpc/next]
>> [also build test WARNING on linus/master v5.7 next-20200605]
>> [cannot apply to linux-nvdimm/libnvdimm-for-next scottwood/next]
>> [if your patch is applied to the wrong git tree, please drop us a note to help
>> improve the system. BTW, we also suggest to use '--base' option to specify the
>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>>
>> url: https://github.com/0day-ci/linux/commits/Vaibhav-Jain/powerpc-papr_scm-Add-support-for-reporting-nvdimm-health/20200607-211653
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
>> config: powerpc-randconfig-r016-20200607 (attached as .config)
>> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project e429cffd4f228f70c1d9df0e5d77c08590dd9766)
>> reproduce (this is a W=1 build):
>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # install powerpc cross compiling tool for clang build
>> # apt-get install binutils-powerpc-linux-gnu
>> # save the attached .config to linux build tree
>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp@intel.com>
>>
>> All warnings (new ones prefixed by >>, old ones prefixed by <<):
>>
>> In file included from <built-in>:1:
>> >> ./usr/include/asm/papr_pdsm.h:69:20: warning: field 'hdr' with variable sized type 'struct nd_cmd_pkg' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
>> struct nd_cmd_pkg hdr; /* Package header containing sub-cmd */
>
> Hi Vaibhav,
>
[.]
> This looks like it's going to need another round to get this fixed. I
> don't think 'struct nd_pdsm_cmd_pkg' should embed a definition of
> 'struct nd_cmd_pkg'. An instance of 'struct nd_cmd_pkg' carries a
> payload that is the 'pdsm' specifics. As the code has it now it's
> defined as a superset of 'struct nd_cmd_pkg' and the compiler warning
> is pointing out a real 'struct' organization problem.
>
> Given the soak time needed in -next after the code is finalized this
> there's no time to do another round of updates and still make the v5.8
> merge window.
Agreed that this looks bad, a solution will probably need some more
review cycles resulting in this series missing the merge window.
I am investigating into the possible solutions for this reported issue
and made few observations:
I see command pkg for Intel, Hpe, Msft and Hyperv families using a
similar layout of embedding nd_cmd_pkg at the head of the
command-pkg. struct nd_pdsm_cmd_pkg is following the same pattern.
struct nd_pdsm_cmd_pkg {
struct nd_cmd_pkg hdr;
/* other members */
};
struct ndn_pkg_msft {
struct nd_cmd_pkg gen;
/* other members */
};
struct nd_pkg_intel {
struct nd_cmd_pkg gen;
/* other members */
};
struct ndn_pkg_hpe1 {
struct nd_cmd_pkg gen;
/* other members */
};
Even though other command families implement similar command-package
layout they were not flagged (yet) as they are (I am guessing) serviced
in vendor acpi drivers rather than in kernel like in case of papr-scm
command family.
So, I think this issue is not just specific to papr-scm command family
introduced in this patch series but rather across all other command
families. Every other command family assumes 'struct nd_cmd_pkg_hdr' to
be embeddable and puts it at the beginning of their corresponding
command-packages. And its only a matter of time when someone tries
filtering/handling of vendor specific commands in nfit module when they
hit similar issue.
Possible Solutions:
* One way would be to redefine 'struct nd_cmd_pkg' to mark field
'nd_payload[]' from a flexible array to zero sized array as
'nd_payload[0]'. This should make 'struct nd_cmd_pkg' embeddable and
clang shouldn't report 'gnu-variable-sized-type-not-at-end'
warning. Also I think this change shouldn't introduce any ABI change.
* Another way to solve this issue might be to redefine 'struct
nd_pdsm_cmd_pkg' to below removing the 'struct nd_cmd_pkg' member. This
struct should immediately follow the 'struct nd_cmd_pkg' command package
when sent to libnvdimm:
struct nd_pdsm_cmd_pkg {
__s32 cmd_status; /* Out: Sub-cmd status returned back */
__u16 reserved[2]; /* Ignored and to be used in future */
__u8 payload[];
};
This should remove the flexible member nc_cmd_pkg.nd_payload from the
struct with just one remaining at the end. However this would make
accessing the [in|out|fw]_size members of 'struct nd_cmd_pkg'
difficult for the pdsm servicing functions.
Any other solution that you think, may solve this issue ?
Thanks,
--
~ Vaibhav
^ permalink raw reply
* Re: [PATCH v3 0/7] Base support for POWER10
From: Murilo Opsfelder Araújo @ 2020-06-09 16:51 UTC (permalink / raw)
To: Michael Ellerman
Cc: Alistair Popple, mikey, linuxppc-dev, npiggin, aneesh.kumar
In-Reply-To: <159168035553.1381411.323672966899358346.b4-ty@ellerman.id.au>
On Tue, Jun 09, 2020 at 03:28:31PM +1000, Michael Ellerman wrote:
> On Thu, 21 May 2020 11:43:34 +1000, Alistair Popple wrote:
> > This series brings together several previously posted patches required for
> > POWER10 support and introduces a new patch enabling POWER10 architected
> > mode to enable booting as a POWER10 pseries guest.
> >
> > It includes support for enabling facilities related to MMA and prefix
> > instructions.
> >
> > [...]
>
> Patches 1-3 and 5-7 applied to powerpc/next.
>
> [1/7] powerpc: Add new HWCAP bits
> https://git.kernel.org/powerpc/c/ee988c11acf6f9464b7b44e9a091bf6afb3b3a49
> [2/7] powerpc: Add support for ISA v3.1
> https://git.kernel.org/powerpc/c/3fd5836ee801ab9ac5b314c26550e209bafa5eaa
> [3/7] powerpc/dt_cpu_ftrs: Advertise support for ISA v3.1 if selected
> https://git.kernel.org/powerpc/c/43d0d37acbe40a9a93d9891ca670638cd22116b1
Just out of curiosity, why do we define ISA_V3_0B and ISA_V3_1 macros
and don't use them anywhere else in the code?
Can't they be used in cpufeatures_setup_start() instead of 3000 and
3100 literals?
> [5/7] powerpc/dt_cpu_ftrs: Enable Prefixed Instructions
> https://git.kernel.org/powerpc/c/c63d688c3dabca973c5a7da73d17422ad13f3737
> [6/7] powerpc/dt_cpu_ftrs: Add MMA feature
> https://git.kernel.org/powerpc/c/87939d50e5888bd78478d9aa9455f56b919df658
> [7/7] powerpc: Add POWER10 architected mode
> https://git.kernel.org/powerpc/c/a3ea40d5c7365e7e5c7c85b6f30b15142b397571
>
> cheers
--
Murilo
^ permalink raw reply
* Re: [PATCH v12 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
From: kernel test robot @ 2020-06-09 16:33 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, linux-nvdimm, linux-kernel
Cc: Santosh Sivaraj, kbuild-all, Steven Rostedt, clang-built-linux,
Oliver O'Halloran, Aneesh Kumar K . V, Vaibhav Jain,
Dan Williams
In-Reply-To: <20200608211026.67573-6-vaibhav@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
Hi Vaibhav,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on linus/master v5.7 next-20200608]
[cannot apply to linux-nvdimm/libnvdimm-for-next scottwood/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Vaibhav-Jain/powerpc-papr_scm-Add-support-for-reporting-nvdimm-health/20200609-051451
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r031-20200608 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project bc2b70982be8f5250cd0082a7190f8b417bd4dfe)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from <built-in>:1:
>> ./usr/include/asm/papr_pdsm.h:67:20: warning: field 'hdr' with variable sized type 'struct nd_cmd_pkg' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
struct nd_cmd_pkg hdr; /* Package header containing sub-cmd */
^
1 warning generated.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30965 bytes --]
^ permalink raw reply
* Re: [musl] ppc64le and 32-bit LE userland compatibility
From: Rich Felker @ 2020-06-09 16:06 UTC (permalink / raw)
To: Will Springer; +Cc: linuxppc-dev
In-Reply-To: <20948555.hxa6pUQ8Du@sheen>
On Tue, Jun 09, 2020 at 10:29:57AM +0000, Will Springer wrote:
> On Saturday, May 30, 2020 3:56:47 PM PDT you wrote:
> > On Friday, May 29, 2020 12:24:27 PM PDT Rich Felker wrote:
> > > The argument passing for pread/pwrite is historically a mess and
> > > differs between archs. musl has a dedicated macro that archs can
> > > define to override it. But it looks like it should match regardless of
> > > BE vs LE, and musl already defines it for powerpc with the default
> > > definition, adding a zero arg to start on an even arg-slot index,
> > > which is an odd register (since ppc32 args start with an odd one, r3).
> > >
> > > > [6]:
> > > > https://gist.github.com/Skirmisher/02891c1a8cafa0ff18b2460933ef4f3c
> > >
> > > I don't think this is correct, but I'm confused about where it's
> > > getting messed up because it looks like it should already be right.
> >
> > Hmm, interesting. Will have to go back to it I guess...
> >
> > > > This was enough to fix up the `file` bug. I'm no seasoned kernel
> > > > hacker, though, and there is still concern over the right way to
> > > > approach this, whether it should live in the kernel or libc, etc.
> > > > Frankly, I don't know the ABI structure enough to understand why the
> > > > register padding has to be different in this case, or what
> > > > lower-level component is responsible for it.. For comparison, I had
> > > > a
> > > > look at the mips tree, since it's bi-endian and has a similar 32/64
> > > > situation. There is a macro conditional upon endianness that is
> > > > responsible for munging long longs; it uses __MIPSEB__ and
> > > > __MIPSEL__
> > > > instead of an if/else on the generic __LITTLE_ENDIAN__. Not sure
> > > > what
> > > > to make of that. (It also simply swaps registers for LE, unlike what
> > > > I did for ppc.)
> > >
> > > Indeed the problem is probably that you need to swap registers for LE,
> > > not remove the padding slot. Did you check what happens if you pass a
> > > value larger than 32 bits?
> > >
> > > If so, the right way to fix this on the kernel side would be to
> > > construct the value as a union rather than by bitwise ops so it's
> > >
> > > endian-agnostic:
> > > (union { u32 parts[2]; u64 val; }){{ arg1, arg2 }}.val
> > >
> > > But the kernel folks might prefer endian ifdefs for some odd reason...
> >
> > You are right, this does seem odd considering what the other archs do.
> > It's quite possible I made a silly mistake, of course...
> >
> > I haven't tested with values outside the 32-bit range yet; again, this
> > is new territory for me, so I haven't exactly done exhaustive tests on
> > everything. I'll give it a closer look.
>
> I took some cues from the mips linux32 syscall setup, and drafted a new
> patch defining a macro to compose the hi/lo parts within the function,
> instead of swapping the args at the function definition. `file /bin/bash`
> and `truncate -s 5G test` both work correctly now. This appears to be the
> correct solution, so I'm not sure what silly mistake I made before, but
> apologies for the confusion. I've updated my gist with the new patch [1].
> [...]
>
> [1]: https://gist.github.com/Skirmisher/02891c1a8cafa0ff18b2460933ef4f3c
This patch looks correct. I prefer the union approach with no #ifdef
but I'm fine with either.
Rich
^ permalink raw reply
* Re: [PATCH] mm: Move p?d_alloc_track to separate header file
From: Stephen Rothwell @ 2020-06-09 15:53 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, manvanth, jroedel, Abdul Haleem, peterz, linuxppc-dev,
Joerg Roedel, linux-kernel, Steven Rostedt, Mike Rapoport,
linux-mm, linux-next, Satheesh Rajendran, Andy Lutomirski,
Andrew Morton, Linus Torvalds, hch
In-Reply-To: <2aecbc65-db1a-dccd-046d-b7c97b714ee0@csgroup.eu>
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hi Christophe,
On Tue, 9 Jun 2020 17:24:14 +0200 Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
> Le 09/06/2020 à 14:05, Joerg Roedel a écrit :
> > From: Joerg Roedel <jroedel@suse.de>
> >
> > The functions are only used in two source files, so there is no need
> > for them to be in the global <linux/mm.h> header. Move them to the new
> > <linux/pgalloc-track.h> header and include it only where needed.
>
> Do you mean we will now create a new header file for any new couple on
> functions based on where they are used ?
>
> Can you explain why this change is needed or is a plus ?
Well at a minimum, it means 45 lines less to be parsed every time the
linux/mm is included (in at last count, 1996 places some of which are
include files included by other files). And, as someone who does a lot
of builds every day, I am in favour of that :-)
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: ipr crashes due to NULL dma_need_drain since cc97923a5bcc ("block: move dma drain handling to scsi")
From: Christoph Hellwig @ 2020-06-09 15:42 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jens Axboe, linux-scsi, LKML, linux-block, linux-ide, brking,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <87zh9cftj0.fsf@mpe.ellerman.id.au>
Can you try this patch?
---
From 1c9913360a0494375c5655b133899cb4323bceb4 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 9 Jun 2020 14:07:31 +0200
Subject: scsi: wire up ata_scsi_dma_need_drain for SAS HBA drivers
We need ata_scsi_dma_need_drain for all drivers wired up to drive ATAPI
devices through libata. That also includes the SAS HBA drivers in
addition to native libata HBA drivers.
Fixes: cc97923a5bcc ("block: move dma drain handling to scsi")
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/scsi/aic94xx/aic94xx_init.c | 1 +
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 1 +
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 1 +
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 1 +
drivers/scsi/ipr.c | 1 +
drivers/scsi/isci/init.c | 1 +
drivers/scsi/mvsas/mv_init.c | 1 +
drivers/scsi/pm8001/pm8001_init.c | 1 +
8 files changed, 8 insertions(+)
diff --git a/drivers/scsi/aic94xx/aic94xx_init.c b/drivers/scsi/aic94xx/aic94xx_init.c
index d022407e5645c7..bef47f38dd0dbc 100644
--- a/drivers/scsi/aic94xx/aic94xx_init.c
+++ b/drivers/scsi/aic94xx/aic94xx_init.c
@@ -40,6 +40,7 @@ static struct scsi_host_template aic94xx_sht = {
/* .name is initialized */
.name = "aic94xx",
.queuecommand = sas_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.target_alloc = sas_target_alloc,
.slave_configure = sas_slave_configure,
.scan_finished = asd_scan_finished,
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 2e1718f9ade218..09a7669dad4c67 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1756,6 +1756,7 @@ static struct scsi_host_template sht_v1_hw = {
.proc_name = DRV_NAME,
.module = THIS_MODULE,
.queuecommand = sas_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.target_alloc = sas_target_alloc,
.slave_configure = hisi_sas_slave_configure,
.scan_finished = hisi_sas_scan_finished,
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index e7e7849a4c14e2..968d3870235359 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -3532,6 +3532,7 @@ static struct scsi_host_template sht_v2_hw = {
.proc_name = DRV_NAME,
.module = THIS_MODULE,
.queuecommand = sas_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.target_alloc = sas_target_alloc,
.slave_configure = hisi_sas_slave_configure,
.scan_finished = hisi_sas_scan_finished,
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 3e6b78a1f993b9..55e2321a65bc5f 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -3075,6 +3075,7 @@ static struct scsi_host_template sht_v3_hw = {
.proc_name = DRV_NAME,
.module = THIS_MODULE,
.queuecommand = sas_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.target_alloc = sas_target_alloc,
.slave_configure = hisi_sas_slave_configure,
.scan_finished = hisi_sas_scan_finished,
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 7d77997d26d457..7d86f4ca266c86 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -6731,6 +6731,7 @@ static struct scsi_host_template driver_template = {
.compat_ioctl = ipr_ioctl,
#endif
.queuecommand = ipr_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.eh_abort_handler = ipr_eh_abort,
.eh_device_reset_handler = ipr_eh_dev_reset,
.eh_host_reset_handler = ipr_eh_host_reset,
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
index 974c3b9116d5ba..085e285f427d93 100644
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -153,6 +153,7 @@ static struct scsi_host_template isci_sht = {
.name = DRV_NAME,
.proc_name = DRV_NAME,
.queuecommand = sas_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.target_alloc = sas_target_alloc,
.slave_configure = sas_slave_configure,
.scan_finished = isci_host_scan_finished,
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 5973eed9493820..b0de3bdb01db06 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -33,6 +33,7 @@ static struct scsi_host_template mvs_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
.queuecommand = sas_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.target_alloc = sas_target_alloc,
.slave_configure = sas_slave_configure,
.scan_finished = mvs_scan_finished,
diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c
index a8f5344fdfda2a..9e99262a2b9dd3 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -87,6 +87,7 @@ static struct scsi_host_template pm8001_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
.queuecommand = sas_queuecommand,
+ .dma_need_drain = ata_scsi_dma_need_drain,
.target_alloc = sas_target_alloc,
.slave_configure = sas_slave_configure,
.scan_finished = pm8001_scan_finished,
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] mm: Move p?d_alloc_track to separate header file
From: Christophe Leroy @ 2020-06-09 15:24 UTC (permalink / raw)
To: Joerg Roedel, Andrew Morton
Cc: linux-arch, Stephen Rothwell, jroedel, Abdul Haleem, peterz,
linuxppc-dev, linux-kernel, Steven Rostedt, Mike Rapoport,
linux-mm, linux-next, Satheesh Rajendran, manvanth,
Andy Lutomirski, Linus Torvalds, hch
In-Reply-To: <20200609120533.25867-1-joro@8bytes.org>
Le 09/06/2020 à 14:05, Joerg Roedel a écrit :
> From: Joerg Roedel <jroedel@suse.de>
>
> The functions are only used in two source files, so there is no need
> for them to be in the global <linux/mm.h> header. Move them to the new
> <linux/pgalloc-track.h> header and include it only where needed.
Do you mean we will now create a new header file for any new couple on
functions based on where they are used ?
Can you explain why this change is needed or is a plus ?
Christophe
>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
> include/linux/mm.h | 45 -------------------------------
> include/linux/pgalloc-track.h | 51 +++++++++++++++++++++++++++++++++++
> lib/ioremap.c | 1 +
> mm/vmalloc.c | 1 +
> 4 files changed, 53 insertions(+), 45 deletions(-)
> create mode 100644 include/linux/pgalloc-track.h
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 9d6042178ca7..22d8b2a2c9bc 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2092,51 +2092,11 @@ static inline pud_t *pud_alloc(struct mm_struct *mm, p4d_t *p4d,
> NULL : pud_offset(p4d, address);
> }
>
> -static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
> - unsigned long address,
> - pgtbl_mod_mask *mod_mask)
> -
> -{
> - if (unlikely(pgd_none(*pgd))) {
> - if (__p4d_alloc(mm, pgd, address))
> - return NULL;
> - *mod_mask |= PGTBL_PGD_MODIFIED;
> - }
> -
> - return p4d_offset(pgd, address);
> -}
> -
> -static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
> - unsigned long address,
> - pgtbl_mod_mask *mod_mask)
> -{
> - if (unlikely(p4d_none(*p4d))) {
> - if (__pud_alloc(mm, p4d, address))
> - return NULL;
> - *mod_mask |= PGTBL_P4D_MODIFIED;
> - }
> -
> - return pud_offset(p4d, address);
> -}
> -
> static inline pmd_t *pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address)
> {
> return (unlikely(pud_none(*pud)) && __pmd_alloc(mm, pud, address))?
> NULL: pmd_offset(pud, address);
> }
> -
> -static inline pmd_t *pmd_alloc_track(struct mm_struct *mm, pud_t *pud,
> - unsigned long address,
> - pgtbl_mod_mask *mod_mask)
> -{
> - if (unlikely(pud_none(*pud))) {
> - if (__pmd_alloc(mm, pud, address))
> - return NULL;
> - *mod_mask |= PGTBL_PUD_MODIFIED;
> - }
> -
> - return pmd_offset(pud, address);
> -}
> #endif /* CONFIG_MMU */
>
> #if USE_SPLIT_PTE_PTLOCKS
> @@ -2252,11 +2212,6 @@ static inline void pgtable_pte_page_dtor(struct page *page)
> ((unlikely(pmd_none(*(pmd))) && __pte_alloc_kernel(pmd))? \
> NULL: pte_offset_kernel(pmd, address))
>
> -#define pte_alloc_kernel_track(pmd, address, mask) \
> - ((unlikely(pmd_none(*(pmd))) && \
> - (__pte_alloc_kernel(pmd) || ({*(mask)|=PGTBL_PMD_MODIFIED;0;})))?\
> - NULL: pte_offset_kernel(pmd, address))
> -
> #if USE_SPLIT_PMD_PTLOCKS
>
> static struct page *pmd_to_page(pmd_t *pmd)
> diff --git a/include/linux/pgalloc-track.h b/include/linux/pgalloc-track.h
> new file mode 100644
> index 000000000000..1dcc865029a2
> --- /dev/null
> +++ b/include/linux/pgalloc-track.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_PGALLLC_TRACK_H
> +#define _LINUX_PGALLLC_TRACK_H
> +
> +#if defined(CONFIG_MMU)
> +static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
> + unsigned long address,
> + pgtbl_mod_mask *mod_mask)
> +{
> + if (unlikely(pgd_none(*pgd))) {
> + if (__p4d_alloc(mm, pgd, address))
> + return NULL;
> + *mod_mask |= PGTBL_PGD_MODIFIED;
> + }
> +
> + return p4d_offset(pgd, address);
> +}
> +
> +static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
> + unsigned long address,
> + pgtbl_mod_mask *mod_mask)
> +{
> + if (unlikely(p4d_none(*p4d))) {
> + if (__pud_alloc(mm, p4d, address))
> + return NULL;
> + *mod_mask |= PGTBL_P4D_MODIFIED;
> + }
> +
> + return pud_offset(p4d, address);
> +}
> +
> +static inline pmd_t *pmd_alloc_track(struct mm_struct *mm, pud_t *pud,
> + unsigned long address,
> + pgtbl_mod_mask *mod_mask)
> +{
> + if (unlikely(pud_none(*pud))) {
> + if (__pmd_alloc(mm, pud, address))
> + return NULL;
> + *mod_mask |= PGTBL_PUD_MODIFIED;
> + }
> +
> + return pmd_offset(pud, address);
> +}
> +#endif /* CONFIG_MMU */
> +
> +#define pte_alloc_kernel_track(pmd, address, mask) \
> + ((unlikely(pmd_none(*(pmd))) && \
> + (__pte_alloc_kernel(pmd) || ({*(mask)|=PGTBL_PMD_MODIFIED;0;})))?\
> + NULL: pte_offset_kernel(pmd, address))
> +
> +#endif /* _LINUX_PGALLLC_TRACK_H */
> diff --git a/lib/ioremap.c b/lib/ioremap.c
> index ad485f08173b..608fcccd21c8 100644
> --- a/lib/ioremap.c
> +++ b/lib/ioremap.c
> @@ -11,6 +11,7 @@
> #include <linux/sched.h>
> #include <linux/io.h>
> #include <linux/export.h>
> +#include <linux/pgalloc-track.h>
> #include <asm/cacheflush.h>
> #include <asm/pgtable.h>
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3091c2ca60df..edc43f003165 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -35,6 +35,7 @@
> #include <linux/bitops.h>
> #include <linux/rbtree_augmented.h>
> #include <linux/overflow.h>
> +#include <linux/pgalloc-track.h>
>
> #include <linux/uaccess.h>
> #include <asm/tlbflush.h>
>
^ permalink raw reply
* Re: [PATCH] mm: Move p?d_alloc_track to separate header file
From: Mike Rapoport @ 2020-06-09 15:07 UTC (permalink / raw)
To: Joerg Roedel
Cc: linux-arch, Stephen Rothwell, jroedel, linux-mm, peterz,
Linus Torvalds, linuxppc-dev, Steven Rostedt, linux-kernel,
Abdul Haleem, linux-next, Satheesh Rajendran, Andy Lutomirski,
Andrew Morton, manvanth, hch
In-Reply-To: <20200609120533.25867-1-joro@8bytes.org>
On Tue, Jun 09, 2020 at 02:05:33PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> The functions are only used in two source files, so there is no need
> for them to be in the global <linux/mm.h> header. Move them to the new
> <linux/pgalloc-track.h> header and include it only where needed.
>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> include/linux/mm.h | 45 -------------------------------
> include/linux/pgalloc-track.h | 51 +++++++++++++++++++++++++++++++++++
> lib/ioremap.c | 1 +
> mm/vmalloc.c | 1 +
> 4 files changed, 53 insertions(+), 45 deletions(-)
> create mode 100644 include/linux/pgalloc-track.h
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 9d6042178ca7..22d8b2a2c9bc 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2092,51 +2092,11 @@ static inline pud_t *pud_alloc(struct mm_struct *mm, p4d_t *p4d,
> NULL : pud_offset(p4d, address);
> }
>
> -static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
> - unsigned long address,
> - pgtbl_mod_mask *mod_mask)
> -
> -{
> - if (unlikely(pgd_none(*pgd))) {
> - if (__p4d_alloc(mm, pgd, address))
> - return NULL;
> - *mod_mask |= PGTBL_PGD_MODIFIED;
> - }
> -
> - return p4d_offset(pgd, address);
> -}
> -
> -static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
> - unsigned long address,
> - pgtbl_mod_mask *mod_mask)
> -{
> - if (unlikely(p4d_none(*p4d))) {
> - if (__pud_alloc(mm, p4d, address))
> - return NULL;
> - *mod_mask |= PGTBL_P4D_MODIFIED;
> - }
> -
> - return pud_offset(p4d, address);
> -}
> -
> static inline pmd_t *pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address)
> {
> return (unlikely(pud_none(*pud)) && __pmd_alloc(mm, pud, address))?
> NULL: pmd_offset(pud, address);
> }
> -
> -static inline pmd_t *pmd_alloc_track(struct mm_struct *mm, pud_t *pud,
> - unsigned long address,
> - pgtbl_mod_mask *mod_mask)
> -{
> - if (unlikely(pud_none(*pud))) {
> - if (__pmd_alloc(mm, pud, address))
> - return NULL;
> - *mod_mask |= PGTBL_PUD_MODIFIED;
> - }
> -
> - return pmd_offset(pud, address);
> -}
> #endif /* CONFIG_MMU */
>
> #if USE_SPLIT_PTE_PTLOCKS
> @@ -2252,11 +2212,6 @@ static inline void pgtable_pte_page_dtor(struct page *page)
> ((unlikely(pmd_none(*(pmd))) && __pte_alloc_kernel(pmd))? \
> NULL: pte_offset_kernel(pmd, address))
>
> -#define pte_alloc_kernel_track(pmd, address, mask) \
> - ((unlikely(pmd_none(*(pmd))) && \
> - (__pte_alloc_kernel(pmd) || ({*(mask)|=PGTBL_PMD_MODIFIED;0;})))?\
> - NULL: pte_offset_kernel(pmd, address))
> -
> #if USE_SPLIT_PMD_PTLOCKS
>
> static struct page *pmd_to_page(pmd_t *pmd)
> diff --git a/include/linux/pgalloc-track.h b/include/linux/pgalloc-track.h
> new file mode 100644
> index 000000000000..1dcc865029a2
> --- /dev/null
> +++ b/include/linux/pgalloc-track.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_PGALLLC_TRACK_H
> +#define _LINUX_PGALLLC_TRACK_H
> +
> +#if defined(CONFIG_MMU)
> +static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
> + unsigned long address,
> + pgtbl_mod_mask *mod_mask)
> +{
> + if (unlikely(pgd_none(*pgd))) {
> + if (__p4d_alloc(mm, pgd, address))
> + return NULL;
> + *mod_mask |= PGTBL_PGD_MODIFIED;
> + }
> +
> + return p4d_offset(pgd, address);
> +}
> +
> +static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
> + unsigned long address,
> + pgtbl_mod_mask *mod_mask)
> +{
> + if (unlikely(p4d_none(*p4d))) {
> + if (__pud_alloc(mm, p4d, address))
> + return NULL;
> + *mod_mask |= PGTBL_P4D_MODIFIED;
> + }
> +
> + return pud_offset(p4d, address);
> +}
> +
> +static inline pmd_t *pmd_alloc_track(struct mm_struct *mm, pud_t *pud,
> + unsigned long address,
> + pgtbl_mod_mask *mod_mask)
> +{
> + if (unlikely(pud_none(*pud))) {
> + if (__pmd_alloc(mm, pud, address))
> + return NULL;
> + *mod_mask |= PGTBL_PUD_MODIFIED;
> + }
> +
> + return pmd_offset(pud, address);
> +}
> +#endif /* CONFIG_MMU */
> +
> +#define pte_alloc_kernel_track(pmd, address, mask) \
> + ((unlikely(pmd_none(*(pmd))) && \
> + (__pte_alloc_kernel(pmd) || ({*(mask)|=PGTBL_PMD_MODIFIED;0;})))?\
> + NULL: pte_offset_kernel(pmd, address))
> +
> +#endif /* _LINUX_PGALLLC_TRACK_H */
> diff --git a/lib/ioremap.c b/lib/ioremap.c
> index ad485f08173b..608fcccd21c8 100644
> --- a/lib/ioremap.c
> +++ b/lib/ioremap.c
> @@ -11,6 +11,7 @@
> #include <linux/sched.h>
> #include <linux/io.h>
> #include <linux/export.h>
> +#include <linux/pgalloc-track.h>
> #include <asm/cacheflush.h>
> #include <asm/pgtable.h>
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3091c2ca60df..edc43f003165 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -35,6 +35,7 @@
> #include <linux/bitops.h>
> #include <linux/rbtree_augmented.h>
> #include <linux/overflow.h>
> +#include <linux/pgalloc-track.h>
>
> #include <linux/uaccess.h>
> #include <asm/tlbflush.h>
> --
> 2.26.2
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH 00/17] spelling.txt: /decriptors/descriptors/
From: Kieran Bingham @ 2020-06-09 12:45 UTC (permalink / raw)
To: Kieran Bingham
Cc: linux-scsi, linux-pm, linux-rdma, netdev, linux-usb,
linux-wireless, linux-kernel, dri-devel, virtualization,
linux-renesas-soc, linux-gpio, Kieran Bingham, linux-mtd, ath10k,
linux-input, linuxppc-dev, linux-mm, linux-arm-kernel
I wouldn't normally go through spelling fixes, but I caught sight of
this typo twice, and then foolishly grepped the tree for it, and saw how
pervasive it was.
so here I am ... fixing a typo globally... but with an addition in
scripts/spelling.txt so it shouldn't re-appear ;-)
Cc: linux-arm-kernel@lists.infradead.org (moderated list:TI DAVINCI MACHINE SUPPORT)
Cc: linux-kernel@vger.kernel.org (open list)
Cc: linux-pm@vger.kernel.org (open list:DEVICE FREQUENCY EVENT (DEVFREQ-EVENT))
Cc: linux-gpio@vger.kernel.org (open list:GPIO SUBSYSTEM)
Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
Cc: linux-rdma@vger.kernel.org (open list:HFI1 DRIVER)
Cc: linux-input@vger.kernel.org (open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...)
Cc: linux-mtd@lists.infradead.org (open list:NAND FLASH SUBSYSTEM)
Cc: netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
Cc: ath10k@lists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
Cc: linux-wireless@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS))
Cc: linux-scsi@vger.kernel.org (open list:IBM Power Virtual FC Device Drivers)
Cc: linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC (32-BIT AND 64-BIT))
Cc: linux-usb@vger.kernel.org (open list:USB SUBSYSTEM)
Cc: virtualization@lists.linux-foundation.org (open list:VIRTIO CORE AND NET DRIVERS)
Cc: linux-mm@kvack.org (open list:MEMORY MANAGEMENT)
Kieran Bingham (17):
arch: arm: mach-davinci: Fix trivial spelling
drivers: infiniband: Fix trivial spelling
drivers: gpio: Fix trivial spelling
drivers: mtd: nand: raw: Fix trivial spelling
drivers: net: Fix trivial spelling
drivers: scsi: Fix trivial spelling
drivers: usb: Fix trivial spelling
drivers: gpu: drm: Fix trivial spelling
drivers: regulator: Fix trivial spelling
drivers: input: joystick: Fix trivial spelling
drivers: infiniband: Fix trivial spelling
drivers: devfreq: Fix trivial spelling
include: dynamic_debug.h: Fix trivial spelling
kernel: trace: Fix trivial spelling
mm: Fix trivial spelling
regulator: gpio: Fix trivial spelling
scripts/spelling.txt: Add descriptors correction
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
drivers/devfreq/devfreq-event.c | 4 ++--
drivers/gpio/TODO | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 2 +-
drivers/infiniband/hw/hfi1/iowait.h | 2 +-
drivers/infiniband/hw/hfi1/ipoib_tx.c | 2 +-
drivers/infiniband/hw/hfi1/verbs_txreq.h | 2 +-
drivers/input/joystick/spaceball.c | 2 +-
drivers/mtd/nand/raw/mxc_nand.c | 2 +-
drivers/mtd/nand/raw/nand_bbt.c | 2 +-
drivers/net/wan/lmc/lmc_main.c | 2 +-
drivers/net/wireless/ath/ath10k/usb.c | 2 +-
drivers/net/wireless/ath/ath6kl/usb.c | 2 +-
drivers/net/wireless/cisco/airo.c | 2 +-
drivers/regulator/fixed.c | 2 +-
drivers/regulator/gpio-regulator.c | 2 +-
drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +-
drivers/scsi/qla2xxx/qla_inline.h | 2 +-
drivers/scsi/qla2xxx/qla_iocb.c | 6 +++---
drivers/usb/core/of.c | 2 +-
include/drm/drm_dp_helper.h | 2 +-
include/linux/dynamic_debug.h | 2 +-
kernel/trace/trace_events.c | 2 +-
mm/balloon_compaction.c | 4 ++--
scripts/spelling.txt | 1 +
26 files changed, 30 insertions(+), 29 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 06/17] drivers: scsi: Fix trivial spelling
From: Kieran Bingham @ 2020-06-09 12:45 UTC (permalink / raw)
To: Kieran Bingham
Cc: Tyrel Datwyler, Jiri Kosina,
open list:IBM Power Virtual FC Device Drivers, Martin K. Petersen,
James E.J. Bottomley, open list, linux-renesas-soc,
supporter:QLOGIC QLA2XXX FC-SCSI DRIVER, Nilesh Javali,
Kieran Bingham, Paul Mackerras,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT
In-Reply-To: <20200609124610.3445662-1-kieran.bingham+renesas@ideasonboard.com>
The word 'descriptor' is misspelled throughout the tree.
Fix it up accordingly:
decriptors -> descriptors
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +-
drivers/scsi/qla2xxx/qla_inline.h | 2 +-
drivers/scsi/qla2xxx/qla_iocb.c | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 635f6f9cffc4..77f4d37d5bd6 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -1344,7 +1344,7 @@ static void ibmvfc_map_sg_list(struct scsi_cmnd *scmd, int nseg,
}
/**
- * ibmvfc_map_sg_data - Maps dma for a scatterlist and initializes decriptor fields
+ * ibmvfc_map_sg_data - Maps dma for a scatterlist and initializes descriptor fields
* @scmd: struct scsi_cmnd with the scatterlist
* @evt: ibmvfc event struct
* @vfc_cmd: vfc_cmd that contains the memory descriptor
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index 44e64aa21194..a92587624c72 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -667,7 +667,7 @@ static int map_sg_list(struct scsi_cmnd *cmd, int nseg,
}
/**
- * map_sg_data: - Maps dma for a scatterlist and initializes decriptor fields
+ * map_sg_data: - Maps dma for a scatterlist and initializes descriptor fields
* @cmd: struct scsi_cmnd with the scatterlist
* @srp_cmd: srp_cmd that contains the memory descriptor
* @dev: device for which to map dma memory
diff --git a/drivers/scsi/qla2xxx/qla_inline.h b/drivers/scsi/qla2xxx/qla_inline.h
index 1fb6ccac07cc..861dc522723c 100644
--- a/drivers/scsi/qla2xxx/qla_inline.h
+++ b/drivers/scsi/qla2xxx/qla_inline.h
@@ -11,7 +11,7 @@
* Continuation Type 1 IOCBs to allocate.
*
* @vha: HA context
- * @dsds: number of data segment decriptors needed
+ * @dsds: number of data segment descriptors needed
*
* Returns the number of IOCB entries needed to store @dsds.
*/
diff --git a/drivers/scsi/qla2xxx/qla_iocb.c b/drivers/scsi/qla2xxx/qla_iocb.c
index 8865c35d3421..1d3c58c5f0e2 100644
--- a/drivers/scsi/qla2xxx/qla_iocb.c
+++ b/drivers/scsi/qla2xxx/qla_iocb.c
@@ -44,7 +44,7 @@ qla2x00_get_cmd_direction(srb_t *sp)
* qla2x00_calc_iocbs_32() - Determine number of Command Type 2 and
* Continuation Type 0 IOCBs to allocate.
*
- * @dsds: number of data segment decriptors needed
+ * @dsds: number of data segment descriptors needed
*
* Returns the number of IOCB entries needed to store @dsds.
*/
@@ -66,7 +66,7 @@ qla2x00_calc_iocbs_32(uint16_t dsds)
* qla2x00_calc_iocbs_64() - Determine number of Command Type 3 and
* Continuation Type 1 IOCBs to allocate.
*
- * @dsds: number of data segment decriptors needed
+ * @dsds: number of data segment descriptors needed
*
* Returns the number of IOCB entries needed to store @dsds.
*/
@@ -669,7 +669,7 @@ qla24xx_build_scsi_type_6_iocbs(srb_t *sp, struct cmd_type_6 *cmd_pkt,
* qla24xx_calc_dsd_lists() - Determine number of DSD list required
* for Command Type 6.
*
- * @dsds: number of data segment decriptors needed
+ * @dsds: number of data segment descriptors needed
*
* Returns the number of dsd list needed to store @dsds.
*/
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox