Re: [PATCH bpf 5/6] tools: bpftool: resolve calls without using imm field

Hi Jakub, On 05/18/2018 12:21 AM, Jakub Kicinski wrote: > On Thu, 17 May 2018 12:05:47 +0530, Sandipan Das wrote: >> Currently, we resolve the callee's address for a JITed function >> call by using the imm field of the call instruction as an offset >> from __bpf_call_base. If bpf_jit_kallsyms is

Re: [PATCH 0/3] Add support to disable sensor groups in P9

On 05/17/2018 06:08 PM, Guenter Roeck wrote: > On 05/16/2018 11:10 PM, Shilpasri G Bhat wrote: >> >> >> On 05/15/2018 08:32 PM, Guenter Roeck wrote: >>> On Thu, Mar 22, 2018 at 04:24:32PM +0530, Shilpasri G Bhat wrote: This patch series adds support to enable/disable OCC based

[PATCH] powepc: Clear PCR on boot

Clear the PCR on boot to ensure we are not running in a compat mode. We've seen this cause problems when a crash (and kdump) occurs while running compat mode guests. The kdump kernel then runs with the PCR set and causes problems. The symptom in the kdump kernel (also seen in petitboot after

[PATCH RESEND] powerpc/lib: Fix "integer constant is too large" build failure

My powerpc-linux-gnu-gcc v4.4.5 compiler can't build a 32-bit kernel any more: arch/powerpc/lib/sstep.c: In function 'do_popcnt': arch/powerpc/lib/sstep.c:1068: error: integer constant is too large for 'long' type arch/powerpc/lib/sstep.c:1069: error: integer constant is too large for 'long'

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Thu, May 17, 2018, at 11:28 PM, Mathieu Desnoyers wrote: > - On May 16, 2018, at 9:19 PM, Boqun Feng boqun.f...@gmail.com wrote: > > > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > >> - On May 16, 2018, at 12:18 PM, Peter Zijlstra pet...@infradead.org > >>

Re: [PATCH] powerpc: Ensure gcc doesn't move around cache flushing in __patch_instruction

On Fri, May 18, 2018 at 08:30:27AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2018-05-17 at 14:23 -0500, Segher Boessenkool wrote: > > On Thu, May 17, 2018 at 01:06:10PM +1000, Benjamin Herrenschmidt wrote: > > > The current asm statement in __patch_instruction() for the cache flushes > > >

[RFC v3 4/4] powerpc/hotplug/drcinfo: Improve code for ibm,drc-info device processing

This patch extends the use of a common parse function for the ibm,drc-info property that can be modified by a callback function to the hotplug device processing. Candidate code is replaced by a call to the parser including a pointer to a local context-specific functions, and local data. In

[RFC v3 3/4] powerpc/hotplug/drcinfo: Fix hot-add CPU issues

This patch applies a common parse function for the ibm,drc-info property that can be modified by a callback function to the hot-add CPU code. Candidate code is replaced by a call to the parser including a pointer to a local context-specific functions, and local data. In addition, a bug in the

[RFC v3 2/4] powerpc/hotplug/drcinfo: Provide common parser for ibm,drc-info

This patch provides a common parse function for the ibm,drc-info property that can be modified by a callback function. The caller provides a pointer to the function and a pointer to their unique data, and the parser provides the current lmb set from the struct. The callback function may return

[RFC v3 1/4] powerpc/hotplug/drcinfo: Fix bugs parsing ibm,drc-info structs

[Replace/withdraw previous patch submission to ensure that testing of related patches on similar hardware progresses together.] This patch fixes a memory parsing bug when using of_prop_next_u32 calls at the start of a structure. Depending upon the value of "cur" memory pointer argument to

[RFC v3 0/4] powerpc/drcinfo: Fix bugs 'ibm,drc-info' property

This patch set corrects some errors and omissions in the previous set of patches adding support for the "ibm,drc-info" property to powerpc systems. Unfortunately, some errors in the previous patch set break things in some of the DLPAR operations. In particular when attempting to hot-add a new

Re: [PATCH] powerpc: Ensure gcc doesn't move around cache flushing in __patch_instruction

On Thu, 2018-05-17 at 14:23 -0500, Segher Boessenkool wrote: > Hi! > > On Thu, May 17, 2018 at 01:06:10PM +1000, Benjamin Herrenschmidt wrote: > > The current asm statement in __patch_instruction() for the cache flushes > > doesn't have a "volatile" statement and no memory clobber. That means > >

[RFC v4 3/3] powerpc migration/memory: Associativity & memory updates

powerpc migration/memory: This patch adds more recognition for changes to the associativity of memory blocks described by the device-tree properties and updates local and general kernel data structures to reflect those changes. These differences may include: * Evaluating 'ibm,dynamic-memory'

[RFC v4 2/3] powerpc migration/cpu: Associativity & cpu changes

powerpc migration/cpu: Now apply changes to the associativity of cpus for the topology of LPARS in Post Migration events. Recognize more changes to the associativity of memory blocks described by the 'cpu' properties when processing the topology of LPARS in Post Migration events. Previous

[RFC v4 1/3] powerpc migration/drmem: Modify DRMEM code to export more features

powerpc migration/drmem: Export many of the functions of DRMEM to parse "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug operations and for Post Migration events. Also modify the DRMEM initialization code to allow it to, * Be called after system initialization * Provide a separate

[RFC v4 0/3] powerpc/hotplug: Fix affinity assoc for LPAR migration

The migration of LPARs across Power systems affects many attributes including that of the associativity of memory blocks and CPUs. The patches in this set execute when a system is coming up fresh upon a migration target. They are intended to, * Recognize changes to the associativity of memory

Re: [PATCH v17 0/9] Address error and recovery for AER and DPC

[+cc Russell, Sam, Bryant, linuxppc-dev, Sebastian, linux-s390] Sorry, I should have pulled in these new CC's earlier because ppc and s390 both have PCI error handling similar to what Oza is changing here. The basic issue is that the new PCIe DPC (Downstream Port Containment, see PCIe r4.0, sec

Re: [PATCH bpf 5/6] tools: bpftool: resolve calls without using imm field

On Thu, 17 May 2018 12:05:47 +0530, Sandipan Das wrote: > Currently, we resolve the callee's address for a JITed function > call by using the imm field of the call instruction as an offset > from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further > use this address to get the callee's

Re: [PATCH] powerpc: Ensure gcc doesn't move around cache flushing in __patch_instruction

Hi! On Thu, May 17, 2018 at 01:06:10PM +1000, Benjamin Herrenschmidt wrote: > The current asm statement in __patch_instruction() for the cache flushes > doesn't have a "volatile" statement and no memory clobber. That means > gcc can potentially move it around (or move the store done by put_user >

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

On 05/17/2018 10:19 AM, Matthew Wilcox wrote: > On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote: >>> +If the speculative page fault fails because of a concurrency is >> >> because a concurrency is > > While one can use concurrency as a

Re: [PATCH v4 4/4] powerpc/kbuild: move -mprofile-kernel check to Kconfig

-language/20180517-224044 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: powerpc-allmodconfig compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote: > > +If the speculative page fault fails because of a concurrency is > >because a concurrency is While one can use concurrency as a noun, it sounds archaic to me. I'd rather:

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

Hi, On 05/17/2018 04:06 AM, Laurent Dufour wrote: > This configuration variable will be used to build the code needed to > handle speculative page fault. > > By default it is turned off, and activated depending on architecture > support, ARCH_HAS_PTE_SPECIAL, SMP and MMU. > > The architecture

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

- On May 16, 2018, at 9:19 PM, Boqun Feng boqun.f...@gmail.com wrote: > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: >> - On May 16, 2018, at 12:18 PM, Peter Zijlstra pet...@infradead.org >> wrote: >> >> > On Mon, Apr 30, 2018 at 06:44:26PM -0400, Mathieu Desnoyers

Failure to allocate HTAB for guest - CMA allocation failures?

Hi, I have reports from a user who is experiencing intermittent issues with qemu being unable to allocate memory for the guest HPT. We see: libvirtError: internal error: process exited while connecting to monitor: Unexpected error in spapr_alloc_htab() at

Re: [2/2] powerpc/powernv: Fix NVRAM sleep in invalid context when crashing

On Mon, 2018-05-14 at 15:59:47 UTC, Nicholas Piggin wrote: > 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: sta...@vger.kernel.org # v3.2 > Fixes: 3b8070335f

Re: [v4, 1/2] cxl: Set the PBCQ Tunnel BAR register when enabling capi mode

On Mon, 2018-05-14 at 08:27:35 UTC, Philippe Bergheaud wrote: > 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

Re: [PATCH] Revert "powerpc/64: Fix checksum folding in csum_add()"

On Tue, Apr 10, 2018 at 08:34:37AM +0200, Christophe Leroy wrote: > This reverts commit 6ad966d7303b70165228dba1ee8da1a05c10eefe. > > That commit was pointless, because csum_add() sums two 32 bits > values, so the sum is 0x1fffe at the maximum. > And then when adding upper part (1) and lower

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

On Thu, May 17, 2018 at 03:27:37PM +0200, Christophe LEROY wrote: > Le 17/05/2018 à 15:15, Segher Boessenkool a écrit : > >>I guess we've been enabling this for all 32-bit targets for ever so it > >>must be a reasonable option. > > > >On 603, load multiple (and string) are one cycle slower than

Re: [PATCH] powerpc/lib: Remove .balign inside string functions for PPC32

Le 17/05/2018 à 15:46, Michael Ellerman a écrit : Nicholas Piggin writes: On Thu, 17 May 2018 12:04:13 +0200 (CEST) Christophe Leroy wrote: commit 87a156fb18fe1 ("Align hot loops of some string functions") degraded the performance of string

Re: [PATCH v4 3/4] powerpc/64: add 32 bytes prechecking before using VMX optimization on memcmp()

wei.guo.si...@gmail.com writes: > From: Simon Guo > > This patch is based on the previous VMX patch on memcmp(). > > To optimize ppc64 memcmp() with VMX instruction, we need to think about > the VMX penalty brought with: If kernel uses VMX instruction, it needs > to

Re: [PATCH 2/2] selftests/powerpc: Add core file test for Protection Key registers

Thiago Jung Bauermann writes: > This test verifies that the AMR, IAMR and UAMOR are being written to a > process' core file. > > Signed-off-by: Thiago Jung Bauermann > --- > tools/testing/selftests/powerpc/ptrace/Makefile| 5 +- >

Re: [PATCH 1/2] selftests/powerpc: Add ptrace tests for Protection Key registers

Thiago Jung Bauermann writes: > This test exercises read and write access to the AMR, IAMR and UAMOR. > > Signed-off-by: Thiago Jung Bauermann > --- > tools/testing/selftests/powerpc/include/reg.h | 1 + >

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On Thu, May 17, 2018 at 12:49:58PM +0200, Christophe Leroy wrote: > In my 8xx configuration, I get 208 calls to memcmp() > Within those 208 calls, about half of them have constant sizes, > 46 have a size of 8, 17 have a size of 16, only a few have a > size over 16. Other fixed sizes are mostly 4,

Re: [PATCH] powerpc/lib: Remove .balign inside string functions for PPC32

Nicholas Piggin writes: > On Thu, 17 May 2018 12:04:13 +0200 (CEST) > Christophe Leroy wrote: > >> commit 87a156fb18fe1 ("Align hot loops of some string functions") >> degraded the performance of string functions by adding useless >> nops >> >> A

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On Thu, 2018-05-17 at 15:21 +0200, Christophe LEROY wrote: > > > +static inline int __memcmp8(const void *p, const void *q, int off) > > > +{ > > > + s64 tmp = be64_to_cpu(*(u64*)(p + off)) - be64_to_cpu(*(u64*)(q + > > > off)); > > > > I always assumed 64bits unaligned access would

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

On Thu, 2018-05-17 at 22:10 +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs > > in order to use multiple word instructions in functions entry/exit > > True, though that could be a lot simpler

Re: [PATCH v6] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()

On Thu, 17 May 2018 12:59:29 +0200 (CEST) Christophe Leroy wrote: > Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every > userspace instruction miss") has shown that limiting the read of > faulting instruction to likely cases improves performance. > > This

Re: [PATCH v2 1/5] powerpc/lib: move PPC32 specific functions out of string.S

On Thu, May 17, 2018 at 12:49:50PM +0200, Christophe Leroy wrote: > In preparation of optimisation patches, move PPC32 specific > memcmp() and __clear_user() into string_32.S > --- /dev/null > +++ b/arch/powerpc/lib/string_32.S > @@ -0,0 +1,74 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +/* >

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

Le 17/05/2018 à 15:15, Segher Boessenkool a écrit : On Thu, May 17, 2018 at 10:10:21PM +1000, Michael Ellerman wrote: Christophe Leroy writes: arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs in order to use multiple word instructions in functions

Re: [PATCH] powerpc/lib: Remove .balign inside string functions for PPC32

On Thu, 17 May 2018 12:04:13 +0200 (CEST) Christophe Leroy wrote: > commit 87a156fb18fe1 ("Align hot loops of some string functions") > degraded the performance of string functions by adding useless > nops > > A simple benchmark on an 8xx calling 10x a memchr() that

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

Le 17/05/2018 à 15:03, Mathieu Malaterre a écrit : On Thu, May 17, 2018 at 12:49 PM, Christophe Leroy wrote: In my 8xx configuration, I get 208 calls to memcmp() Within those 208 calls, about half of them have constant sizes, 46 have a size of 8, 17 have a size of

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

On Thu, May 17, 2018 at 10:10:21PM +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs > > in order to use multiple word instructions in functions entry/exit > > True, though that could be a lot

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On Thu, May 17, 2018 at 12:49 PM, Christophe Leroy wrote: > In my 8xx configuration, I get 208 calls to memcmp() > Within those 208 calls, about half of them have constant sizes, > 46 have a size of 8, 17 have a size of 16, only a few have a > size over 16. Other fixed

Re: [PATCH 0/3] Add support to disable sensor groups in P9

On 05/16/2018 11:10 PM, Shilpasri G Bhat wrote: On 05/15/2018 08:32 PM, Guenter Roeck wrote: On Thu, Mar 22, 2018 at 04:24:32PM +0530, Shilpasri G Bhat wrote: This patch series adds support to enable/disable OCC based inband-sensor groups at runtime. The environmental sensor groups are

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

Christophe Leroy writes: > arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs > in order to use multiple word instructions in functions entry/exit True, though that could be a lot simpler because the MULTIPLEWORD value is only used for PPC32, which is always

[PATCH v11 24/26] x86/mm: add speculative pagefault handling

From: Peter Zijlstra Try a speculative fault before acquiring mmap_sem, if it returns with VM_FAULT_RETRY continue with the mmap_sem acquisition and do the traditional fault. Signed-off-by: Peter Zijlstra (Intel) [Clearing of FAULT_FLAG_ALLOW_RETRY

[PATCH v11 26/26] arm64/mm: add speculative page fault

From: Mahendran Ganesh This patch enables the speculative page fault on the arm64 architecture. I completed spf porting in 4.9. From the test result, we can see app launching time improved by about 10% in average. For the apps which have more than 50 threads, 15% or

[PATCH v11 25/26] powerpc/mm: add speculative page fault

This patch enable the speculative page fault on the PowerPC architecture. This will try a speculative page fault without holding the mmap_sem, if it returns with VM_FAULT_RETRY, the mmap_sem is acquired and the traditional page fault processing is done. The speculative path is only tried for

[PATCH v11 13/26] mm: cache some VMA fields in the vm_fault structure

When handling speculative page fault, the vma->vm_flags and vma->vm_page_prot fields are read once the page table lock is released. So there is no more guarantee that these fields would not change in our back. They will be saved in the vm_fault structure before the VMA is checked for changes. In

[PATCH v11 22/26] perf tools: add support for the SPF perf event

Add support for the new speculative faults event. Acked-by: David Rientjes Signed-off-by: Laurent Dufour --- tools/include/uapi/linux/perf_event.h | 1 + tools/perf/util/evsel.c | 1 + tools/perf/util/parse-events.c| 4

[PATCH v11 23/26] mm: add speculative page fault vmstats

Add speculative_pgfault vmstat counter to count successful speculative page fault handling. Also fixing a minor typo in include/linux/vm_event_item.h. Signed-off-by: Laurent Dufour --- include/linux/vm_event_item.h | 3 +++ mm/memory.c | 3 +++

[PATCH v11 21/26] perf: add a speculative page fault sw event

Add a new software event to count succeeded speculative page faults. Acked-by: David Rientjes Signed-off-by: Laurent Dufour --- include/uapi/linux/perf_event.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/perf_event.h

[PATCH v11 20/26] mm: adding speculative page fault failure trace events

This patch a set of new trace events to collect the speculative page fault event failures. Signed-off-by: Laurent Dufour --- include/trace/events/pagefault.h | 80 mm/memory.c | 57

[PATCH v11 19/26] mm: provide speculative fault infrastructure

From: Peter Zijlstra Provide infrastructure to do a speculative fault (not holding mmap_sem). The not holding of mmap_sem means we can race against VMA change/removal and page-table destruction. We use the SRCU VMA freeing to keep the VMA around. We use the VMA seqcount to

[PATCH v11 18/26] mm: protect mm_rb tree with a rwlock

This change is inspired by the Peter's proposal patch [1] which was protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in that particular case, and it is introducing major performance degradation due to excessive scheduling operations. To allow access to the mm_rb tree without

[PATCH v11 17/26] mm: introduce __page_add_new_anon_rmap()

When dealing with speculative page fault handler, we may race with VMA being split or merged. In this case the vma->vm_start and vm->vm_end fields may not match the address the page fault is occurring. This can only happens when the VMA is split but in that case, the anon_vma pointer of the new

[PATCH v11 16/26] mm: introduce __vm_normal_page()

When dealing with the speculative fault path we should use the VMA's field cached value stored in the vm_fault structure. Currently vm_normal_page() is using the pointer to the VMA to fetch the vm_flags value. This patch provides a new __vm_normal_page() which is receiving the vm_flags flags

[PATCH v11 15/26] mm: introduce __lru_cache_add_active_or_unevictable

The speculative page fault handler which is run without holding the mmap_sem is calling lru_cache_add_active_or_unevictable() but the vm_flags is not guaranteed to remain constant. Introducing __lru_cache_add_active_or_unevictable() which has the vma flags value parameter instead of the vma

[PATCH v11 14/26] mm/migrate: Pass vm_fault pointer to migrate_misplaced_page()

migrate_misplaced_page() is only called during the page fault handling so it's better to pass the pointer to the struct vm_fault instead of the vma. This way during the speculative page fault path the saved vma->vm_flags could be used. Acked-by: David Rientjes

[PATCH v11 12/26] mm: protect SPF handler against anon_vma changes

The speculative page fault handler must be protected against anon_vma changes. This is because page_add_new_anon_rmap() is called during the speculative path. In addition, don't try speculative page fault if the VMA don't have an anon_vma structure allocated because its allocation should be

[PATCH v11 11/26] mm: protect mremap() against SPF hanlder

If a thread is remapping an area while another one is faulting on the destination area, the SPF handler may fetch the vma from the RB tree before the pte has been moved by the other thread. This means that the moved ptes will overwrite those create by the page fault handler leading to page leaked.

[PATCH v11 10/26] mm: protect VMA modifications using VMA sequence count

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() -

[PATCH v11 09/26] mm: VMA sequence count

From: Peter Zijlstra Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence counts such that we can easily test if a VMA is changed. The calls to vm_write_begin/end() in unmap_page_range() are used to detect when a VMA is being unmap and thus that new page

[PATCH v11 08/26] mm: introduce INIT_VMA()

Some VMA struct fields need to be initialized once the VMA structure is allocated. Currently this only concerns anon_vma_chain field but some other will be added to support the speculative page fault. Instead of spreading the initialization calls all over the code, let's introduce a dedicated

[PATCH v11 07/26] mm: make pte_unmap_same compatible with SPF

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

[PATCH v11 06/26] mm: introduce pte_spinlock for FAULT_FLAG_SPECULATIVE

When handling page fault without holding the mmap_sem the fetch of the pte lock pointer and the locking will have to be done while ensuring that the VMA is not touched in our back. So move the fetch and locking operations in a dedicated function. Signed-off-by: Laurent Dufour

[PATCH v11 05/26] mm: prepare for FAULT_FLAG_SPECULATIVE

From: Peter Zijlstra When speculating faults (without holding mmap_sem) we need to validate that the vma against which we loaded pages is still valid when we're ready to install the new PTE. Therefore, replace the pte_offset_map_lock() calls that (re)take the PTL with

[PATCH v11 03/26] powerpc/mm: set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for BOOK3S_64. This enables the Speculative Page Fault handler. Support is only provide for BOOK3S_64 currently because: - require CONFIG_PPC_STD_MMU because checks done in set_access_flags_filter() - require BOOK3S because we can't support for

[PATCH v11 04/26] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

From: Mahendran Ganesh Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This enables Speculative Page Fault handler. Signed-off-by: Ganesh Mahendran --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v11 02/26] x86/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT

Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT which turns on the Speculative Page Fault handler when building for 64bit. Cc: Thomas Gleixner Signed-off-by: Laurent Dufour --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

This configuration variable will be used to build the code needed to handle speculative page fault. By default it is turned off, and activated depending on architecture support, ARCH_HAS_PTE_SPECIAL, SMP and MMU. The architecture support is needed since the speculative page fault handler is

[PATCH v11 00/26] Speculative page faults

This is a port on kernel 4.17 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore [1]. The idea is to try to handle user space page faults without holding the mmap_sem. This should allow better concurrency for massively threaded process since the page fault

[PATCH v6] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()

Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every userspace instruction miss") has shown that limiting the read of faulting instruction to likely cases improves performance. This patch goes further into this direction by limiting the read of the faulting instruction to the only

[PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

In my 8xx configuration, I get 208 calls to memcmp() Within those 208 calls, about half of them have constant sizes, 46 have a size of 8, 17 have a size of 16, only a few have a size over 16. Other fixed sizes are mostly 4, 6 and 10. This patch inlines calls to memcmp() when size is constant and

[PATCH v2 4/5] powerpc/lib: inline string functions NUL size verification

Many calls to memcmp(), strncmp(), strncpy() and memchr() are done with constant size. This patch gives GCC a chance to optimise out the NUL size verification. This is only done when CONFIG_FORTIFY_SOURCE is not set, because when CONFIG_FORTIFY_SOURCE is set, other inline versions of the

[PATCH v2 3/5] powerpc/lib: optimise PPC32 memcmp

At the time being, memcmp() compares two chunks of memory byte per byte. This patch optimises the comparison by comparing word by word. A small benchmark performed on an 8xx comparing two chuncks of 512 bytes performed 10 times gives: Before : 5852274 TB ticks After: 1488638 TB ticks

[PATCH v2 2/5] powerpc/lib: optimise 32 bits __clear_user()

Rewrite clear_user() on the same principle as memset(0), making use of dcbz to clear complete cache lines. This code is a copy/paste of memset(), with some modifications in order to retrieve remaining number of bytes to be cleared, as it needs to be returned in case of error. On a MPC885,

[PATCH v2 1/5] powerpc/lib: move PPC32 specific functions out of string.S

In preparation of optimisation patches, move PPC32 specific memcmp() and __clear_user() into string_32.S Signed-off-by: Christophe Leroy --- arch/powerpc/lib/Makefile| 5 +-- arch/powerpc/lib/string.S| 61

[PATCH v2 0/5] powerpc/lib: Optimisation of string functions (mainly for PPC32)

This serie intend to optimise string functions for PPC32 in the same spirit as already done on PPC64. The first patch moves PPC32 specific functions from string.S into a dedicated file named string_32.S The second patch rewrites __clear_user() by using dcbz intruction The third patch rewrites

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/16/2018 10:35 PM, Ram Pai wrote: So let me see if I understand the overall idea. Application can allocate new keys through a new syscall sys_pkey_alloc_1(flags, init_val, sig_init_val) 'sig_init_val' is the permission-state of the key in signal context. I would keep the existing system

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/16/2018 11:07 PM, Ram Pai wrote: what would change the key-permission-values enforced in signal-handler context? Or can it never be changed, ones set through sys_pkey_alloc()? The access rights can only be set by pkey_alloc and are unchanged after that (so we do not have to discuss

[PATCH] powerpc/lib: Remove .balign inside string functions for PPC32

commit 87a156fb18fe1 ("Align hot loops of some string functions") degraded the performance of string functions by adding useless nops A simple benchmark on an 8xx calling 10x a memchr() that matches the first byte runs in 41668 TB ticks before this patch and in 35986 TB ticks after this

Patch "futex: Remove duplicated code and fix undefined behaviour" has been added to the 4.9-stable tree

This is a note to let you know that I've just added the patch titled futex: Remove duplicated code and fix undefined behaviour to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

Patch "futex: Remove duplicated code and fix undefined behaviour" has been added to the 4.4-stable tree

This is a note to let you know that I've just added the patch titled futex: Remove duplicated code and fix undefined behaviour to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Thu, May 17, 2018 at 09:19:49AM +0800, Boqun Feng wrote: > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > > and that x86 calls it from syscall_return_slowpath() (which AFAIU is > > now used in the fast-path since KPTI), I wonder where we should call > > So we actually

[PATCH v3] KVM: PPC: Book3S HV: lockless tlbie for HPT hcalls

tlbies to an LPAR do not have to be serialised since POWER4/PPC970, after which the MMU_FTR_LOCKLESS_TLBIE feature was introduced to avoid tlbie locking. Since commit c17b98cf6028 ("KVM: PPC: Book3S HV: Remove code for PPC970 processors"), KVM no longer supports processors that do not have this

[PATCH bpf 0/6] bpf: enhancements for multi-function programs

This patch series introduces the following: [1] Support for bpf-to-bpf function calls in the powerpc64 JIT compiler. [2] Provide a way for resolving function calls because of the way JITed images are allocated in powerpc64. [3] Fix to get JITed instruction dumps for multi-function programs

[PATCH bpf 4/6] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the addresses of the kernel symbols corresponding to each function in a JITed program. Signed-off-by: Sandipan Das --- tools/include/uapi/linux/bpf.h | 2 ++

[PATCH bpf 2/6] bpf: powerpc64: add JIT support for multi-function programs

This adds support for bpf-to-bpf function calls in the powerpc64 JIT compiler. The JIT compiler converts the bpf call instructions to native branch instructions. After a round of the usual passes, the start addresses of the JITed images for the callee functions are known. Finally, to fixup the

[PATCH bpf 6/6] bpf: fix JITed dump for multi-function programs via syscall

Currently, for multi-function programs, we cannot get the JITed instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD command. Because of this, userspace tools such as bpftool fail to identify a multi-function program as being JITed or not. With the JIT enabled and the test program

[PATCH bpf 5/6] tools: bpftool: resolve calls without using imm field

Currently, we resolve the callee's address for a JITed function call by using the imm field of the call instruction as an offset from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further use this address to get the callee's kernel symbol's name. For some architectures, such as powerpc64,

[PATCH bpf 3/6] bpf: get kernel symbol addresses via syscall

This adds new two new fields to struct bpf_prog_info. For multi-function programs, these fields can be used to pass a list of kernel symbol addresses for all functions in a given program and to userspace using the bpf system call with the BPF_OBJ_GET_INFO_BY_FD command. When bpf_jit_kallsyms is

[PATCH bpf 1/6] bpf: support 64-bit offsets for bpf function calls

The imm field of a bpf instruction is a signed 32-bit integer. For JIT bpf-to-bpf function calls, it stores the offset of the start address of the callee's JITed image from __bpf_call_base. For some architectures, such as powerpc64, this offset may be as large as 64 bits and cannot be accomodated

Re: [PATCH 0/3] Add support to disable sensor groups in P9

On 05/15/2018 08:32 PM, Guenter Roeck wrote: > On Thu, Mar 22, 2018 at 04:24:32PM +0530, Shilpasri G Bhat wrote: >> This patch series adds support to enable/disable OCC based >> inband-sensor groups at runtime. The environmental sensor groups are >> managed in HWMON and the remaining platform