* Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
From: Bjorn Helgaas @ 2018-05-14 12:47 UTC (permalink / raw)
To: Nipun Gupta
Cc: robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, hch, joro, m.szyprowski, shawnguo,
frowand.list, bhelgaas, iommu, linux-kernel, devicetree,
linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan,
stuyoder, laurentiu.tudor, leoyang.li
In-Reply-To: <1525069641-8523-6-git-send-email-nipun.gupta@nxp.com>
When you add the changleog, please also fix the subject typo:
- bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
^^^^^^^
+ bus: fsl-mc: support dma configure for devices on fsl-mc bus
On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 5d8266c..624828b 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> return 0;
> }
>
> +static int fsl_mc_dma_configure(struct device *dev)
> +{
> + struct device *dma_dev = dev;
> +
> + while (dev_is_fsl_mc(dma_dev))
> + dma_dev = dma_dev->parent;
> +
> + return of_dma_configure(dev, dma_dev->of_node, 0);
> +}
> +
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> .name = "fsl-mc",
> .match = fsl_mc_bus_match,
> .uevent = fsl_mc_bus_uevent,
> + .dma_configure = fsl_mc_dma_configure,
> .dev_groups = fsl_mc_dev_groups,
> };
> EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> mc_dev->icid = parent_mc_dev->icid;
> mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
> mc_dev->dev.dma_mask = &mc_dev->dma_mask;
> + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
> dev_set_msi_domain(&mc_dev->dev,
> dev_get_msi_domain(&parent_mc_dev->dev));
> }
> @@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> goto error_cleanup_dev;
> }
>
> - /* Objects are coherent, unless 'no shareability' flag set. */
> - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> -
> /*
> * The device-specific probe callback will get invoked by device_add()
> */
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 1/3] powerpc/io: Add __raw_writeq_be() __raw_rm_writeq_be()
From: Michael Ellerman @ 2018-05-14 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: alistair, paulus
Add byte-swapping versions of __raw_writeq() and __raw_rm_writeq().
This allows us to avoid sparse warnings caused by passing __be64 to
__raw_writeq(), which takes unsigned long:
arch/powerpc/platforms/powernv/pci-ioda.c:1981:38:
warning: incorrect type in argument 1 (different base types)
expected unsigned long [unsigned] v
got restricted __be64 [usertype] <noident>
It's also generally preferable to use a byte-swapping accessor rather
than doing it by hand in the code, which is more bug prone.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/io.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index af074923d598..e0331e754568 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -367,6 +367,11 @@ static inline void __raw_writeq(unsigned long v, volatile void __iomem *addr)
*(volatile unsigned long __force *)PCI_FIX_ADDR(addr) = v;
}
+static inline void __raw_writeq_be(unsigned long v, volatile void __iomem *addr)
+{
+ __raw_writeq((__force unsigned long)cpu_to_be64(v), addr);
+}
+
/*
* Real mode versions of the above. Those instructions are only supposed
* to be used in hypervisor real mode as per the architecture spec.
@@ -395,6 +400,11 @@ static inline void __raw_rm_writeq(u64 val, volatile void __iomem *paddr)
: : "r" (val), "r" (paddr) : "memory");
}
+static inline void __raw_rm_writeq_be(u64 val, volatile void __iomem *paddr)
+{
+ __raw_rm_writeq((__force u64)cpu_to_be64(val), paddr);
+}
+
static inline u8 __raw_rm_readb(volatile void __iomem *paddr)
{
u8 ret;
--
2.14.1
^ permalink raw reply related
* [PATCH 2/3] powerpc/powernv: Use __raw_[rm_]writeq_be() in pci-ioda.c
From: Michael Ellerman @ 2018-05-14 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: alistair, paulus
In-Reply-To: <20180514125033.12000-1-mpe@ellerman.id.au>
This allows us to squash some sparse warnings and also avoids having
to do explicity endian conversions in the code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3f9c69d7623a..f9f2b1dc9357 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1976,9 +1976,10 @@ static void pnv_pci_p7ioc_tce_invalidate(struct iommu_table *tbl,
mb(); /* Ensure above stores are visible */
while (start <= end) {
if (rm)
- __raw_rm_writeq(cpu_to_be64(start), invalidate);
+ __raw_rm_writeq_be(start, invalidate);
else
- __raw_writeq(cpu_to_be64(start), invalidate);
+ __raw_writeq_be(start, invalidate);
+
start += inc;
}
@@ -2055,9 +2056,9 @@ static void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
mb(); /* Ensure previous TCE table stores are visible */
if (rm)
- __raw_rm_writeq(cpu_to_be64(val), invalidate);
+ __raw_rm_writeq_be(val, invalidate);
else
- __raw_writeq(cpu_to_be64(val), invalidate);
+ __raw_writeq_be(val, invalidate);
}
static inline void pnv_pci_phb3_tce_invalidate_pe(struct pnv_ioda_pe *pe)
@@ -2067,7 +2068,7 @@ static inline void pnv_pci_phb3_tce_invalidate_pe(struct pnv_ioda_pe *pe)
unsigned long val = PHB3_TCE_KILL_INVAL_PE | (pe->pe_number & 0xFF);
mb(); /* Ensure above stores are visible */
- __raw_writeq(cpu_to_be64(val), invalidate);
+ __raw_writeq_be(val, invalidate);
}
static void pnv_pci_phb3_tce_invalidate(struct pnv_ioda_pe *pe, bool rm,
@@ -2090,9 +2091,9 @@ static void pnv_pci_phb3_tce_invalidate(struct pnv_ioda_pe *pe, bool rm,
while (start <= end) {
if (rm)
- __raw_rm_writeq(cpu_to_be64(start), invalidate);
+ __raw_rm_writeq_be(start, invalidate);
else
- __raw_writeq(cpu_to_be64(start), invalidate);
+ __raw_writeq_be(start, invalidate);
start += inc;
}
}
--
2.14.1
^ permalink raw reply related
* [PATCH 3/3] powerpc/powernv: Use __raw_[rm_]writeq_be() in npu-dma.c
From: Michael Ellerman @ 2018-05-14 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: alistair, paulus
In-Reply-To: <20180514125033.12000-1-mpe@ellerman.id.au>
This allows us to squash some sparse warnings and also avoids having
to do explicity endian conversions in the code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/powernv/npu-dma.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c
index 525e966dce34..8cdf91f5d3a4 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -459,10 +459,9 @@ static void mmio_launch_invalidate(struct mmio_atsd_reg *mmio_atsd_reg,
struct npu *npu = mmio_atsd_reg->npu;
int reg = mmio_atsd_reg->reg;
- __raw_writeq(cpu_to_be64(va),
- npu->mmio_atsd_regs[reg] + XTS_ATSD_AVA);
+ __raw_writeq_be(va, npu->mmio_atsd_regs[reg] + XTS_ATSD_AVA);
eieio();
- __raw_writeq(cpu_to_be64(launch), npu->mmio_atsd_regs[reg]);
+ __raw_writeq_be(launch, npu->mmio_atsd_regs[reg]);
}
static void mmio_invalidate_pid(struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS],
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v4 1/2] cxl: Set the PBCQ Tunnel BAR register when enabling capi mode
From: Philippe Bergheaud @ 2018-05-14 13:00 UTC (permalink / raw)
To: Michael Ellerman, stewart@linux.vnet.ibm.com, linuxppc-dev
Cc: fbarrat, clombard, benh
In-Reply-To: <87sh6upl2i.fsf@concordia.ellerman.id.au>
On 14/05/2018 12:51, Michael Ellerman wrote:
> Philippe Bergheaud <felix@linux.ibm.com> writes:
>
>> Skiboot used to set the default Tunnel BAR register value when capi mode
>> was enabled. This approach was ok for the cxl driver, but prevented other
>> drivers from choosing different values.
>>
>> Skiboot versions > 5.11 will not set the default value any longer. This
>> patch modifies the cxl driver to set/reset the Tunnel BAR register when
>> entering/exiting the cxl mode, with pnv_pci_set_tunnel_bar().
>>
>> That should work with old skiboot (since we are re-writing the value
>> already set) and new skiboot.
> But doesn't that mean new skiboot can't boot any old kernel? That seems
> undesirable.
>
> cheers
>
Yes, with new skiboot, all kernels will boot.
Capi mode tunnelled operations did not work until linux-4.17-rc1 (Apr
15, 2008). With new skiboot, kernels since linux-4.17-rc1 will loose
tunneled operations in capi mode, until this patch set is merged.
Capi mode tunneled operations are not used in any IBM or partner GA
products. The feature will be fully supported after this patch set and
the libcxl PR https://github.com/ibm-capi/libcxl/pull/29 are merged.
Philippe
^ permalink raw reply
* [PATCH 1/2] powerpc: Rename thread_struct.fs to addr_limit
From: Michael Ellerman @ 2018-05-14 13:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kernel-hardening, thgarnie, keescook
It's called 'fs' for historical reasons, it's named after the x86 'FS'
register. But we don't have to use that name for the member of
thread_struct, and in fact arch/x86 doesn't even call it 'fs' anymore.
So rename it to 'addr_limit', which better reflects what it's used
for, and is also the name used on other arches.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/processor.h | 6 +++---
arch/powerpc/include/asm/uaccess.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index b4778cfaad5b..07167c2d1825 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -264,7 +264,7 @@ struct thread_struct {
unsigned long ksp_vsid;
#endif
struct pt_regs *regs; /* Pointer to saved register state */
- mm_segment_t fs; /* for get_fs() validation */
+ mm_segment_t addr_limit; /* for get_fs() validation */
#ifdef CONFIG_BOOKE
/* BookE base exception scratch space; align on cacheline */
unsigned long normsave[8] ____cacheline_aligned;
@@ -398,7 +398,7 @@ struct thread_struct {
#define INIT_THREAD { \
.ksp = INIT_SP, \
.ksp_limit = INIT_SP_LIMIT, \
- .fs = KERNEL_DS, \
+ .addr_limit = KERNEL_DS, \
.pgdir = swapper_pg_dir, \
.fpexc_mode = MSR_FE0 | MSR_FE1, \
SPEFSCR_INIT \
@@ -407,7 +407,7 @@ struct thread_struct {
#define INIT_THREAD { \
.ksp = INIT_SP, \
.regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \
- .fs = KERNEL_DS, \
+ .addr_limit = KERNEL_DS, \
.fpexc_mode = 0, \
.ppr = INIT_PPR, \
.fscr = FSCR_TAR | FSCR_EBB \
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index a62ee663b2c8..a91cea15187b 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -30,8 +30,8 @@
#endif
#define get_ds() (KERNEL_DS)
-#define get_fs() (current->thread.fs)
-#define set_fs(val) (current->thread.fs = (val))
+#define get_fs() (current->thread.addr_limit)
+#define set_fs(val) (current->thread.addr_limit = (val))
#define segment_eq(a, b) ((a).seg == (b).seg)
--
2.14.1
^ permalink raw reply related
* [PATCH 2/2] powerpc: Check address limit on user-mode return (TIF_FSCHECK)
From: Michael Ellerman @ 2018-05-14 13:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kernel-hardening, thgarnie, keescook
In-Reply-To: <20180514130316.23855-1-mpe@ellerman.id.au>
set_fs() sets the addr_limit, which is used in access_ok() to
determine if an address is a user or kernel address.
Some code paths use set_fs() to temporarily elevate the addr_limit so
that kernel code can read/write kernel memory as if it were user
memory. That is fine as long as the code can't ever return to
userspace with the addr_limit still elevated.
If that did happen, then userspace can read/write kernel memory as if
it were user memory, eg. just with write(2). In case it's not clear,
that is very bad. It has also happened in the past due to bugs.
Commit 5ea0727b163c ("x86/syscalls: Check address limit on user-mode
return") added a mechanism to check the addr_limit value before
returning to userspace. Any call to set_fs() sets a thread flag,
TIF_FSCHECK, and if we see that on the return to userspace we go out
of line to check that the addr_limit value is not elevated.
For further info see the above commit, as well as:
https://lwn.net/Articles/722267/
https://bugs.chromium.org/p/project-zero/issues/detail?id=990
Verified to work on 64-bit Book3S using a POC that objdumps the system
call handler, and a modified lkdtm_CORRUPT_USER_DS() that doesn't kill
the caller.
Before:
$ sudo ./test-tif-fscheck
...
0000000000000000 <.data>:
0: e1 f7 8a 79 rldicl. r10,r12,30,63
4: 80 03 82 40 bne 0x384
8: 00 40 8a 71 andi. r10,r12,16384
c: 78 0b 2a 7c mr r10,r1
10: 10 fd 21 38 addi r1,r1,-752
14: 08 00 c2 41 beq- 0x1c
18: 58 09 2d e8 ld r1,2392(r13)
1c: 00 00 41 f9 std r10,0(r1)
20: 70 01 61 f9 std r11,368(r1)
24: 78 01 81 f9 std r12,376(r1)
28: 70 00 01 f8 std r0,112(r1)
2c: 78 00 41 f9 std r10,120(r1)
30: 20 00 82 41 beq 0x50
34: a6 42 4c 7d mftb r10
After:
$ sudo ./test-tif-fscheck
Killed
And in dmesg:
Invalid address limit on user-mode return
WARNING: CPU: 1 PID: 3689 at ../include/linux/syscalls.h:260 do_notify_resume+0x140/0x170
...
NIP [c00000000001ee50] do_notify_resume+0x140/0x170
LR [c00000000001ee4c] do_notify_resume+0x13c/0x170
Call Trace:
do_notify_resume+0x13c/0x170 (unreliable)
ret_from_except_lite+0x70/0x74
Performance overhead is essentially zero in the usual case, because
the bit is checked as part of the existing _TIF_USER_WORK_MASK check.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/thread_info.h | 8 +++++---
arch/powerpc/include/asm/uaccess.h | 8 +++++++-
arch/powerpc/kernel/signal.c | 4 ++++
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index 5964145db03d..f308dfeb2746 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -79,8 +79,7 @@ extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src
#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
#define TIF_SIGPENDING 1 /* signal pending */
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
-#define TIF_POLLING_NRFLAG 3 /* true if poll_idle() is polling
- TIF_NEED_RESCHED */
+#define TIF_FSCHECK 3 /* Check FS is USER_DS on return */
#define TIF_32BIT 4 /* 32 bit binary */
#define TIF_RESTORE_TM 5 /* need to restore TM FP/VEC/VSX */
#define TIF_PATCH_PENDING 6 /* pending live patching update */
@@ -99,6 +98,7 @@ extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src
#if defined(CONFIG_PPC64)
#define TIF_ELF2ABI 18 /* function descriptors must die! */
#endif
+#define TIF_POLLING_NRFLAG 19 /* true if poll_idle() is polling TIF_NEED_RESCHED */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
@@ -118,13 +118,15 @@ extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src
#define _TIF_SYSCALL_TRACEPOINT (1<<TIF_SYSCALL_TRACEPOINT)
#define _TIF_EMULATE_STACK_STORE (1<<TIF_EMULATE_STACK_STORE)
#define _TIF_NOHZ (1<<TIF_NOHZ)
+#define _TIF_FSCHECK (1<<TIF_FSCHECK)
#define _TIF_SYSCALL_DOTRACE (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
_TIF_SECCOMP | _TIF_SYSCALL_TRACEPOINT | \
_TIF_NOHZ)
#define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
_TIF_NOTIFY_RESUME | _TIF_UPROBE | \
- _TIF_RESTORE_TM | _TIF_PATCH_PENDING)
+ _TIF_RESTORE_TM | _TIF_PATCH_PENDING | \
+ _TIF_FSCHECK)
#define _TIF_PERSYSCALL_MASK (_TIF_RESTOREALL|_TIF_NOERROR)
/* Bits in local_flags */
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index a91cea15187b..abba80f8ff04 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -31,7 +31,13 @@
#define get_ds() (KERNEL_DS)
#define get_fs() (current->thread.addr_limit)
-#define set_fs(val) (current->thread.addr_limit = (val))
+
+static inline void set_fs(mm_segment_t fs)
+{
+ current->thread.addr_limit = fs;
+ /* On user-mode return check addr_limit (fs) is correct */
+ set_thread_flag(TIF_FSCHECK);
+}
#define segment_eq(a, b) ((a).seg == (b).seg)
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index 61db86ecd318..fb932f1202c7 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -15,6 +15,7 @@
#include <linux/key.h>
#include <linux/context_tracking.h>
#include <linux/livepatch.h>
+#include <linux/syscalls.h>
#include <asm/hw_breakpoint.h>
#include <linux/uaccess.h>
#include <asm/unistd.h>
@@ -150,6 +151,9 @@ void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)
{
user_exit();
+ /* Check valid addr_limit, TIF check is done there */
+ addr_limit_user_check();
+
if (thread_info_flags & _TIF_UPROBE)
uprobe_notify_resume(regs);
--
2.14.1
^ permalink raw reply related
* Re: [PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
From: Laurentiu Tudor @ 2018-05-14 13:39 UTC (permalink / raw)
To: Nipun Gupta, robin.murphy@arm.com, will.deacon@arm.com,
mark.rutland@arm.com, catalin.marinas@arm.com
Cc: hch@lst.de, gregkh@linuxfoundation.org, joro@8bytes.org,
robh+dt@kernel.org, m.szyprowski@samsung.com, shawnguo@kernel.org,
frowand.list@gmail.com, bhelgaas@google.com,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
Bharat Bhushan, stuyoder@gmail.com, Leo Li
In-Reply-To: <1524824826-29473-6-git-send-email-nipun.gupta@nxp.com>
Hi Nipun,
On 04/27/2018 01:27 PM, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-=
bus.c
> index 5d8266c..624828b 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, str=
uct kobj_uevent_env *env)
> return 0;
> }
>
> +static int fsl_mc_dma_configure(struct device *dev)
> +{
> + struct device *dma_dev =3D dev;
> +
> + while (dev_is_fsl_mc(dma_dev))
> + dma_dev =3D dma_dev->parent;
> +
> + return of_dma_configure(dev, dma_dev->of_node, 0);
> +}
> +
> static ssize_t modalias_show(struct device *dev, struct device_attribut=
e *attr,
> char *buf)
> {
> @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type =3D {
> .name =3D "fsl-mc",
> .match =3D fsl_mc_bus_match,
> .uevent =3D fsl_mc_bus_uevent,
> + .dma_configure =3D fsl_mc_dma_configure,
> .dev_groups =3D fsl_mc_dev_groups,
> };
> EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_des=
c,
> mc_dev->icid =3D parent_mc_dev->icid;
> mc_dev->dma_mask =3D FSL_MC_DEFAULT_DMA_MASK;
> mc_dev->dev.dma_mask =3D &mc_dev->dma_mask;
> + mc_dev->dev.coherent_dma_mask =3D mc_dev->dma_mask;
This change seems a bit unrelated to the patch subject. I wonder if it=20
makes sense to split it it in a distinct patch.
---
Best Regards, Laurentiu=
^ permalink raw reply
* Re: [PATCH v10 02/25] x86/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
From: Laurent Dufour @ 2018-05-14 14:47 UTC (permalink / raw)
To: Punit Agrawal, akpm
Cc: mhocko, peterz, kirill, ak, dave, jack, Matthew Wilcox, benh, mpe,
paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, Daniel Jordan, David Rientjes,
Jerome Glisse, Ganesh Mahendran, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, paulmck, Tim Chen, linuxppc-dev,
x86
In-Reply-To: <87sh72jtmn.fsf@e105922-lin.cambridge.arm.com>
On 08/05/2018 13:04, Punit Agrawal wrote:
> Hi Laurent,
>
> Laurent Dufour <ldufour@linux.vnet.ibm.com> writes:
>
>> Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT which turns on the
>> Speculative Page Fault handler when building for 64bit.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
>> ---
>> arch/x86/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index d8983df5a2bc..ebdeb48e4a4a 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -30,6 +30,7 @@ config X86_64
>> select MODULES_USE_ELF_RELA
>> select X86_DEV_DMA_OPS
>> select ARCH_HAS_SYSCALL_WRAPPER
>> + select ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
>
> I'd suggest merging this patch with the one making changes to the
> architectural fault handler towards the end of the series.
>
> The Kconfig change is closely tied to the architectural support for SPF
> and makes sense to be in a single patch.
>
> If there's a good reason to keep them as separate patches, please move
> the architecture Kconfig changes after the patch adding fault handler
> changes.
>
> It's better to enable the feature once the core infrastructure is merged
> rather than at the beginning of the series to avoid potential bad
> fallout from incomplete functionality during bisection.
Indeed bisection was the reason why Andrew asked me to push the configuration
enablement on top of the series (https://lkml.org/lkml/2017/10/10/1229).
I also think it would be better to have the architecture enablement in on patch
but that would mean that the code will not be build when bisecting without the
latest patch adding the per architecture code.
I'm fine with the both options.
Andrew, what do you think would be the best here ?
Thanks,
Laurent.
>
> All the comments here definitely hold for the arm64 patches that you
> plan to include with the next update.
>
> Thanks,
> Punit
>
>>
>> #
>> # Arch settings
>
^ permalink raw reply
* [PATCH 00/21] i2c: make use of i2c_8bit_addr_from_msg
From: Peter Rosin @ 2018-05-14 14:53 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Brendan Higgins, Benjamin Herrenschmidt,
Joel Stanley, Andrew Jeffery, Guenter Roeck,
Uwe Kleine-König, Pengutronix Kernel Team, Wolfram Sang,
Peter Korsgaard, Andy Gross, David Brown, Linus Walleij,
linux-i2c, openbmc, linux-arm-kernel, linux-aspeed, linuxppc-dev,
linux-arm-msm, linux-soc
Hi!
The nice little inline i2c_8bit_addr_from_msg is not getting
enough use. This series improves the situation and drops a
bunch of lines in the process.
I have only compile-tested (that part fine, at least over here).
Cheers,
Peter
Peter Rosin (21):
i2c: algo: bit: make use of i2c_8bit_addr_from_msg
i2c: algo: pca: make use of i2c_8bit_addr_from_msg
i2c: algo: pcf: make use of i2c_8bit_addr_from_msg
i2c: aspeed: make use of i2c_8bit_addr_from_msg
i2c: axxia: make use of i2c_8bit_addr_from_msg
i2c: diolan: make use of i2c_8bit_addr_from_msg
i2c: efm32: make use of i2c_8bit_addr_from_msg
i2c: eg20t: make use of i2c_8bit_addr_from_msg
i2c: emev2: make use of i2c_8bit_addr_from_msg
i2c: hix5hd2: make use of i2c_8bit_addr_from_msg
i2c: imx-lpi2c: make use of i2c_8bit_addr_from_msg
i2c: imx: make use of i2c_8bit_addr_from_msg
i2c: kempld: make use of i2c_8bit_addr_from_msg
i2c: mxs: make use of i2c_8bit_addr_from_msg
i2c: ocores: make use of i2c_8bit_addr_from_msg
i2c: pasemi: make use of i2c_8bit_addr_from_msg
i2c: qup: make use of i2c_8bit_addr_from_msg
i2c: rcar: make use of i2c_8bit_addr_from_msg
i2c: riic: make use of i2c_8bit_addr_from_msg
i2c: stu300: make use of i2c_8bit_addr_from_msg
i2c: xiic: make use of i2c_8bit_addr_from_msg
drivers/i2c/algos/i2c-algo-bit.c | 4 +---
drivers/i2c/algos/i2c-algo-pca.c | 5 +----
drivers/i2c/algos/i2c-algo-pcf.c | 5 +----
drivers/i2c/busses/i2c-aspeed.c | 3 +--
drivers/i2c/busses/i2c-axxia.c | 5 +++--
drivers/i2c/busses/i2c-diolan-u2c.c | 11 ++++-------
drivers/i2c/busses/i2c-efm32.c | 3 +--
drivers/i2c/busses/i2c-eg20t.c | 5 ++---
drivers/i2c/busses/i2c-emev2.c | 2 +-
drivers/i2c/busses/i2c-hix5hd2.c | 9 ++-------
drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +---
drivers/i2c/busses/i2c-imx.c | 10 +++++-----
drivers/i2c/busses/i2c-kempld.c | 7 +++----
drivers/i2c/busses/i2c-mxs.c | 9 +++------
drivers/i2c/busses/i2c-ocores.c | 5 +----
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-qup.c | 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-riic.c | 5 ++---
drivers/i2c/busses/i2c-stu300.c | 22 +++++++++++++---------
drivers/i2c/busses/i2c-xiic.c | 11 ++---------
21 files changed, 50 insertions(+), 81 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 16/21] i2c: pasemi: make use of i2c_8bit_addr_from_msg
From: Peter Rosin @ 2018-05-14 14:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Peter Rosin, linuxppc-dev, linux-i2c, Wolfram Sang
In-Reply-To: <20180514145330.4857-1-peda@axentia.se>
Because it looks neater.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/i2c/busses/i2c-pasemi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-pasemi.c b/drivers/i2c/busses/i2c-pasemi.c
index df1dbc92a024..55fd5c6f3cca 100644
--- a/drivers/i2c/busses/i2c-pasemi.c
+++ b/drivers/i2c/busses/i2c-pasemi.c
@@ -121,7 +121,7 @@ static int pasemi_i2c_xfer_msg(struct i2c_adapter *adapter,
read = msg->flags & I2C_M_RD ? 1 : 0;
- TXFIFO_WR(smbus, MTXFIFO_START | (msg->addr << 1) | read);
+ TXFIFO_WR(smbus, MTXFIFO_START | i2c_8bit_addr_from_msg(msg));
if (read) {
TXFIFO_WR(smbus, msg->len | MTXFIFO_READ |
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v10 02/25] x86/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
From: Punit Agrawal @ 2018-05-14 15:05 UTC (permalink / raw)
To: Laurent Dufour
Cc: akpm, mhocko, peterz, kirill, ak, dave, jack, Matthew Wilcox,
benh, mpe, paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, Daniel Jordan, David Rientjes,
Jerome Glisse, Ganesh Mahendran, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, paulmck, Tim Chen, linuxppc-dev,
x86
In-Reply-To: <c289a58f-8afa-34c7-2624-c7bd2f6fcf48@linux.vnet.ibm.com>
Laurent Dufour <ldufour@linux.vnet.ibm.com> writes:
> On 08/05/2018 13:04, Punit Agrawal wrote:
>> Hi Laurent,
>>
>> Laurent Dufour <ldufour@linux.vnet.ibm.com> writes:
>>
>>> Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT which turns on the
>>> Speculative Page Fault handler when building for 64bit.
>>>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
>>> ---
>>> arch/x86/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>> index d8983df5a2bc..ebdeb48e4a4a 100644
>>> --- a/arch/x86/Kconfig
>>> +++ b/arch/x86/Kconfig
>>> @@ -30,6 +30,7 @@ config X86_64
>>> select MODULES_USE_ELF_RELA
>>> select X86_DEV_DMA_OPS
>>> select ARCH_HAS_SYSCALL_WRAPPER
>>> + select ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
>>
>> I'd suggest merging this patch with the one making changes to the
>> architectural fault handler towards the end of the series.
>>
>> The Kconfig change is closely tied to the architectural support for SPF
>> and makes sense to be in a single patch.
>>
>> If there's a good reason to keep them as separate patches, please move
>> the architecture Kconfig changes after the patch adding fault handler
>> changes.
>>
>> It's better to enable the feature once the core infrastructure is merged
>> rather than at the beginning of the series to avoid potential bad
>> fallout from incomplete functionality during bisection.
>
> Indeed bisection was the reason why Andrew asked me to push the configuration
> enablement on top of the series (https://lkml.org/lkml/2017/10/10/1229).
The config options have gone through another round of splitting (between
core and architecture) since that comment. I agree that it still makes
sense to define the core config - CONFIG_SPECULATIVE_PAGE_FAULT early
on.
Just to clarify, my suggestion was to only move the architecture configs
further down.
>
> I also think it would be better to have the architecture enablement in on patch
> but that would mean that the code will not be build when bisecting without the
> latest patch adding the per architecture code.
I don't see that as a problem. But if I'm in the minority, I am OK with
leaving things as they are as well.
Thanks,
Punit
^ permalink raw reply
* Re: [PATCH v10 06/25] mm: make pte_unmap_same compatible with SPF
From: Laurent Dufour @ 2018-05-14 15:09 UTC (permalink / raw)
To: vinayak menon
Cc: Andrew Morton, Michal Hocko, Peter Zijlstra, kirill, ak, dave,
jack, Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner,
Ingo Molnar, hpa, Will Deacon, Sergey Senozhatsky,
Andrea Arcangeli, Alexei Starovoitov, kemi.wang,
sergey.senozhatsky.work, Daniel Jordan, David Rientjes,
Jerome Glisse, Ganesh Mahendran, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, Paul McKenney, Tim Chen,
linuxppc-dev, x86, Vinayak Menon
In-Reply-To: <CAOaiJ-n6P-hjBEkiR4+MyFYunocPgzAYkG1wALDcmi7ROe4-ag@mail.gmail.com>
On 10/05/2018 18:15, vinayak menon wrote:
> On Tue, Apr 17, 2018 at 8:03 PM, Laurent Dufour
> <ldufour@linux.vnet.ibm.com> wrote:
>> pte_unmap_same() is making the assumption that the page table are still
>> around because the mmap_sem is held.
>> This is no more the case when running a speculative page fault and
>> additional check must be made to ensure that the final page table are still
>> there.
>>
>> This is now done by calling pte_spinlock() to check for the VMA's
>> consistency while locking for the page tables.
>>
>> This is requiring passing a vm_fault structure to pte_unmap_same() which is
>> containing all the needed parameters.
>>
>> As pte_spinlock() may fail in the case of a speculative page fault, if the
>> VMA has been touched in our back, pte_unmap_same() should now return 3
>> cases :
>> 1. pte are the same (0)
>> 2. pte are different (VM_FAULT_PTNOTSAME)
>> 3. a VMA's changes has been detected (VM_FAULT_RETRY)
>>
>> The case 2 is handled by the introduction of a new VM_FAULT flag named
>> VM_FAULT_PTNOTSAME which is then trapped in cow_user_page().
>> If VM_FAULT_RETRY is returned, it is passed up to the callers to retry the
>> page fault while holding the mmap_sem.
>>
>> Acked-by: David Rientjes <rientjes@google.com>
>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
>> ---
>> include/linux/mm.h | 1 +
>> mm/memory.c | 39 ++++++++++++++++++++++++++++-----------
>> 2 files changed, 29 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 4d1aff80669c..714da99d77a3 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1208,6 +1208,7 @@ static inline void clear_page_pfmemalloc(struct page *page)
>> #define VM_FAULT_NEEDDSYNC 0x2000 /* ->fault did not modify page tables
>> * and needs fsync() to complete (for
>> * synchronous page faults in DAX) */
>> +#define VM_FAULT_PTNOTSAME 0x4000 /* Page table entries have changed */
>
>
> This has to be added to VM_FAULT_RESULT_TRACE ?
Indeed there is no chance that the macro VM_FAULT_RESULT_TRACE would have to
translate that code to a string since VM_FAULT_PTNOTSAME is currently only
returned by pte_unmap_same() and then converted by its only caller
do_swap_page() to return 0. So VM_FAULT_PTNOTSAME is not expected to be seen
outside of these services which are never using VM_FAULT_RESULT_TRACE().
This being said, this may be a good idea to add it in the case of future
potential usage.
^ permalink raw reply
* Re: [PATCH v10 09/25] mm: protect VMA modifications using VMA sequence count
From: Laurent Dufour @ 2018-05-14 15:25 UTC (permalink / raw)
To: Minchan Kim
Cc: akpm, mhocko, peterz, kirill, ak, dave, jack, Matthew Wilcox,
benh, mpe, paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, Daniel Jordan, David Rientjes,
Jerome Glisse, Ganesh Mahendran, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, paulmck, Tim Chen, linuxppc-dev,
x86
In-Reply-To: <20180423071941.GD114098@rodete-desktop-imager.corp.google.com>
On 23/04/2018 09:19, Minchan Kim wrote:
> On Tue, Apr 17, 2018 at 04:33:15PM +0200, Laurent Dufour wrote:
>> The VMA sequence count has been introduced to allow fast detection of
>> VMA modification when running a page fault handler without holding
>> the mmap_sem.
>>
>> This patch provides protection against the VMA modification done in :
>> - madvise()
>> - mpol_rebind_policy()
>> - vma_replace_policy()
>> - change_prot_numa()
>> - mlock(), munlock()
>> - mprotect()
>> - mmap_region()
>> - collapse_huge_page()
>> - userfaultd registering services
>>
>> In addition, VMA fields which will be read during the speculative fault
>> path needs to be written using WRITE_ONCE to prevent write to be split
>> and intermediate values to be pushed to other CPUs.
>>
>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
>> ---
>> fs/proc/task_mmu.c | 5 ++++-
>> fs/userfaultfd.c | 17 +++++++++++++----
>> mm/khugepaged.c | 3 +++
>> mm/madvise.c | 6 +++++-
>> mm/mempolicy.c | 51 ++++++++++++++++++++++++++++++++++-----------------
>> mm/mlock.c | 13 ++++++++-----
>> mm/mmap.c | 22 +++++++++++++---------
>> mm/mprotect.c | 4 +++-
>> mm/swap_state.c | 8 ++++++--
>> 9 files changed, 89 insertions(+), 40 deletions(-)
>>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index c486ad4b43f0..aeb417f28839 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -1136,8 +1136,11 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf,
>> goto out_mm;
>> }
>> for (vma = mm->mmap; vma; vma = vma->vm_next) {
>> - vma->vm_flags &= ~VM_SOFTDIRTY;
>> + vm_write_begin(vma);
>> + WRITE_ONCE(vma->vm_flags,
>> + vma->vm_flags & ~VM_SOFTDIRTY);
>> vma_set_page_prot(vma);
>> + vm_write_end(vma);
>
> trivial:
>
> I think It's tricky to maintain that VMA fields to be read during SPF should be
> (READ|WRITE_ONCE). I think we need some accessor to read/write them rather than
> raw accessing like like vma_set_page_prot. Maybe spf prefix would be helpful.
>
> vma_spf_set_value(vma, vm_flags, val);
>
> We also add some markers in vm_area_struct's fileds to indicate that
> people shouldn't access those fields directly.
>
> Just a thought.
At the beginning I was liking that idea but...
I'm not sure this will change a lot the code, most of the time the
vm_write_begin()/end() are surrounding part of code larger than one VMA
structure's field change. For this particular case and few others this will be
applicable but that's not the majority.
Thanks,
Laurent.
>
>
>> }
>> downgrade_write(&mm->mmap_sem);
>
>
>> diff --git a/mm/swap_state.c b/mm/swap_state.c
>> index fe079756bb18..8a8a402ed59f 100644
>> --- a/mm/swap_state.c
>> +++ b/mm/swap_state.c
>> @@ -575,6 +575,10 @@ static unsigned long swapin_nr_pages(unsigned long offset)
>> * the readahead.
>> *
>> * Caller must hold down_read on the vma->vm_mm if vmf->vma is not NULL.
>> + * This is needed to ensure the VMA will not be freed in our back. In the case
>> + * of the speculative page fault handler, this cannot happen, even if we don't
>> + * hold the mmap_sem. Callees are assumed to take care of reading VMA's fields
>
> I guess reader would be curious on *why* is safe with SPF.
> Comment about the why could be helpful for reviewer.
>
>> + * using READ_ONCE() to read consistent values.
>> */
>> struct page *swap_cluster_readahead(swp_entry_t entry, gfp_t gfp_mask,
>> struct vm_fault *vmf)
>> @@ -668,9 +672,9 @@ static inline void swap_ra_clamp_pfn(struct vm_area_struct *vma,
>> unsigned long *start,
>> unsigned long *end)
>> {
>> - *start = max3(lpfn, PFN_DOWN(vma->vm_start),
>> + *start = max3(lpfn, PFN_DOWN(READ_ONCE(vma->vm_start)),
>> PFN_DOWN(faddr & PMD_MASK));
>> - *end = min3(rpfn, PFN_DOWN(vma->vm_end),
>> + *end = min3(rpfn, PFN_DOWN(READ_ONCE(vma->vm_end)),
>> PFN_DOWN((faddr & PMD_MASK) + PMD_SIZE));
>> }
>>
>> --
>> 2.7.4
>>
>
^ permalink raw reply
* Re: [PATCH v3 3/4] powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS
From: Steven Rostedt @ 2018-05-14 15:28 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-kbuild, linuxppc-dev, Masahiro Yamada, Segher Boessenkool
In-Reply-To: <20180514035228.21316-4-npiggin@gmail.com>
On Mon, 14 May 2018 13:52:27 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:
> The powerpc toolchain can compile combinations of 32/64 bit and
> big/little endian, so it's convenient to consider, e.g.,
>
> `CC -m64 -mbig-endian`
>
> To be the C compiler for the purpose of invoking it to build target
> artifacts. So overriding the the CC variable to include thse flags
the these
> works for this purpose.
>
> Unfortunately that is not compatible with the way the proposed new
> Kconfig macro language will work.
>
> After previous patches in this series, these flags can be carefully
> passed in using flags instead.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> Since v2:
> - removed extra -EB in the recordmcount script (thanks mpe)
>
> arch/powerpc/Makefile | 16 +++++++++-------
> scripts/recordmcount.pl | 7 +++++++
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 167b26a0780c..6faf1d6ad9dd 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -75,13 +75,15 @@ endif
> endif
>
> ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
> -override LD += -EL
> +KBUILD_CFLAGS += -mlittle-endian
> +LDFLAGS += -EL
> LDEMULATION := lppc
> GNUTARGET := powerpcle
> MULTIPLEWORD := -mno-multiple
> KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
> else
> -override LD += -EB
> +KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
> +LDFLAGS += -EB
> LDEMULATION := ppc
> GNUTARGET := powerpc
> MULTIPLEWORD := -mmultiple
> @@ -94,19 +96,19 @@ aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
> aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
> endif
>
> -cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
> -cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
> ifneq ($(cc-name),clang)
> cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align
> endif
>
> +cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
> +cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
> aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
> aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
>
> ifeq ($(HAS_BIARCH),y)
> -override AS += -a$(BITS)
> -override LD += -m elf$(BITS)$(LDEMULATION)
> -override CC += -m$(BITS)
> +KBUILD_CFLAGS += -m$(BITS)
> +KBUILD_AFLAGS += -m$(BITS) -Wl,-a$(BITS)
> +LDFLAGS += -m elf$(BITS)$(LDEMULATION)
> KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
> endif
>
> diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
> index 191eb949d52c..3c67304a7425 100755
> --- a/scripts/recordmcount.pl
> +++ b/scripts/recordmcount.pl
> @@ -274,6 +274,13 @@ if ($arch eq "x86_64") {
> if ($bits == 64) {
> $type = ".quad";
> }
> + if ($endian eq "big") {
> + $cc .= " -mbig-endian ";
> + $ld .= " -EB ";
> + } else {
> + $cc .= " -mlittle-endian ";
> + $ld .= " -EL ";
> + }
Have you tried building all current archs with function tracing enabled
to make sure this doesn't break any of them? I can do it if you want.
-- Steve
>
> } elsif ($arch eq "arm") {
> $alignment = 2;
^ permalink raw reply
* Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
From: Andy Lutomirski @ 2018-05-14 15:32 UTC (permalink / raw)
To: Florian Weimer
Cc: Andy Lutomirski, linuxram, Dave Hansen, Linux-MM, Linux API,
linux-x86_64, linux-arch, X86 ML, linuxppc-dev
In-Reply-To: <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com>
> On May 14, 2018, at 5:01 AM, Florian Weimer <fweimer@redhat.com> wrote:
>=20
>> One thing we could do, though: the current initual state on process
>> creation is all access blocked on all keys. We could change it so that
>> half the keys are fully blocked and half are read-only. Then we could ad=
d
>> a PKEY_ALLOC_STRICT or similar that allocates a key with the correct
>> initial state*and* does the setsignal thing. If there are no keys left
>> with the correct initial state, then it fails.
>=20
> The initial PKRU value can currently be configured by the system administr=
ator. I fear this approach has too many moving parts to be viable.
>=20
>=20
Honestly, I think we should drop that option. I don=E2=80=99t see how we can=
expect an administrator to do this usefully.=
^ permalink raw reply
* Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
From: Florian Weimer @ 2018-05-14 15:34 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, linuxram, Dave Hansen, Linux-MM, Linux API,
linux-x86_64, linux-arch, X86 ML, linuxppc-dev
In-Reply-To: <E77C6E12-EF2A-435A-AAD4-1554459606F1@amacapital.net>
On 05/14/2018 05:32 PM, Andy Lutomirski wrote:
>
>
>
>> On May 14, 2018, at 5:01 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>
>>> One thing we could do, though: the current initual state on process
>>> creation is all access blocked on all keys. We could change it so that
>>> half the keys are fully blocked and half are read-only. Then we could add
>>> a PKEY_ALLOC_STRICT or similar that allocates a key with the correct
>>> initial state*and* does the setsignal thing. If there are no keys left
>>> with the correct initial state, then it fails.
>>
>> The initial PKRU value can currently be configured by the system administrator. I fear this approach has too many moving parts to be viable.
>>
>>
>
> Honestly, I think we should drop that option. I don’t see how we can expect an administrator to do this usefully.
I don't disagree—it makes things way less predictable in practice.
Thanks,
Florian
^ permalink raw reply
* [PATCH 0/2] sleeping functions in invalid context on panic fixes
From: Nicholas Piggin @ 2018-05-14 15:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
Here's a couple of fixes which seem to solve a problem where
panics can hang forever rather than reboot after 10 seconds. The
symptoms are that a CPU calls panic(), but later it is found in
idle.
Nicholas Piggin (2):
powerpc/powernv: Fix opal_event_shutdown() called with interrupts
disabled
powerpc/powernv: Fix NVRAM sleep in invalid context when crashing
arch/powerpc/platforms/powernv/opal-irqchip.c | 2 +-
arch/powerpc/platforms/powernv/opal-nvram.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 3 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH 1/2] powerpc/powernv: Fix opal_event_shutdown() called with interrupts disabled
From: Nicholas Piggin @ 2018-05-14 15:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180514155947.22753-1-npiggin@gmail.com>
A kernel crash in process context that calls emergency_restart from
panic will end up calling opal_event_shutdown with interrupts disabled
but not in interrupt. This causes a sleeping function to be called
which gives the following warning with sysrq+c:
Rebooting in 10 seconds..
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
in_atomic(): 0, irqs_disabled(): 1, pid: 7669, name: bash
CPU: 20 PID: 7669 Comm: bash Tainted: G D W 4.17.0-rc5+ #3
Call Trace:
dump_stack+0xb0/0xf4 (unreliable)
___might_sleep+0x174/0x1a0
mutex_lock+0x38/0xb0
__free_irq+0x68/0x460
free_irq+0x70/0xc0
opal_event_shutdown+0xb4/0xf0
opal_shutdown+0x24/0xa0
pnv_shutdown+0x28/0x40
machine_shutdown+0x44/0x60
machine_restart+0x28/0x80
emergency_restart+0x30/0x50
panic+0x2a0/0x328
oops_end+0x1ec/0x1f0
bad_page_fault+0xe8/0x154
handle_page_fault+0x34/0x38
--- interrupt: 300 at sysrq_handle_crash+0x44/0x60
LR = __handle_sysrq+0xfc/0x260
flag_spec.62335+0x12b844/0x1e8db4 (unreliable)
__handle_sysrq+0xfc/0x260
write_sysrq_trigger+0xa8/0xb0
proc_reg_write+0xac/0x110
__vfs_write+0x6c/0x240
vfs_write+0xd0/0x240
ksys_write+0x6c/0x110
Fixes: 9f0fd0499d30 ("powerpc/powernv: Add a virtual irqchip for opal events")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/powernv/opal-irqchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c b/arch/powerpc/platforms/powernv/opal-irqchip.c
index 9d1b8c0aaf93..05ffe05f0fdc 100644
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -177,7 +177,7 @@ void opal_event_shutdown(void)
if (!opal_irqs[i])
continue;
- if (in_interrupt())
+ if (in_interrupt() || irqs_disabled())
disable_irq_nosync(opal_irqs[i]);
else
free_irq(opal_irqs[i], NULL);
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] powerpc/powernv: Fix NVRAM sleep in invalid context when crashing
From: Nicholas Piggin @ 2018-05-14 15:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin, stable
In-Reply-To: <20180514155947.22753-1-npiggin@gmail.com>
Similarly to opal_event_shutdown, opal_nvram_write can be called in
the crash path with irqs disabled. Special case the delay to avoid
sleeping in invalid context.
Cc: stable@vger.kernel.org # v3.2
Fixes: 3b8070335f ("powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/powernv/opal-nvram.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-nvram.c b/arch/powerpc/platforms/powernv/opal-nvram.c
index 1bceb95f422d..5584247f5029 100644
--- a/arch/powerpc/platforms/powernv/opal-nvram.c
+++ b/arch/powerpc/platforms/powernv/opal-nvram.c
@@ -44,6 +44,10 @@ static ssize_t opal_nvram_read(char *buf, size_t count, loff_t *index)
return count;
}
+/*
+ * This can be called in the panic path with interrupts off, so use
+ * mdelay in that case.
+ */
static ssize_t opal_nvram_write(char *buf, size_t count, loff_t *index)
{
s64 rc = OPAL_BUSY;
@@ -58,10 +62,16 @@ static ssize_t opal_nvram_write(char *buf, size_t count, loff_t *index)
while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
rc = opal_write_nvram(__pa(buf), count, off);
if (rc == OPAL_BUSY_EVENT) {
- msleep(OPAL_BUSY_DELAY_MS);
+ if (in_interrupt() || irqs_disabled())
+ mdelay(OPAL_BUSY_DELAY_MS);
+ else
+ msleep(OPAL_BUSY_DELAY_MS);
opal_poll_events(NULL);
} else if (rc == OPAL_BUSY) {
- msleep(OPAL_BUSY_DELAY_MS);
+ if (in_interrupt() || irqs_disabled())
+ mdelay(OPAL_BUSY_DELAY_MS);
+ else
+ msleep(OPAL_BUSY_DELAY_MS);
}
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 00/21] i2c: make use of i2c_8bit_addr_from_msg
From: Joe Perches @ 2018-05-14 16:11 UTC (permalink / raw)
To: Peter Rosin, linux-kernel
Cc: Brendan Higgins, Benjamin Herrenschmidt, Joel Stanley,
Andrew Jeffery, Guenter Roeck, Uwe Kleine-König,
Pengutronix Kernel Team, Wolfram Sang, Peter Korsgaard,
Andy Gross, David Brown, Linus Walleij, linux-i2c, openbmc,
linux-arm-kernel, linux-aspeed, linuxppc-dev, linux-arm-msm,
linux-soc
In-Reply-To: <20180514145330.4857-1-peda@axentia.se>
On Mon, 2018-05-14 at 16:53 +0200, Peter Rosin wrote:
> Hi!
>
> The nice little inline i2c_8bit_addr_from_msg is not getting
> enough use. This series improves the situation and drops a
> bunch of lines in the process.
Perhaps the inline should test for I2C_M_REV_DIR_ADDR
as there is at least one use like
- addr = msg->addr << 1;
- if (flags & I2C_M_RD)
- addr |= 1;
+ addr = i2c_8bit_addr_from_msg(msg);
if (flags & I2C_M_REV_DIR_ADDR)
addr ^= 1;
which look odd
Do any of these changes now no longer need
the temporary flags variable?
^ permalink raw reply
* Re: [PATCH 00/21] i2c: make use of i2c_8bit_addr_from_msg
From: Peter Rosin @ 2018-05-14 17:01 UTC (permalink / raw)
To: Joe Perches, linux-kernel
Cc: Brendan Higgins, Benjamin Herrenschmidt, Joel Stanley,
Andrew Jeffery, Guenter Roeck, Uwe Kleine-König,
Pengutronix Kernel Team, Wolfram Sang, Peter Korsgaard,
Andy Gross, David Brown, Linus Walleij, linux-i2c, openbmc,
linux-arm-kernel, linux-aspeed, linuxppc-dev, linux-arm-msm,
linux-soc
In-Reply-To: <c83bb5ddf36b419c4c01e20384c7b532c9a48cd4.camel@perches.com>
On 2018-05-14 18:11, Joe Perches wrote:
> On Mon, 2018-05-14 at 16:53 +0200, Peter Rosin wrote:
>> Hi!
>>
>> The nice little inline i2c_8bit_addr_from_msg is not getting
>> enough use. This series improves the situation and drops a
>> bunch of lines in the process.
>
> Perhaps the inline should test for I2C_M_REV_DIR_ADDR
> as there is at least one use like
>
> - addr = msg->addr << 1;
> - if (flags & I2C_M_RD)
> - addr |= 1;
> + addr = i2c_8bit_addr_from_msg(msg);
> if (flags & I2C_M_REV_DIR_ADDR)
> addr ^= 1;
>
> which look odd
I say no, because the driver has to also indicate support with
I2C_FUNC_PROTOCOL_MANGLING and I don't see a sane way to check
that part of the contract. But what do I know. Seems orthogonal.
> Do any of these changes now no longer need
> the temporary flags variable?
Right, I thought I had made any obvious further simplification made
possible by these changes, but I overlooked that one. The flags
variable is certainly over-engineered in i2c-algo-pcf.c and would
be a good candidate for removal. But that's only patch 3/21.
I'll wait for a bit with an update, and Wolfram can adjust this on
the way in if he feels like it.
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Allow LD_DEAD_CODE_DATA_ELIMINATION to be selected
From: Mathieu Malaterre @ 2018-05-14 19:10 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, linux-arch, Nicolas Pitre, linux-kbuild
In-Reply-To: <20180502222430.2a1cced4@roar.ozlabs.ibm.com>
On Wed, May 2, 2018 at 2:24 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> On Wed, 2 May 2018 11:17:52 +0200
> Mathieu Malaterre <malat@debian.org> wrote:
>
>> Nick,
>>
>> On Sat, Apr 21, 2018 at 4:48 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
>> > On Fri, 20 Apr 2018 22:08:27 +0200
>> > Mathieu Malaterre <malat@debian.org> wrote:
>> >
>> >> On Fri, Apr 20, 2018 at 12:41 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>> >> > On Fri, 20 Apr 2018 12:00:49 +0200
>> >> > Mathieu Malaterre <malat@debian.org> wrote:
>> >> >
>> >> >> On Fri, Apr 20, 2018 at 9:34 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
>> >> >> > This requires further changes to linker script to KEEP some tables
>> >> >> > and wildcard compiler generated sections into the right place. This
>> >> >> > includes pp32 modifications from Christophe Leroy.
>> >> >> >
>> >> >> > When compiling powernv_defconfig with this option:
>> >> >> >
>> >> >> > text data bss dec filename
>> >> >> > 11827621 4810490 1341080 17979191 vmlinux
>> >> >> > 11752437 4598858 1338776 17690071 vmlinux.dcde
>> >> >> >
>> >> >> > Resulting kernel is almost 400kB smaller (and still boots).
>> >> >> >
>> >> >> > [ppc32 numbers here]
>> >> >>
>> >> >> ^^^
>> >> >>
>> >> >> Do you want somebody else to provide those numbers ?
>> >> >
>> >> > If you have a booting kernel, yes some more numbers would be good.
>> >>
>> >> I've used /boot/config-4.15.0-2-powerpc from my current debian
>> >> package. Rebuild master with and without option, boot ok, load/unload
>> >> module ok.
>> >>
>> >> $ size nick/vmlinux.with*
>> >> text data bss dec hex filename
>> >> 7386425 2364370 1425432 11176227 aa8923 nick/vmlinux.with
>> >> 7461457 2475122 1428064 11364643 ad6923 nick/vmlinux.without
>> >>
>> >> This is not clear why with option the size of kernel is slightly bigger:
>> >>
>> >> $ du -sk nick/vmlinux.with*
>> >> 124488 nick/vmlinux.with
>> >> 124004 nick/vmlinux.without
>> >
>> > Not sure. readelf -S vmlinux may show something.
>> >
>> > To really get lots of detail, you can add to the top level Makefile:
>> >
>> > LDFLAGS_vmlinux += -M
>>
>> Here is what I did:
>>
>> $ git diff
>> diff --git a/Makefile b/Makefile
>> index 619a85ad716b..1a2e3d142a59 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -4,6 +4,7 @@ PATCHLEVEL = 17
>> SUBLEVEL = 0
>> EXTRAVERSION = -rc3
>> NAME = Fearless Coyote
>> +LDFLAGS_vmlinux += -M
>
> That'll get overwritten further down. Put it down with another line
> that starts with LDFLAGS_vmlinux +=
Sorry about that, I was not paying attention :(
Anyway I cannot make sense of the output with -M.
Here is a quick summary if needed (with option / without option).
$ ./scripts/bloat-o-meter nick/vmlinux.without nick/vmlinux.with | head
add/remove: 0/647 grow/shrink: 852/1846 up/down: 11276/-95033 (-83757)
Function old new delta
SiSInitPtr 2212 2600 +388
xmon_core.isra 7540 7900 +360
ata_attach_transport 840 1032 +192
via_pmu_interrupt 2828 3004 +176
matroxfb_init 3000 3156 +156
fbcon_scroll 3092 3248 +156
__do_adjtimex 1716 1868 +152
fbcon_event_notify 2044 2184 +140
$ ./scripts/bloat-o-meter nick/vmlinux.without nick/vmlinux.with | tail
aty_set_pll18818 540 - -540
sel_ib_pkey_sid 556 - -556
pci_dev_acs_enabled 608 - -608
aa_label_find_merge 752 - -752
drmem_update_dt 796 - -796
powerpc_macros 1176 - -1176
ima_restore_measurement_list 1224 - -1224
rtas_os_term_buf 2048 - -2048
vle_opcodes 8200 - -8200
Total: Before=9927171, After=9843414, chg -0.84%
> Thanks,
> Nick
^ permalink raw reply
* [PATCH] powerpc/64: Fix for "make PACA_IRQ_HARD_DIS track MSR[EE] closely"
From: Nicholas Piggin @ 2018-05-15 2:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
The patch "powerpc/64s: make PACA_IRQ_HARD_DIS track MSR[EE] closely"
needs an equivalent change to the 64/e interrupt handler, to set
PACA_IRQ_HARD_DIS when MSR[EE] gets cleared.
Also the original patch should be named powerpc/64: rather than 64s:.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/exceptions-64e.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 9b6e653e501a..9eab3ea480fa 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -956,6 +956,9 @@ kernel_dbg_exc:
rldicl r10,r11,48,1 /* clear MSR_EE */
rotldi r11,r10,16
mtspr SPRN_SRR1,r11
+ lbz r11,PACAIRQHAPPENED(r13)
+ ori r11,r11,PACA_IRQ_HARD_DIS
+ stb r11,PACAIRQHAPPENED(r13)
.endif
lwz r11,PACA_EXGEN+EX_CR(r13)
--
2.17.0
^ permalink raw reply related
* [RFC PATCH 0/5] Add FADump support on PowerNV platform
From: Hari Bathini @ 2018-05-15 4:58 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli, Michael Ellerman, Mahesh J Salgaonkar,
Vasant Hegde, linuxppc-dev, Stewart Smith
Firmware-Assisted Dump (FADump) is currently supported only on pseries
platform. This patch series adds support for powernv platform too.
The first two patches refactor the FADump code to make use of common
code across multiple platforms. The third patch adds basic FADump support
to powernv platform. The next patch processes state data provided by f/w
and adds core notes to core file. The last patch adds support to export
opalcore. This is to make debugging of failures in opal code easier.
The patch series is tested with a few workarounds in firmware and kernel
as the full and final firmware support is currently being worked on.
The below skiboot patch series adds the relevant OPAL changes:
http://patchwork.ozlabs.org/project/skiboot/list/?series=42576
---
Hari Bathini (5):
powerpc/fadump: move internal fadump code to a new file
pseries/fadump: move out platform specific support from generic code
powerpc/fadump: enable fadump support on powernv platform
powerpc/fadump: process architected register state data provided by firmware
powerpc/powernv: export /proc/opaldump for analysing opal crashes
arch/powerpc/Kconfig | 2
arch/powerpc/include/asm/fadump.h | 185 ----
arch/powerpc/include/asm/opal-api.h | 4
arch/powerpc/include/asm/opal.h | 1
arch/powerpc/kernel/Makefile | 2
arch/powerpc/kernel/fadump.c | 1111 +++++++++--------------
arch/powerpc/kernel/fadump_internal.c | 194 ++++
arch/powerpc/kernel/fadump_internal.h | 197 ++++
arch/powerpc/platforms/powernv/Makefile | 1
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
arch/powerpc/platforms/powernv/opalcore.c | 282 ++++++
arch/powerpc/platforms/powernv/opalcore.h | 28 +
arch/powerpc/platforms/powernv/powernv_fadump.c | 503 ++++++++++
arch/powerpc/platforms/powernv/powernv_fadump.h | 72 +
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/pseries_fadump.c | 532 +++++++++++
arch/powerpc/platforms/pseries/pseries_fadump.h | 96 ++
17 files changed, 2335 insertions(+), 877 deletions(-)
create mode 100644 arch/powerpc/kernel/fadump_internal.c
create mode 100644 arch/powerpc/kernel/fadump_internal.h
create mode 100644 arch/powerpc/platforms/powernv/opalcore.c
create mode 100644 arch/powerpc/platforms/powernv/opalcore.h
create mode 100644 arch/powerpc/platforms/powernv/powernv_fadump.c
create mode 100644 arch/powerpc/platforms/powernv/powernv_fadump.h
create mode 100644 arch/powerpc/platforms/pseries/pseries_fadump.c
create mode 100644 arch/powerpc/platforms/pseries/pseries_fadump.h
--
Signature
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox