On Wed, Feb 06, 2019 at 05:28:37PM +1100, Russell Currey wrote:
> Without restoring the IAMR after idle, execution prevention on POWER9
> with Radix MMU is overwritten and the kernel can freely execute userspace
> without
> faulting.
>
> This is necessary when returning from any stop state that
This adds test cases for the addc[.] instruction.
Signed-off-by: Sandipan Das
---
arch/powerpc/include/asm/ppc-opcode.h | 1 +
arch/powerpc/lib/test_emulate_step.c | 192 ++
2 files changed, 193 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h
This adds test cases for the add[.] instruction.
Signed-off-by: Sandipan Das
---
arch/powerpc/lib/test_emulate_step.c | 176 +++
1 file changed, 176 insertions(+)
diff --git a/arch/powerpc/lib/test_emulate_step.c
b/arch/powerpc/lib/test_emulate_step.c
index
This enhances the current selftest framework for validating
the in-kernel instruction emulation infrastructure by adding
support for compute type instructions i.e. integer ALU-based
instructions. Originally, this framework was limited to only
testing load and store instructions.
While most of the
This aims to extend the current test infrastructure for in-kernel
instruction emulation by adding support for validating basic integer
operations and will verify the GPRs, LR, XER and CR.
There can be multiple test cases for each instruction. Each test case
has to be provided with the initial
Le 20/02/2019 à 06:53, Masahiro Yamada a écrit :
It is fragile to rely on the compiler's optimization to avoid the
section mismatch. Some functions may not be necessarily inlined
when the compiler's inlining heuristic changes.
Add __init markers consistently.
As for prom_getprop() and
On Wed, 2019-02-20 at 01:14 +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
>
> > On 02/08/2019 12:34 PM, Michael Ellerman wrote:
> > > In commit 7820856a4fcd ("powerpc/mm/book3e/64: Remove unsupported
> > > 64Kpage size from 64bit booke") we dropped the 64K page size support
> > >
On Tue, Feb 19, 2019 at 02:21:04PM +1000, Nicholas Piggin wrote:
> Michael Ellerman's on February 8, 2019 11:04 am:
> > Nicholas Piggin writes:
> >> Russell Currey's on February 6, 2019 4:28 pm:
> >>> Without restoring the IAMR after idle, execution prevention on POWER9
> >>> with Radix MMU is
It is fragile to rely on the compiler's optimization to avoid the
section mismatch. Some functions may not be necessarily inlined
when the compiler's inlining heuristic changes.
Add __init markers consistently.
As for prom_getprop() and prom_getproplen(), they are marked as
'inline', so inlining
From: Ira Weiny
To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.
This patch does not change any functionality. New functionality will
follow in subsequent patches.
Some of the get_user_pages_fast() call sites were unchanged because
From: Ira Weiny
DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().
Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.
Signed-off-by: Ira Weiny
---
mm/gup.c | 24
From: Ira Weiny
In order to support more options in the GUP fast walk, change
the write parameter to flags throughout the call stack.
This patch does not change functionality and passes FOLL_WRITE
where write was previously used.
Signed-off-by: Ira Weiny
---
mm/gup.c | 52
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Ira Weiny
Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.
This patch does not change any functionality.
FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX is in
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
From: Ira Weiny
Resending these as I had only 1 minor comment which I believe we have covered
in this series. I was anticipating these going through the mm tree as they
depend on a cleanup patch there and the IB changes are very minor. But they
could just as well go through the IB tree.
NOTE:
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Using the hash MMU on P7+, the AMR is used for pkeys. It's important
that the host and guest never end up with each other's AMR value, since
this could disrupt operations and break things.
The AMR gets correctly restored on context switch, however before this
happens (i.e. in a program like
On 20/2/19 3:26 pm, Daniel Axtens wrote:
I needed the following diff to get this booting on a T4240RDB:
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 961f44eabb65..fbe9894d6305 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -3,6
Hi Andrew,
> kcov provides kernel coverage data that's useful for fuzzing tools like
> syzkaller.
>
> Wire up kcov support on powerpc. Disable kcov instrumentation on the same
> files where we currently disable gcov and UBSan instrumentation.
>
> Signed-off-by: Andrew Donnellan
> Acked-by:
-Original Message-
From: Lorenzo Pieralisi
Sent: 2019年2月19日 19:27
To: Xiaowei Bao
Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
shawn...@kernel.org; Leo Li ; kis...@ti.com; a...@arndb.de;
gre...@linuxfoundation.org; M.h. Lian ; Mingkai Hu
; Roy Zang ;
This makes the handling of machine check interrupts that occur inside
a guest simpler and more robust, with less done in assembler code and
in real mode.
Now, when a machine check occurs inside a guest, we always get the
machine check event struct and put a copy in the vcpu struct for the
vcpu
This adds an "in_guest" parameter to machine_check_print_event_info()
so that we can avoid trying to translate guest NIP values into
symbolic form using the host kernel's symbol table.
Signed-off-by: Paul Mackerras
---
arch/powerpc/include/asm/mce.h| 2 +-
arch/powerpc/kernel/mce.c
On Tue, Feb 19, 2019 at 02:13:51PM +1000, Nicholas Piggin wrote:
> Paul Mackerras's on February 18, 2019 9:06 am:
> > On Sat, Oct 13, 2018 at 10:04:09PM +1000, Nicholas Piggin wrote:
> >> Reimplement Book3S idle code in C, moving POWER7/8/9 implementation
> >> speific HV idle code to the powernv
Sandipan Das writes:
> This adds emulation support for the following integer instructions:
> * Multiply-Add High Doubleword (maddhd)
> * Multiply-Add High Doubleword Unsigned (maddhdu)
> * Multiply-Add Low Doubleword (maddld)
This doesn't build with old binutils.
{standard
Sandipan Das writes:
> This adds emulation support for the following integer instructions:
> * Deliver A Random Number (darn)
This doesn't build with old binutils. We need to support old binutils.
{standard input}:4343: Error: Unrecognized opcode: `darn'
You need to use PPC_DARN().
On Mon, Feb 11, 2019 at 03:38:59PM +0100, Petr Mladek wrote:
> On Mon 2019-02-11 13:50:35, Andrea Parri wrote:
> > Hi Michael,
> >
> >
> > On Thu, Feb 07, 2019 at 11:46:29PM +1100, Michael Ellerman wrote:
> > > Arch code can set a "dump stack arch description string" which is
> > > displayed
From: Colin King
Date: Tue, 19 Feb 2019 14:21:20 +
> From: Colin Ian King
>
> Passing the struct ptp_clock_info caps by parameter is passing over 130 bytes
> of data by value on the stack. Optimize this by passing it by reference
> instead.
> Also shinks the object code size:
>
> Before:
On Tue, 19 Feb 2019 07:17:59 PST (-0800), Christoph Hellwig wrote:
On Fri, Feb 15, 2019 at 06:32:07PM +0900, Masahiro Yamada wrote:
On Thu, Feb 14, 2019 at 2:40 AM Christoph Hellwig wrote:
>
> HAVE_KPROBES is defined genericly in arch/Kconfig and architectures
> should just select it if
On Wed, 13 Feb 2019 11:18:21 +1100
Alexey Kardashevskiy wrote:
> On 13/02/2019 07:52, Alex Williamson wrote:
> > On Mon, 11 Feb 2019 18:49:17 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group from
> >> a container, we need to
> -Original Message-
> From: Colin King
> Sent: Tuesday, February 19, 2019 8:05 AM
> To: Roy Pledge ; Leo Li ;
> linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH][next] soc: fsl:
On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote:
> Balbir Singh writes:
> > Fair enough, my point was that the compiler can help out. I'll see what
> > -Wconversion finds on my local build :)
>
> I get about 43MB of warnings here :)
Yes, -Wconversion complains about a lot of
On 02/19/2019 07:46 AM, Michael Bringmann wrote:
> powerpc/pseries: Fix dn reference error in dlpar_cpu_remove_by_index()
>
> A reference to the device node of the CPU to be removed is released
> upon successful removal of the associated CPU device. If the call
> to remove the CPU device fails,
On Mon, Feb 18, 2019 at 03:25:00PM +, Viorel Suman wrote:
> According to RM SPDIF STC SYSCLK_DF field is 9-bit wide, values
> being in 0..511 range. Use a proper type to handle sysclk_df.
>
> Signed-off-by: Viorel Suman
Acked-by: Nicolin Chen
> ---
> sound/soc/fsl/fsl_spdif.c | 10
On Mon, Feb 18, 2019 at 02:12:17PM +, Viorel Suman wrote:
> According to RM SPDIF TXCLK_DF mask is 7-bit wide.
>
> Signed-off-by: Viorel Suman
Acked-by: Nicolin Chen
> ---
> sound/soc/fsl/fsl_spdif.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Le 18/02/2019 à 10:27, Michael Ellerman a écrit :
Christophe Leroy writes:
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index e0637730a8e7..dba2c1038363 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@
From: Daniel Axtens
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 to 0x8000 0600 .
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the
From: Daniel Axtens
Currently, shadow addresses are always addr >> shift + offset.
However, for powerpc, the virtual address space is fragmented in
ways that make this simple scheme impractical.
Allow architectures to override:
- kasan_shadow_to_mem
- kasan_mem_to_shadow
- addr_has_shadow
Hi Daniel,
Find here your series rebased on my v6. No test done, not even compiled.
Christophe
Christophe Leroy (3):
kasan: do not open-code addr_has_shadow
kasan: allow architectures to manage the memory-to-shadow mapping
powerpc: KASAN for 64bit Book3E
arch/powerpc/Kconfig
From: Daniel Axtens
We have a couple of places checking for the existence of a shadow
mapping for an address by open-coding the inverse of the check in
addr_has_shadow.
Replace the open-coded versions with the helper. This will be
needed in future to allow architectures to override the layout
The challenge with book3s/32 is that the hash table management
has to be set up before being able to use KASAN.
This patch adds a kasan_arch_is_ready() helper to defer
the activation of KASAN until paging is ready.
This limits KASAN to KASAN_MINIMAL mode. The downside of it
is that the 603,
From: Daniel Axtens
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initalised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.
My attempts to move
This patch adds KASAN support for PPC32.
The KASAN shadow area is located between the vmalloc area and the
fixmap area.
KASAN_SHADOW_OFFSET is calculated in asm/kasan.h and extracted
by Makefile prepare rule via asm-offsets.h
For modules, the shadow area is allocated at module_alloc().
Note
CONFIG_KASAN implements wrappers for memcpy() memmove() and memset()
Those wrappers are doing the verification then call respectively
__memcpy() __memmove() and __memset(). The arches are therefore
expected to rename their optimised functions that way.
For files on which KASAN is inhibited,
In kernel/cputable.c, explicitly use memcpy() in order
to allow GCC to replace it with __memcpy() when KASAN is
selected.
Since commit 400c47d81ca38 ("powerpc32: memset: only use dcbz once cache is
enabled"), memset() can be used before activation of the cache,
so no need to use memset_io() for
In preparation of KASAN, move early_init() into a separate
file in order to allow deactivation of KASAN for that function.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/early_32.c | 36
This serie adds KASAN support to powerpc/32
Tested on nohash/32 (8xx) and book3s/32 (mpc832x ie 603).
Boot tested on qemu mac99
Changes in v6:
- Fixed oops on module loading (due to access to RO shadow zero area).
- Added support for hash book3s/32, thanks to Daniel's patch to differ KASAN
powerpc/pseries: Fix dn reference error in dlpar_cpu_remove_by_index()
A reference to the device node of the CPU to be removed is released
upon successful removal of the associated CPU device. If the call
to remove the CPU device fails, dlpar_cpu_remove_by_index() still
frees the reference and
On Fri, Feb 15, 2019 at 06:32:07PM +0900, Masahiro Yamada wrote:
> On Thu, Feb 14, 2019 at 2:40 AM Christoph Hellwig wrote:
> >
> > HAVE_KPROBES is defined genericly in arch/Kconfig and architectures
> > should just select it if supported.
> >
> > Signed-off-by: Christoph Hellwig
>
> Do you
Looks fine,
Reviewed-by: Christoph Hellwig
From: Colin Ian King
Passing the struct ptp_clock_info caps by parameter is passing over 130 bytes
of data by value on the stack. Optimize this by passing it by reference instead.
Also shinks the object code size:
Before:
textdata bss dec hex filename
125962160 64
Christophe Leroy writes:
> On 02/08/2019 12:34 PM, Michael Ellerman wrote:
>> In commit 7820856a4fcd ("powerpc/mm/book3e/64: Remove unsupported
>> 64Kpage size from 64bit booke") we dropped the 64K page size support
>> from the 64-bit nohash (Book3E) code.
>>
>> But we didn't update the
From: Colin Ian King
Currently the error check for a null reg leaks a struct qbman
that was allocated earlier. Fix this by kfree'ing p on the error exit
path.
Signed-off-by: Colin Ian King
---
drivers/soc/fsl/dpio/qbman-portal.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote:
> Balbir Singh writes:
> > On Sun, Feb 17, 2019 at 07:34:20PM +1100, Michael Ellerman wrote:
> >> Balbir Singh writes:
> >> > On Sat, Feb 16, 2019 at 08:22:12AM -0600, Segher Boessenkool wrote:
> >> >> On Sat, Feb 16, 2019 at
The patch
SoC: imx-sgtl5000: add missing put_device()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
On Tue, Jan 22, 2019 at 02:33:27PM +0800, Xiaowei Bao wrote:
> Add the PCIe EP mode support for layerscape platform.
>
> Signed-off-by: Xiaowei Bao
> Reviewed-by: Minghuan Lian
> Reviewed-by: Zhiqiang Hou
> Reviewed-by: Kishon Vijay Abraham I
> ---
> depends on:
"Aneesh Kumar K.V" writes:
> After we ALIGN up the address we need to make sure we didn't overflow
> and resulted in zero address. In that case, we need to make sure that
> the returned address is greater than mmap_min_addr.
>
> Also when doing top-down search the low_limit is not PAGE_SIZE but
Dear Linux folks,
On a the IBM S822LC (8335-GTA) with Ubuntu 18.10, and Linux 5.0-rc5+
accessing `/sys/kernel/debug/kmemleak` takes a long time. According to
strace it takes three seconds.
```
$ sudo strace -tt -T cat /sys/kernel/debug/kmemleak
10:35:49.861641 execve("/bin/cat", ["cat",
On 19/02/2019 04:55, Michael Ellerman wrote:
> Mark Cave-Ayland writes:
>> On 11/02/2019 00:30, Benjamin Herrenschmidt wrote:
>>
>>> On Fri, 2019-02-08 at 14:51 +, Mark Cave-Ayland wrote:
Indeed, but there are still some questions to be asked here:
1) Why were these bits
59 matches
Mail list logo
