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 Al
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 to
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 the
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 t
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 cou
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 a/arch/powerpc/kernel/s
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 barrier_nospec
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
--- a/
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 b/ar
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 ++
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 discussion
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 973
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 return
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 c
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 reser
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 (like
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
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
t
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 +-
tools/testing/se
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 ++---
tools/testing/selftests/vm/protection_key
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
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 a/tools/testing/sel
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|
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
tools/testi
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.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(
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 Hans
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 a/tool
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 +
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 thr
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
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 -
tools/testing/selftests/vm/pkey-p
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 ++
tools/testing/selftests/vm/pkey-powerp
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
---
to
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 insertio
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
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(+),
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
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 ++
tools
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 insertions
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 th
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 at
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 delet
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 pa
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
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 fi
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 key
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.
Lets
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 a/tools/testing/selftests/powerpc/ptrace/core-pk
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 a/tools/testing/selft
Looks good:
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
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)
> > - pkey_assert(rea
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 return
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 trigg
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);
> >
> > /*
> > -* Th
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 = syscall
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;
> > }
>
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 a
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
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 change
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.
drivers/cr
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
bu
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.
drivers/sta
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
in
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 by
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 sig
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], d
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
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 PPC
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 ++-
arch/powerp
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 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 wor
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 been
Stress testing has uncovered issues with handling continuously queued PRRN
events. Running PRRN events in this way can seriously load the system given
the sheer volume of dlpar being handled. This patchset ensures that PRRN
events are handled more synchronously, only allowing the PRRN handler to
qu
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
ac
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 ca
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]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...
> 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 @@ power9_save_addition
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 a
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
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
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 operat
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 E
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 o
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.
Signe
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
distrib
On Tue, Jul 17, 2018 at 05:19:11PM +1000, Alexey Kardashevskiy wrote:
> 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_
On Wed, Jun 20, 2018 at 06:42:58PM +1000, Alexey Kardashevskiy wrote:
> When attaching a hardware table to LIOBN in KVM, we match table parameters
> such as page size, table offset and table size. However the tables are
> created via very different paths - VFIO and KVM - and the VFIO path goes
> th
On Mon, May 28, 2018 at 09:48:26AM +0800, wei.guo.si...@gmail.com wrote:
> From: Simon Guo
>
> Originally PPC KVM MMIO emulation uses only 0~31#(5 bits) for VSR
> reg number, and use mmio_vsx_tx_sx_enabled field together for
> 0~63# VSR regs.
>
> Currently PPC KVM MMIO emulation is reimplemented
On Sat, Jul 07, 2018 at 08:53:07AM +0200, Nicholas Mc Guire wrote:
> The call to of_find_compatible_node() is returning a pointer with
> incremented refcount so it must be explicitly decremented after the
> last use. As here it is only being used for checking of node presence
> but the result is n
On Sat, Jul 07, 2018 at 11:07:25AM +0200, Nicholas Mc Guire wrote:
> The constants are 64bit but not explicitly declared UL resulting
> in sparse warnings. Fixed by declaring the constants UL.
>
> Signed-off-by: Nicholas Mc Guire
Thanks, patch applied to my kvm-ppc-next branch.
Paul.
On 18 July 2018 at 02:12, Eric Biggers wrote:
> 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 f
Hi,
On 07/17/2018 07:17 PM, Guenter Roeck wrote:
> 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, temp
94 matches
Mail list logo