Moved all the generic definition and helper functions to the header file.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 35 ++---
expected_pkey_fault() is comparing the contents of pkey
register with 0. This may not be true all the time. There
could be bits set by default by the architecture
which can never be changed. Hence compare the value against
shadow pkey register, which is supposed to track the bits
accurately all
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Acked-by: Ingo Molnar
---
tools/testing/selftests/vm/.gitignore |1 +
tools/testing/selftests/vm/Makefile |1 +
tools/testing/selftests/vm/pkey-helpers.h | 219
introduce a new allocator that allocates 4k hardware-pages to back
64k linux-page. This allocator is only applicable on powerpc.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h|6 ++
Key allocation and deallocation has the side effect of programming the
UAMOR/AMR/IAMR registers. This is wrong, since its the responsibility of
the application and not that of the kernel, to modify the permission on
the key.
Do not modify the pkey registers at key allocation/deallocation.
This
From: "Gautham R. Shenoy"
On 64-bit servers, SPRN_SPRG3 and its userspace read-only mirror
SPRN_USPRG3 are used as userspace VDSO write and read registers
respectively.
SPRN_SPRG3 is lost when we enter stop4 and above, and is currently not
restored. As a result, any read from SPRN_USPRG3
pkey subsystem is supported if the hardware and kernel has support.
We determine that by checking if allocation of a key succeeds or not.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/pkey-helpers.h|2 ++
Ensure pkey-0 is allocated on start. Ensure pkey-0 can be attached
dynamically in various modes, without failures. Ensure pkey-0 can be
freed and allocated.
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c | 66 +-
1 files changed, 64
Total number of pkeys calculation is off by 1. Fix it.
Cc: Florian Weimer
Cc: Michael Ellerman
Cc: Thiago Jung Bauermann
Fixes: 4fb158f65ac5 ("powerpc: track allocation status of all pkeys")
Cc: sta...@vger.kernel.org # v4.16+
Signed-off-by: Ram Pai
---
arch/powerpc/mm/pkeys.c |2 +-
1
On Wed, Jun 20, 2018 at 07:47:02AM -0700, Dave Hansen wrote:
> On 06/13/2018 05:44 PM, Ram Pai wrote:
> > If the flag is 0, no bits will be set. Hence we cant expect
> > the resulting bitmap to have a higher value than what it
> > was earlier
> ...
> > if (flags)
> > -
From: Thiago Jung Bauermann
This will help us ensure we print pkey_reg_t values correctly in different
architectures.
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
detect write-violation on a page to which write-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
---
tools/testing/selftests/vm/protection_keys.c | 12
1 files changed, 12 insertions(+), 0
The test case assumes execute-permissions of unallocated keys are
enabled by default.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Ram Pai
---
.../testing/selftests/powerpc/ptrace/ptrace-pkey.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
This is in preparation to accomadate a differing size register
across architectures.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 23 ---
tools/testing/selftests/vm/pkey-x86.h|
open_hugepage_file() <- opens the huge page file
get_start_key() <-- provides the first non-reserved key.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Dave Hansen
---
tools/testing/selftests/vm/pkey-helpers.h| 10
cleanup the code to satisfy coding styles.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c | 64 +
1 files changed, 43 insertions(+), 21 deletions(-)
diff --git a/tools/testing/selftests/vm/protection_keys.c
detect access-violation on a page to which access-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
---
tools/testing/selftests/vm/protection_keys.c | 19 +++
1 files changed, 19
Generally the signal handler restores the state of the pkey register
before returning. However there are times when the read/write operation
can legitamely fail without invoking the signal handler. Eg: A
sys_read() operaton to a write-protected page should be disallowed. In
such a case the state
Currently in a multithreaded application, a key allocated by one
thread is not usable by other threads. By "not usable" we mean that
other threads are unable to change the access permissions for that
key for themselves.
When a new key is allocated in one thread, the corresponding UAMOR
bits for
Deny all permissions on all keys, with some exceptions. pkey-0 must
allow all permissions, or else everything comes to a screaching halt.
Execute-only key must allow execute permission.
Signed-off-by: Ram Pai
---
arch/powerpc/mm/pkeys.c |8 +++-
1 files changed, 3 insertions(+), 5
alloc_random_pkey() was allocating the same pkey every time.
Not all pkeys were geting tested. fixed it.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git
detect write-violation on a page to which access-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
---
tools/testing/selftests/vm/protection_keys.c | 13 +
1 files changed, 13 insertions(+),
When a thread forks the contents of AMR, IAMR, UAMOR registers in the
newly forked thread are not inherited.
Save the registers before forking, for content of those
registers to be automatically copied into the new thread.
Cc: Michael Ellerman
Cc: Florian Weimer
Cc: Andy Lutomirski
Cc: Thiago
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
Looks good,
Reviewed-by: Christoph Hellwig
On 07/14/2018 11:54 PM, Shilpasri G Bhat wrote:
On-Chip-Controller(OCC) is an embedded micro-processor in POWER9 chip
which measures various system and chip level sensors. These sensors
comprises of environmental sensors (like power, temperature, current
and voltage) and performance sensors
Memory protection keys enables an application to protect its address space from
inadvertent access by its own code.
This feature is now enabled on powerpc architecture and integrated in
4.16-rc1. The patches move the selftests to arch neutral directory
and enhance their test coverage.
Test
some pkru references are named to pkey_reg
and some prku references are renamed to pkey
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Dave Hansen
---
tools/testing/selftests/vm/pkey-helpers.h| 85 +-
instead of clearing the bits, pkey_disable_clear() was setting
the bits. Fixed it.
Also fixed a wrong assertion in that function. When bits are
cleared, the resulting bit value will be less than the original.
This hasn't been a problem so far because this code isn't currently
used.
cc: Dave
The maximum number of keys that can be allocated has to
take into consideration, that some keys are reserved by
the architecture for specific purpose. Hence cannot
be allocated.
Fix the assertion in test_pkey_alloc_exhaust()
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
Assortment of fixes to pkey to match its behavior to that on x86.
Patch 1 makes pkey consumable in multithreaded applications.
Patch 2 Deny, by default, permissions on all unallocated keys.
Patch 3 pkey allocation/free must not change pkey registers.
Patch 4 fixes fork to inherit the key
execute-only key is allocated dynamically. This is a problem. When a
thread implicitly creates a execute-only key, and resets UAMOR for that
key, the UAMOR value does not percolate to all the other threads. Any
other thread may ignorantly change the permissions on the key. This can
cause the
Only when the key is allocated, its permission are enabled.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Ram Pai
---
tools/testing/selftests/powerpc/ptrace/core-pkey.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Hi,
Kernel defines same polynomial for CRC-32 in few places.
This is unnecessary duplication of the same value. Also this might
be error-prone for future code - every driver will define the
polynomial again.
This is an attempt to unify definition of polynomial. Few obvious
hard-coded locations
Do not define again the polynomial but use header with existing define.
Signed-off-by: Krzysztof Kozlowski
---
Not tested
It would be nice to get some testing. Only generic lib/crc, bunzip, xz_crc32
and Freescale's Ethernet driver were tested on HW. Rest got just different
builds.
On Wed, Jun 20, 2018 at 08:20:22AM -0700, Dave Hansen wrote:
> On 06/13/2018 05:45 PM, Ram Pai wrote:
> > Generally the signal handler restores the state of the pkey register
> > before returning. However there are times when the read/write operation
> > can legitamely fail without invoking the
Diana Craciun a écrit :
Implement barrier_nospec for NXP PowerPC Book3E processors.
Diana Craciun (6):
Disable the speculation barrier from the command line
Document nospectre_v1 kernel parameter.
Make stf barrier PPC_BOOK3S_64 specific.
Enable cpu vulnerabilities reporting for NXP
On 07/17/2018 08:58 AM, Ram Pai wrote:
> On Wed, Jun 20, 2018 at 07:47:02AM -0700, Dave Hansen wrote:
>> On 06/13/2018 05:44 PM, Ram Pai wrote:
>>> If the flag is 0, no bits will be set. Hence we cant expect
>>> the resulting bitmap to have a higher value than what it
>>> was earlier
>> ...
>>>
On Wed, Jun 20, 2018 at 07:49:31AM -0700, Dave Hansen wrote:
> On 06/13/2018 05:45 PM, Ram Pai wrote:
> > When a key is freed, the key is no more effective.
> > Clear the bits corresponding to the pkey in the shadow
> > register. Otherwise it will carry some spurious bits
> > which can
On Wed, Jun 20, 2018 at 08:09:12AM -0700, Dave Hansen wrote:
> > - if (cpu_has_pku()) {
> > - dprintf1("SKIP: %s: no CPU support\n", __func__);
> > + if (is_pkey_supported()) {
> > + dprintf1("SKIP: %s: no CPU/kernel support\n", __func__);
> > return;
> > }
Header was defining CRCPOLY_LE/BE and CRC32C_POLY_LE but in fact all of
them are CRC-32 polynomials so use consistent naming.
Signed-off-by: Krzysztof Kozlowski
---
include/linux/crc32poly.h | 4 ++--
lib/crc32.c | 10 +-
lib/gen_crc32table.c | 4 ++--
3 files
On Wed, Jun 20, 2018 at 08:16:44AM -0700, Dave Hansen wrote:
> On 06/13/2018 05:45 PM, Ram Pai wrote:
> > +void test_read_of_access_disabled_region_with_page_already_mapped(int *ptr,
> > + u16 pkey)
> > +{
> > + int ptr_contents;
> > +
> > + dprintf1("disabling access to PKEY[%02d],
On 07/17/2018 09:13 AM, Ram Pai wrote:
> I have incorporated almost all of your comments. But there are some
> comments that take some effort to implement. Shall we get the patches
> merged in the current form? This code has been sitting out for a while.
>
> In the current form its tested and
On Wed, Jun 20, 2018 at 08:07:31AM -0700, Dave Hansen wrote:
> On 06/13/2018 05:45 PM, Ram Pai wrote:
> > --- a/tools/testing/selftests/vm/protection_keys.c
> > +++ b/tools/testing/selftests/vm/protection_keys.c
> > @@ -577,7 +577,8 @@ int sys_pkey_free(unsigned long pkey)
> > int ret =
Allow other drivers and parts of kernel to use the same define for
CRC32 polynomial, instead of duplicating it in many places. This code
does not bring any functional changes, except moving existing code.
Signed-off-by: Krzysztof Kozlowski
---
include/linux/crc32poly.h | 20
On Wed, Jun 20, 2018 at 08:11:07AM -0700, Dave Hansen wrote:
> On 06/13/2018 05:45 PM, Ram Pai wrote:
> > /*
> > -* There are 16 pkeys supported in hardware. Three are
> > -* allocated by the time we get here:
> > -* 1. The default key (0)
> > -* 2. One possibly consumed
Diana Craciun a écrit :
The NXP PPC Book3E platforms are not vulnerable to meltdown and
Spectre v4, so make them PPC_BOOK3S_64 specific.
Signed-off-by: Diana Craciun
---
History:
v2-->v3
- used the existing functions for spectre v1/v2
arch/powerpc/Kconfig | 7 ++-
On Wed, Jun 20, 2018 at 07:53:57AM -0700, Dave Hansen wrote:
> On 06/13/2018 05:45 PM, Ram Pai wrote:
> > +++ b/tools/testing/selftests/vm/protection_keys.c
> > @@ -916,10 +916,10 @@ void expected_pkey_fault(int pkey)
> > pkey_assert(last_si_pkey == pkey);
> >
> > /*
> > -*
The Vitaly Bordug's email bounces ("ru.mvista.com: Name or service not
known") and there was no activity (ack, review, sign) since 2009.
Cc: Vitaly Bordug
Cc: Pantelis Antoniou
Cc: "David S. Miller"
Signed-off-by: Krzysztof Kozlowski
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff
On Tue, Jul 17, 2018 at 10:56:08AM -0700, Dave Hansen wrote:
> On 07/17/2018 09:13 AM, Ram Pai wrote:
> > I have incorporated almost all of your comments. But there are some
> > comments that take some effort to implement. Shall we get the patches
> > merged in the current form? This code has
Do not define again the polynomial but use header with existing define.
Signed-off-by: Krzysztof Kozlowski
---
lib/decompress_bunzip2.c | 3 ++-
lib/xz/xz_crc32.c| 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
Do not define again the polynomial but use header with existing define.
Signed-off-by: Krzysztof Kozlowski
---
Only Freescale FEC was tested
It would be nice to get some testing. Only generic lib/crc, bunzip, xz_crc32
and Freescale's Ethernet driver were tested on HW. Rest got just different
On 06/29/2018 11:52 AM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> switches from an unchanging variable to a constant expression to eliminate
> the VLA generation.
>
> [1]
>
While handling PRRN events, the time to handle the actual hotplug events
dwarfs the time it takes to perform the device tree updates and queue the
hotplug events. In the case that PRRN events are being queued continuously,
hotplug events have been observed to be queued faster than the kernel can
When a PRRN event is being handled and another PRRN event comes in, the
second event will block rtas polling waiting on the first to complete,
preventing any further rtas events from being handled. This can be
especially problematic in case that PRRN events are continuously being
queued in which
> DEFINE(PPC_DBELL_SERVER, PPC_DBELL_SERVER);
> diff --git a/arch/powerpc/kernel/idle_book3s.S
> b/arch/powerpc/kernel/idle_book3s.S
> index d85d551..5069d42 100644
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -120,6 +120,9 @@
For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
is used to load kernel/initrd/purgatory is supposed to be allocated from
top to down. This is what we have been doing all along in the old kexec
loading interface and the kexec loading is still default setting in some
Hi Krzysztof,
On Tue, Jul 17, 2018 at 06:05:35PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Kernel defines same polynomial for CRC-32 in few places.
> This is unnecessary duplication of the same value. Also this might
> be error-prone for future code - every driver will define the
> polynomial
On Tue, Jul 17, 2018 at 05:19:13PM +1000, Alexey Kardashevskiy wrote:
> A VM which has:
> - a DMA capable device passed through to it (eg. network card);
> - running a malicious kernel that ignores H_PUT_TCE failure;
> - capability of using IOMMU pages bigger that physical pages
> can create an
On Tue, Jul 17, 2018 at 6:49 AM Abdul Haleem
wrote:
>
> On Sat, 2018-07-14 at 10:55 +1000, Stephen Rothwell wrote:
> > Hi Abdul,
> >
> > On Fri, 13 Jul 2018 14:43:11 +0530 Abdul Haleem
> > wrote:
> > >
> > > On Thu, 2018-07-12 at 13:44 -0400, Pavel Tatashin wrote:
> > > > > Related commit could
This patchset is doing:
1) Move reparent_resources() to kernel/resource.c to clean up duplicated
code in arch/microblaze/pci/pci-common.c and
arch/powerpc/kernel/pci-common.c .
2) Replace struct resource's sibling list from singly linked list to
list_head. Clearing out those pointer
reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
so that it's shared.
Reviewed-by: Andy Shevchenko
Signed-off-by: Baoquan He
Cc: Michal Simek
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael
The struct resource uses singly linked list to link siblings, implemented
by pointer operation. Replace it with list_head for better code readability.
Based on this list_head replacement, it will be very easy to do reverse
iteration on iomem_resource's sibling list in later patch.
Besides, type
This function, being a variant of walk_system_ram_res() introduced in
commit 8c86e70acead ("resource: provide new functions to walk through
resources"), walks through a list of all the resources of System RAM
in reversed order, i.e., from higher to lower.
It will be used in kexec_file code.
The size is always equal to 1 page so let's use this. Later on this will
be used for other checks which use page shifts to check the granularity
of access.
This should cause no behavioral change.
Reviewed-by: David Gibson
Acked-by: Alex Williamson
Signed-off-by: Alexey Kardashevskiy
---
As
A VM which has:
- a DMA capable device passed through to it (eg. network card);
- running a malicious kernel that ignores H_PUT_TCE failure;
- capability of using IOMMU pages bigger that physical pages
can create an IOMMU mapping that exposes (for example) 16MB of
the host physical memory to
This is to improve page boundaries checking and should probably
be cc:stable. I came accross this while debugging nvlink2 passthrough
but the lack of checking might be exploited by the existing userspace.
The get_user_pages() comment says it should be "phased out" but the only
alternative seems
Implement the barrier_nospec as a isync;sync instruction sequence.
The implementation uses the infrastructure built for BOOK3S 64.
Signed-off-by: Diana Craciun
---
History:
v3-->v4
- fixed compilation issues
v2-->v3
- added PPC_NOSPEC Kconfig
- addressed the review comments
It was a
Used barrier_nospec to sanitize the syscall table.
Signed-off-by: Diana Craciun
---
History:
v2-->v3
- included in the series
arch/powerpc/kernel/entry_32.S | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index
From: "Gautham R. Shenoy"
On 64-bit Servers, SPRN_SPRG3 and its userspace read-only mirror
SPRN_USPRG3 are used as userspace VDSO write and read registers
respectively.
SPRN_SPRG3 is lost when we enter stop4 and above, and is currently not
restored. As a result, any read from SPRN_USPRG3
On 07/16/2018 01:56 PM, Michal Hocko wrote:
> On Mon 16-07-18 11:32:56, Mahesh J Salgaonkar wrote:
>> One of the primary issues with Firmware Assisted Dump (fadump) on Power
>> is that it needs a large amount of memory to be reserved. This reserved
>> memory is used for saving the contents of old
On Tue, Jul 17, 2018 at 04:57:29PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> On 64-bit Servers, SPRN_SPRG3 and its userspace read-only mirror
> SPRN_USPRG3 are used as userspace VDSO write and read registers
> respectively.
>
> SPRN_SPRG3 is lost when we enter stop4 and
On Tue 17-07-18 16:58:10, Mahesh Jagannath Salgaonkar wrote:
> On 07/16/2018 01:56 PM, Michal Hocko wrote:
> > On Mon 16-07-18 11:32:56, Mahesh J Salgaonkar wrote:
> >> One of the primary issues with Firmware Assisted Dump (fadump) on Power
> >> is that it needs a large amount of memory to be
On Sat, 2018-07-14 at 10:55 +1000, Stephen Rothwell wrote:
> Hi Abdul,
>
> On Fri, 13 Jul 2018 14:43:11 +0530 Abdul Haleem
> wrote:
> >
> > On Thu, 2018-07-12 at 13:44 -0400, Pavel Tatashin wrote:
> > > > Related commit could be one of below ? I see lots of patches related to
> > > > mm and
The speculation barrier can be disabled from the command line
with the parameter: "nospectre_v1".
Signed-off-by: Diana Craciun
---
History:
v2-->v3
- no changes
arch/powerpc/kernel/security.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
Implement barrier_nospec for NXP PowerPC Book3E processors.
Diana Craciun (6):
Disable the speculation barrier from the command line
Document nospectre_v1 kernel parameter.
Make stf barrier PPC_BOOK3S_64 specific.
Enable cpu vulnerabilities reporting for NXP PPC BOOK3E
Add
Signed-off-by: Diana Craciun
---
History:
v2-->v3
- new
Documentation/admin-guide/kernel-parameters.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index efc7aa7..b346cc7 100644
---
The NXP PPC Book3E platforms are not vulnerable to meltdown and
Spectre v4, so make them PPC_BOOK3S_64 specific.
Signed-off-by: Diana Craciun
---
History:
v2-->v3
- used the existing functions for spectre v1/v2
arch/powerpc/Kconfig | 7 ++-
arch/powerpc/kernel/security.c | 2 ++
NXP Book3E platforms are not vulnerable to speculative store
bypass, so make the mitigations PPC_BOOK3S_64 specific.
Signed-off-by: Diana Craciun
---
History:
v2-->v3
- new
arch/powerpc/kernel/security.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/security.c
From: Thiago Jung Bauermann
In preparation for multi-arch support, move definitions which have
arch-specific values to x86-specific header.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 111
helper functions to handler shadow pkey register
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 29 ++
tools/testing/selftests/vm/pkey-x86.h|5
Introduce generic abstractions and provide architecture
specific implementation for the abstractions.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 16 -
On 13/07/2018 05:56, Song, HaiyanX wrote:
> Hi Laurent,
Hi Haiyan,
Thanks a lot for sharing this perf reports.
I looked at them closely, and I've to admit that I was not able to found a
major difference between the base and the head report, except that
handle_pte_fault() is no more in-lined in
83 matches
Mail list logo