This patch adds new kernel traces in the current in-kernel 'library'
which can be called by other drivers to help interacting with an
IBM XSL on a POWER9 system.
If some kernel traces exist in the 'normal path' to handle a page or a
segment fault, some others are missing when a page fault is handl
Le 12/03/2018 à 12:36, Arvind Yadav a écrit :
if device_register() returned an error! Always use put_device()
to give up the reference initialized.
Signed-off-by: Arvind Yadav
---
OK, device_unregister() calls put_device() but also other actions that
we can skip in this case.
Acked-by: F
Le 08/03/2018 à 11:05, Vaibhav Jain a écrit :
It is possible for a CXL card to have a valid PSL but no valid
AFUs. When this happens we have a valid instance of 'struct cxl'
representing the adapter but with its member 'struct cxl_afu *cxl[]'
as empty. Unfortunately at many placed within cxl co
printk in unmap_cpu_from_node() uses KERN_ERR message severity
for a WARNING message. Correct message severity to KERN_WARNING.
Signed-off-by: Vipin K Parashar
---
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/
Le 13/03/2018 à 11:11, Vipin K Parashar a écrit :
printk in unmap_cpu_from_node() uses KERN_ERR message severity
for a WARNING message. Correct message severity to KERN_WARNING.
Signed-off-by: Vipin K Parashar
---
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Shilpasri G Bhat writes:
> On 12/04/2017 10:11 AM, Stewart Smith wrote:
>> Shilpasri G Bhat writes:
>>> On 11/28/2017 05:07 PM, Michael Ellerman wrote:
Shilpasri G Bhat writes:
> Adds support to enable/disable a sensor group. This can be used to
> select the sensor groups that
Mauricio Faria de Oliveira writes:
> Hi Michael and Michal,
>
> Got back to this; sorry for the delay.
>
> On 03/06/2018 09:55 AM, Michal Suchánek wrote:
>> Michael Ellerman wrote:
>
>>> I*think* the patch below is all we need, as well as some tweaking of
>>> patch 2, are you able to test and r
Anyone object to us merging the following patch via the powerpc tree?
Full series is here if anyone's interested:
http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=28377&state=*
cheers
Nicholas Piggin writes:
> This will be used by powerpc to allocate per-cpu stacks and other
> da
Hi Michael,
On 03/13/2018 08:39 AM, Michael Ellerman wrote:
I agree; the 'Using fallback displacement flush' message is misleading
(is the system slower/fallback or not? Ô_o)
That message is actually just wrong.
It still prints that even if enable=false.
So we should change all those messag
Nicholas Piggin writes:
> Move this into the early setup code, and don't iterate over CPU masks.
> We don't want to call into sysfs so early from setup, and a future patch
> won't initialize CPU masks by the time this is called.
> ---
> arch/powerpc/kernel/paca.c | 3 +++
> arch/powerpc/ker
Nicholas Piggin writes:
> diff --git a/arch/powerpc/platforms/pseries/kexec.c
> b/arch/powerpc/platforms/pseries/kexec.c
> index eeb13429d685..3fe126796975 100644
> --- a/arch/powerpc/platforms/pseries/kexec.c
> +++ b/arch/powerpc/platforms/pseries/kexec.c
> @@ -23,7 +23,12 @@
>
> void pserie
On Tue, 13 Mar 2018 23:41:46 +1100
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > diff --git a/arch/powerpc/platforms/pseries/kexec.c
> > b/arch/powerpc/platforms/pseries/kexec.c
> > index eeb13429d685..3fe126796975 100644
> > --- a/arch/powerpc/platforms/pseries/kexec.c
> > +++ b/arc
On Tue, 13 Mar 2018 23:25:05 +1100
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > Move this into the early setup code, and don't iterate over CPU masks.
> > We don't want to call into sysfs so early from setup, and a future patch
> > won't initialize CPU masks by the time this is calle
Greg Kroah-Hartman writes:
> On Sat, Mar 10, 2018 at 05:14:22PM +0100, christophe leroy wrote:
>> Le 10/03/2018 à 15:52, Greg Kroah-Hartman a écrit :
>> > On Sat, Mar 10, 2018 at 08:27:54AM +0100, christophe leroy wrote:
>> > > Le 10/03/2018 à 01:10, Greg Kroah-Hartman a écrit :
>> > > > On Fri, M
Hi Deepa,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on ]
url:
https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305
base:
config: arm64-allnoconfig (attached as .config)
compiler
Hi Deepa,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on ]
url:
https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305
base:
config: powerpc-iss476-smp_defconfig (attached as
On Tue, 13 Mar 2018 23:25:05 +1100
Michael Ellerman wrote:
> Nicholas Piggin writes:
>
> > Move this into the early setup code, and don't iterate over CPU masks.
> > We don't want to call into sysfs so early from setup, and a future patch
> > won't initialize CPU masks by the time this is calle
On Tue, Mar 13, 2018 at 10:02:09PM +1100, Michael Ellerman wrote:
> Shilpasri G Bhat writes:
> > On 12/04/2017 10:11 AM, Stewart Smith wrote:
> >> Shilpasri G Bhat writes:
> >>> On 11/28/2017 05:07 PM, Michael Ellerman wrote:
> Shilpasri G Bhat writes:
>
> > Adds support to enable/
On Tue, 13 Mar 2018 09:14:39 -0300
Mauricio Faria de Oliveira wrote:
> Hi Michael,
>
> On 03/13/2018 08:39 AM, Michael Ellerman wrote:
> >> I agree; the 'Using fallback displacement flush' message is
> >> misleading (is the system slower/fallback or not? Ô_o)
>
> > That message is actually ju
This is a port on kernel 4.16 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 han
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.
Suggested-by: Thomas Gleixner
Signed-off-by: Laurent Dufour
---
mm/Kconfig | 3 +++
1 file changed, 3 insertions(+)
Introduce CONFIG_SPECULATIVE_PAGE_FAULT which turns on the Speculative Page
Fault handler when building for 64bits with SMP.
Cc: Thomas Gleixner
Signed-off-by: Laurent Dufour
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a0a77
Define CONFIG_SPECULATIVE_PAGE_FAULT for BOOK3S_64 and SMP. 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 book3e
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 pte_map_lock() which can fa
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
---
mm/memory.c |
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 unmap_page_range() one allows us to make assumptions about
page-tables; when we find the seqcount hasn't changed we can assume
page-tables are
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_spinloc
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.
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
protec
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.
Signed-off-by: Laurent Dufour
---
include/linux/migrate.h |
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.
This
The current maybe_mkwrite() is getting passed the pointer to the vma
structure to fetch the vm_flags field.
When dealing with the speculative page fault handler, it will be better to
rely on the cached vm_flags value stored in the vm_fault structure.
This patch introduce a __maybe_mkwrite() servi
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 pointer
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 value
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 VM
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
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 detect change
(includi
Add a new software event to count succeeded speculative page faults.
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 b/include/uapi/linux/perf_event.h
index 6f873503552d..a6ddab9edeec 100644
---
Add support for the new speculative faults event.
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
tools/perf/util/parse-events.l| 1 +
tools/perf/util/python.c
When the speculative page fault handler is returning VM_RETRY, there is a
chance that VMA fetched without grabbing the mmap_sem can be reused by the
legacy page fault handler. By reusing it, we avoid calling find_vma()
again. To achieve, that we must ensure that the VMA structure will not be
freed
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 is now done in
handle_speculative_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 mult
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_poli
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 | 87
mm/memory.c | 62 ++--
2 files changed, 136 in
On 03/13/2018 02:59 PM, Michal Suchánek wrote:
Maybe it would make more sense to move the messages to the function
that actually patches in the instructions?
That helps, but if the instructions are not patched (e.g., no_rfi_flush)
then there is no information about what the system actually supp
Copypasta from original gmb() and rfi implementation
Signed-off-by: Michal Suchanek
---
arch/powerpc/include/asm/barrier.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/include/asm/barrier.h
b/arch/powerpc/include/asm/barrier.h
index 10daa1d56e0a..8e47b3abe405 100644
Hello,
this is patchset adding barrier_nospec on powerpc. It is based on the
out-of-tree gmb() patch and the existing rfi patches.
I do not have the tests for the Spectre/Meltdown issues available so this is
untested.
Feedback on the general approach as well as actual effectivity is welcome.
Th
Signed-off-by: Michal Suchanek
---
arch/powerpc/kernel/entry_64.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2cb5109a7ea3..7bfc4cf48af2 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.
Coopypasta from x86.
Signed-off-by: Michal Suchanek
---
arch/powerpc/include/asm/uaccess.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 51bfeb8777f0..af9b0e731f46 100644
--- a/arch/p
Copypasta from rfi implementation
Signed-off-by: Michal Suchanek
---
arch/powerpc/include/asm/barrier.h| 4 ++--
arch/powerpc/include/asm/feature-fixups.h | 9 +
arch/powerpc/include/asm/setup.h | 8
arch/powerpc/kernel/setup_64.c| 29
Copypasta from rfi implementation
Signed-off-by: Michal Suchanek
---
arch/powerpc/kernel/setup_64.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index d1d9f047161e..4b67b7b877d9 100644
---
Copypasta from rfi implementation
Signed-off-by: Michal Suchanek
---
arch/powerpc/platforms/pseries/setup.c | 38 ++
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
in
Copypasta from lwsync patching.
Note that unlike RFI which is patched only in kernel the nospec state
reflects settings at the time the module was loaded.
Iterating all modules and re-patching every time the settings change is
not implemented.
Signed-off-by: Michal Suchanek
---
arch/powerpc/in
Copypasta from rfi implementation
Signed-off-by: Michal Suchanek
---
arch/powerpc/kernel/setup_64.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4b67b7b877d9..257f0e6be107 100644
--- a/arch/powerpc/kernel/setup_
On Tue, 13 Mar 2018 15:13:11 -0300
Mauricio Faria de Oliveira wrote:
> On 03/13/2018 02:59 PM, Michal Suchánek wrote:
> > Maybe it would make more sense to move the messages to the function
> > that actually patches in the instructions?
>
> That helps, but if the instructions are not patched (
On Tue, 13 Mar 2018 23:06:35 +1100 Michael Ellerman wrote:
> Anyone object to us merging the following patch via the powerpc tree?
>
> Full series is here if anyone's interested:
> http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=28377&state=*
>
Yup, please go ahead.
I assume t
On 03/13/2018 03:36 PM, Michal Suchánek wrote:
On Tue, 13 Mar 2018 15:13:11 -0300
Mauricio Faria de Oliveira wrote:
On 03/13/2018 02:59 PM, Michal Suchánek wrote:
Maybe it would make more sense to move the messages to the function
that actually patches in the instructions?
That helps, but
On Tue, Mar 13, 2018 at 07:32:59PM +0100, Michal Suchanek wrote:
> Copypasta from original gmb() and rfi implementation
Actual real changelogs would be very welcome. Seeing as I've not seen
these mythical RFI patches, this leaves one quite puzzled :-)
Hi Arnaldo,
Please pull an update to the JSON files for POWER9 PMU events.
The following changes since commit 90d2614c4d10c2f9d0ada9a3b01e5f43ca8d1ae3:
perf test: Fix exit code for record+probe_libc_inet_pton.sh (2018-03-13
15:14:43 -0300)
are available in the git repository at:
https://
When running virtualised the powerpc kernel is able to run the system
in "compat mode" - which means the kernel and hardware are pretending
to userspace that the CPU is an older version than it actually is.
AT_BASE_PLATFORM is an AUXV entry that we export to userspace for use
when we're running in
On Wed, 14 Mar 2018 10:14:11 +1100
Michael Ellerman wrote:
> When running virtualised the powerpc kernel is able to run the system
> in "compat mode" - which means the kernel and hardware are pretending
> to userspace that the CPU is an older version than it actually is.
>
> AT_BASE_PLATFORM is
On Tue, 13 Mar 2018 12:41:28 -0700
Andrew Morton wrote:
> On Tue, 13 Mar 2018 23:06:35 +1100 Michael Ellerman
> wrote:
>
> > Anyone object to us merging the following patch via the powerpc tree?
> >
> > Full series is here if anyone's interested:
> >
> > http://patchwork.ozlabs.org/project
On Tue, Mar 13, 2018 at 10:58 AM, Benjamin Herrenschmidt
wrote:
> On Mon, 2018-03-12 at 12:43 +0800, Pingfan Liu wrote:
>> For kexec -p, the boot cpu can be not the cpu0, this causes the problem
>> to alloc paca[]. In theory, there is no requirement to assign cpu's logical
>> id as its present seq
On 7/3/18 2:40 pm, Alexey Kardashevskiy wrote:
> On 13/02/18 16:51, Alexey Kardashevskiy wrote:
>> GPUs and the corresponding NVLink bridges get different PEs as they have
>> separate translation validation entries (TVEs). We put these PEs to
>> the same IOMMU group so they cannot be passed through
ething to improve:
>
> [auto build test ERROR on ]
>
> url:
> https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305
> base:
> config: arm64-allnoconfig (attached as .config)
> compiler: aarch64-linu
o improve:
>
> [auto build test ERROR on ]
>
> url:
> https://github.com/0day-ci/linux/commits/Deepa-Dinamani/posix_clocks-Prepare-syscalls-for-64-bit-time_t-conversion/20180313-203305
> base:
> config: powerpc-iss476-smp_defconfig (attached as .config)
> compiler: power
The series is a preparation series for individual architectures
to use 64 bit time_t syscalls in compat and 32 bit emulation modes.
This is a follow up to the series Arnd Bergmann posted:
https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1]
Thomas, Arnd, this seems ready to be merged no
All the current architecture specific defines for these
are the same. Refactor these common defines to a common
header file.
The new common linux/compat_time.h is also useful as it
will eventually be used to hold all the defines that
are needed for compat time types that support non y2038
safe typ
Hi all,
I get the following from a powerpc_ppc44x defconfig build in current
linux-next:
arch/powerpc/boot/ebony.dtb: Warning (pci_bridge): /plb/pci@20ec0: missing
bus-range for PCI bridge
arch/powerpc/boot/ebony.dtb: Warning (pci_device_bus_num): Failed prerequisite
'pci_bridge'
arch/powe
Hi all,
I also get these from a powerpc allyesconfig build of linux-next:
WARNING: vmlinux.o(.text+0x7c81c): Section mismatch in reference from the
function .stop_machine_change_mapping() to the function
.meminit.text:.create_physical_mapping()
The function .stop_machine_change_mapping() refere
70 matches
Mail list logo
