On 3/25/2021 1:36 PM, Daniel Lezcano wrote:
The slope of the temperature increase or decrease can be high and when
the temperature crosses the trip point, there could be a significant
difference between the trip temperature and the measured temperatures.
That forces the userspace to read the
On Wed, Dec 23, 2020 at 09:06:01PM -0300, Thiago Jung Bauermann wrote:
>
> Hi Ram,
>
> Thanks for reviewing this patch.
>
> Ram Pai writes:
>
> > On Fri, Dec 18, 2020 at 03:21:03AM -0300, Thiago Jung Bauermann wrote:
> >> On server-class POWER machines, we
On Fri, Dec 18, 2020 at 03:21:03AM -0300, Thiago Jung Bauermann wrote:
> On server-class POWER machines, we don't need the SWIOTLB unless we're a
> secure VM. Nevertheless, if CONFIG_SWIOTLB is enabled we unconditionally
> allocate it.
>
> In most cases this is harmless, but on a few machine confi
On 10/6/2020 6:20 AM, Daniel Lezcano wrote:
The dynamic thermal and power management is a technique to dynamically
adjust the power consumption of different devices in order to ensure a
global thermal constraint.
An userspace daemon is usually monitoring the temperature and the
power to take
On Thu, Oct 01, 2020 at 11:17:15AM -0700, Ralph Campbell wrote:
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being used (gup, compaction,
> migr
. In
> addition, the mmap_sem is help in read mode during that time, not in write
^^ held
> mode since the virual memory layout is not impacted, and
> kvm->arch.uvmem_lock prevents concurrent operation on the secure device.
>
> Cc: Ram Pai
Reviewed-by: Ram Pai
RP
ock, so prefix the original function with __
> and remove the locking in it, and introduce a wrapper which call that
> function with the lock held.
>
> There is no functional change.
Reviewed-by: Ram Pai
>
> Cc: Ram Pai
> Cc: Bharata B Rao
> Cc: Paul Mackerras
> Signed-off-by: Laurent Dufour
> ---
RP
On 5/15/2020 8:10 AM, Daniel Lezcano wrote:
Initially the thermal framework had a very simple notification
mechanism to send generic netlink messages to the userspace.
The notification function was never called from anywhere and the
corresponding dead code was removed. It was probably a first
NIT_ABORT, this hcall will be
> filtered out in kvmppc_h_svm_init_abort() because kvm->arch.secure_guest is
> not set in that case.
>
> Fixes: 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* Hcalls")
> Signed-off-by: Laurent Dufour
Reviewed-by: Ram Pai
&
Signed-off-by: Sayali Lokhande
Co-Developed-by: Ram Prakash Gupta
Signed-off-by: Ram Prakash Gupta
---
drivers/mmc/core/debugfs.c | 90 ++
drivers/mmc/core/host.c| 153 +
2 files changed, 243 insertions(+)
diff --git a/drivers
Adding clk scaling dt parameters.
Signed-off-by: Ram Prakash Gupta
---
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci
: Ram Prakash Gupta
Signed-off-by: Ram Prakash Gupta
---
drivers/mmc/host/sdhci-msm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index b75c82d..67accf6 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci
Badiganti
Signed-off-by: Bao D. Nguyen
Signed-off-by: Can Guo
Signed-off-by: Sayali Lokhande
Co-Developed-by: Ram Prakash Gupta
Signed-off-by: Ram Prakash Gupta
---
drivers/mmc/core/block.c | 19 -
drivers/mmc/core/core.c | 8 +++
drivers/mmc/core/host.c | 10
holds,
up_threshold and down_threshold to decide whether to increase
the frequency or scale it down respectively as per load.
Ram Prakash Gupta (6):
mmc: core: Parse clk scaling dt entries
mmc: core: Add core scaling support in driver
mmc: core: Initialize clk scaling for mmc and SDCard
: Can Guo
Signed-off-by: Sayali Lokhande
Co-Developed-by: Ram Prakash Gupta
Signed-off-by: Ram Prakash Gupta
---
drivers/mmc/core/core.c | 769
drivers/mmc/core/core.h | 17 ++
drivers/mmc/core/mmc.c | 192
drivers/mmc/core/sd.c
-by: Can Guo
Signed-off-by: Sayali Lokhande
Co-Developed-by: Ram Prakash Gupta
Signed-off-by: Ram Prakash Gupta
---
drivers/mmc/core/host.c | 63 +
include/linux/mmc/card.h | 7 +
include/linux/mmc/host.h | 66
because during build vmlinux is linked with an expected virtual
> runtime address of KERNELBASE.
>
> Fixes: 6a9c930bd775 ("powerpc/prom_init: Add the ESM call to prom_init")
> Signed-off-by: Thiago Jung Bauermann
Tested-by: Ram Pai
> ---
> arch/powerpc/include
On Tue, Oct 15, 2019 at 09:35:01AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
> > From: Thiago Jung Bauermann
> >
> > Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
> > be set by both device an
gt; - return !(read_amr() & ((AMR_RD_BIT|AMR_WR_BIT) << pkey_shift));
> -}
> -
> int __execute_only_pkey(struct mm_struct *mm)
> {
> return mm->context.execute_only_pkey;
The function was initially used by __execute_only_pkey(), but ones we
changed the implementation of __execute_only_pkey(), the need for
pkey_allows_readwrite() disappeared.
Acked-by: Ram Pai
--
Ram Pai
explicit request to preserve the state of the current
kernel, unsharing of pages is skipped.
NOTE: Reserve atleast 256M for crashkernel. Otherwise SWIOTLB
allocation fails and crash kernel fails to boot.
Signed-off-by: Ram Pai
diff --git a/arch/powerpc/include/asm/ultravisor-api.h
b/arch
le to anyone needing it, inside the
secure-virtual-machine. All of this is integrity-protected and encrypted
to safegaurd it when at rest and at runtime.
Bottomline -- Blob is data, and hence no licensing implication. And due
to some reason, even data needs to have licensing statement, we can
make it available to have no conflicts with GPL.
--
Ram Pai
On 8/14/2018 12:04 PM, Lina Iyer wrote:
Adding Ram, so he can respond.
-- Lina
On Thu, Jul 26 2018 at 02:55 -0600, Zhang Rui wrote:
On δΈ€, 2018-05-07 at 11:55 -0600, Lina Iyer wrote:
From: Ram Chandrasekar
Let userspace be another voter for cooling device state instead of
the
overriding
processor. Has anyone come across this issue? What am I doing wrong?
Any suggestion is deeply appreciated.
Thanks,
Ram Gupta
On Wed, May 23, 2018 at 09:50:02PM +0300, Michael S. Tsirkin wrote:
> subj: s/virito/virtio/
>
..snip..
> > machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init);
> > +
> > +bool platform_forces_virtio_dma(struct virtio_device *vdev)
> > +{
> > + /*
> > +* On protected guest pl
Agree. Was going to send that the moment the other patches
landed upstream. Glad I dont have to do it :-)
Reviewed-by: Ram Pai
On Thu, May 10, 2018 at 11:54:22PM +1000, Michael Ellerman wrote:
> Now that we've updated the generic headers to support 5 PKEY bits for
> powerpc we don
On Wed, May 09, 2018 at 12:59:44AM +1000, Michael Ellerman wrote:
> Consolidate the pkey handling by providing a common empty definition
> of vma_pkey() in pkeys.h when CONFIG_ARCH_HAS_PKEYS=n.
>
> This also removes another entanglement of pkeys.h and
> asm/mmu_context.h.
>
Re
On Wed, May 09, 2018 at 12:59:42AM +1000, Michael Ellerman wrote:
> From: Ram Pai
>
> Currently only 4bits are allocated in the vma flags to hold 16
> keys. This is sufficient for x86. PowerPC supports 32 keys,
> which needs 5bits. This patch allocates an additional bit.
&
ied that this would overwrite the 0 entry
> ("??") with "".
Yes it would :-( and could potentially break anything that depends on
0th entry being "??"
Is the following fix acceptable?
#if VM_PKEY_BIT4
[ilog2(VM_PKEY_BIT4)] = "",
#endif
--
Ram Pai
-by: Thiago Jung Bauermann
(fixed compilation errors for x86 configs)
Acked-by: Michal Hocko
Reviewed-by: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |5 -
arch/x86/include/asm/mmu_context.h |5 -
arch/x86/include/asm/pkeys.h
implemented (1).
- comment by Michal Hocko
version prior to v11:
(1) used one additional bit from VM_HIGH_ARCH_*
to support 32 keys.
- Suggestion by Dave Hansen.
(2) powerpc specific changes to support memory keys.
Ram Pai (3):
mm
Signed-off-by: Ram Pai
---
fs/proc/task_mmu.c |1 +
include/linux/mm.h |8 +++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 0c9e392..3c7 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -679,6 +679,7
: Dave Hansen
Signed-off-by: Ram Pai
Reviewed-by: Ingo Molnar
Reviewed-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pkeys.h |2 ++
fs/proc/task_mmu.c |4 ++--
include/linux/mm.h |9 +
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a
hardware enables some pages
to be shared with the hypervisor. Secure VM then uses these pages to
bounce virtio data with the hypervisor.
One elegant way to impliment this functionality is to abstract it
under our special dma_ops and wire it to the virtio devices.
However the restriction imposed by the generic virtio code, contrains us
from doing so.
If we can enrich vring_use_dma_api() to take multiple factors into
consideration and not just VIRTIO_F_IOMMU_PLATFORM; perferrably by
consulting a arch-dependent function, we could seemlessly integrate
into the existing virtio infrastructure.
RP
>
> --
> MST
--
Ram Pai
is a known issue with the use of printf() in the
> signal handler and a resulting deadlock. I *thought* there was a patch
> merged to fix this from Ram Pai or one of the other IBM folks.
Yes. there is a patch. unfortunately that patch assumes the selftest has
been moved into selftests/vm d
On Thu, Apr 26, 2018 at 10:57:31AM -0700, Dave Hansen wrote:
> On 04/06/2018 06:09 PM, Ram Pai wrote:
> > Well :). my point is add this code and delete the other
> > code that you add later in that function.
>
> I don't think I'm understanding what your suggestion w
On Wed, Apr 11, 2018 at 08:16:33AM +0200, Takashi Iwai wrote:
> On Wed, 11 Apr 2018 02:37:44 +0200,
> Ram Pai wrote:
> >
> > On Tue, Apr 10, 2018 at 01:42:39PM -0700, Andrew Morton wrote:
> > > On Tue, 10 Apr 2018 06:54:11 +0200 Takashi Iwai wrote:
> > >
On Tue, Apr 10, 2018 at 01:42:39PM -0700, Andrew Morton wrote:
> On Tue, 10 Apr 2018 06:54:11 +0200 Takashi Iwai wrote:
>
> > On Tue, 10 Apr 2018 02:23:26 +0200,
> > Andrew Morton wrote:
> > >
> > > On Sun, 8 Apr 2018 09:20:26 +0200 Takashi Iwai wrote:
> > >
> > > > We've got a bug report ind
On Fri, Apr 06, 2018 at 05:47:29PM -0700, Dave Hansen wrote:
> On 04/06/2018 05:09 PM, Ram Pai wrote:
> >> - /*
> >> - * Look for a protection-key-drive execute-only mapping
> >> - * which is now being given permissions that are not
> >> - * execute-
gt; We had a check for PROT_READ/WRITE, but it did not work
> for PROT_NONE. This entirely removes the PROT_* checks,
> which ensures that PROT_NONE now works.
>
> Reported-by: Shakeel Butt
>
> Signed-off-by: Dave Hansen
> Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys
On Wed, Apr 04, 2018 at 06:41:01PM -0300, Thiago Jung Bauermann wrote:
>
> Hello Ram,
>
> Ram Pai writes:
>
> > 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
>
On Thu, Apr 05, 2018 at 04:40:15PM +0200, Takashi Iwai wrote:
> On Mon, 02 Apr 2018 22:35:04 +0200,
> Takashi Iwai wrote:
> >
> > On Mon, 02 Apr 2018 21:09:03 +0200,
> > Ram Pai wrote:
> > >
> > > On Mon, Apr 02, 2018 at 09:16:16AM +0200, Takashi
loc.start + size - 1;
> - if (resource_contains(&avail, &alloc)) {
> + if (alloc.start <= alloc.end &&
> + resource_contains(&avail, &alloc)) {
> new->start = alloc.start;
> new->end = alloc.end;
> return 0;
> --
> 2.16.2
--
Ram Pai
: Dave Hansen
Signed-off-by: Ram Pai
Reviewed-by: Ingo Molnar
Reviewed-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pkeys.h |2 ++
fs/proc/task_mmu.c |4 ++--
include/linux/mm.h |9 +
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a
-by: Thiago Jung Bauermann
(fixed compilation errors for x86 configs)
Acked-by: Michal Hocko
Reviewed-by: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |5 -
arch/x86/include/asm/mmu_context.h |5 -
arch/x86/include/asm/pkeys.h
:
(1) used one additional bit from VM_HIGH_ARCH_*
to support 32 keys.
- Suggestion by Dave Hansen.
(2) powerpc specific changes to support memory keys.
Ram Pai (3):
mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS
is enabled
mm
Acked-by: Balbir Singh
Signed-off-by: Ram Pai
---
fs/proc/task_mmu.c |1 +
include/linux/mm.h |3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 6b996d0..6d83bb7 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
nly
> disallow values that are actually bad (< 0).
>
> The end-user visible effect of this is that you can now use
> mprotect_pkey() to set pkey=0.
>
> This is a bit nicer than what Ram proposed because it is simpler
> and removes special-casing for pkey 0. On the other ha
: Ingo Molnar
cc: Andrew Morton
Signed-off-by: Ram Pai
---
History:
v2: mm_pkey_is_allocated() continued to treat pkey-0 special.
fixed it.
arch/powerpc/include/asm/pkeys.h | 20
arch/powerpc/mm/pkeys.c | 20
2 files changed
On Mon, Mar 26, 2018 at 04:31:41PM -0700, Ram Pai wrote:
> 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
> implementati
: Ingo Molnar
cc: Andrew Morton
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/pkeys.h | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..9c7d3bd 100644
--- a/arch
nly
> disallow values that are actually bad (< 0).
>
> The end-user visible effect of this is that you can now use
> mprotect_pkey() to set pkey=0.
>
> This is a bit nicer than what Ram proposed because it is simpler
> and removes special-casing for pkey 0. On the other ha
On Sun, Mar 18, 2018 at 10:30:48AM +0100, Thomas Gleixner wrote:
> On Sat, 17 Mar 2018, Ram Pai wrote:
> > On Fri, Mar 16, 2018 at 02:46:56PM -0700, Dave Hansen wrote:
> > >
> > > From: Dave Hansen
> > >
> > > mm_pkey_is_allocated() treats pkey 0 as
nly
> disallow values that are actually bad (< 0).
>
> The end-user visible effect of this is that you can now use
> mprotect_pkey() to set pkey=0.
>
> This is a bit nicer than what Ram proposed because it is simpler
> and removes special-casing for pkey 0. On the other ha
On Fri, Mar 16, 2018 at 10:02:22PM +1100, Balbir Singh wrote:
> On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai wrote:
> > 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
> > provid
address-range.
Tested on powerpc only. Could not test on x86.
cc: Thomas Gleixner
cc: Dave Hansen
cc: Michael Ellermen
cc: Ingo Molnar
cc: Andrew Morton
Signed-off-by: Ram Pai
---
History:
v4 : (1) moved the code entirely in arch-independent location.
(2) fixed comments
On Thu, Mar 15, 2018 at 10:31:51AM -0700, Dave Hansen wrote:
> On 03/15/2018 10:21 AM, Ram Pai wrote:
> > On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
> >> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
> >>>> +if (!pkey || !mm_pkey_is_al
On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
> >> + if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> > Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> > ever. If it does, then this wants to be fixed.
>
> I
Hansen
cc: Michael Ellermen
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/pkeys.h | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..3c1deec 100644
--- a
cc: Michael Ellermen
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/x86/include/asm/pkeys.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index a0ba1ff..6ea7486 100644
--- a/arch/x86/include/asm/pkeys.h
On Wed, Mar 14, 2018 at 10:51:26AM -0700, Dave Hansen wrote:
> On 03/14/2018 10:14 AM, Ram Pai wrote:
> > I look at key-0 as 'the key'. It has special status.
> > (a) It always exist.
>
> Do you mean "is always allocated"?
always allocated and cannot be
On Wed, Mar 14, 2018 at 07:19:23AM -0700, Dave Hansen wrote:
> On 03/14/2018 12:46 AM, Ram Pai wrote:
> > Once an address range is associated with an allocated pkey, it cannot be
> > reverted back to key-0. There is no valid reason for the above behavior. On
> > the contrary
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/x86/include/asm/pkeys.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index a0ba1ff..6ea7486 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/pkeys.h | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..3c1deec 100644
--- a/arch/powerpc/include/asm
On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote:
> On 03/09/2018 12:12 AM, Ram Pai wrote:
> > Once an address range is associated with an allocated pkey, it cannot be
> > reverted back to key-0. There is no valid reason for the above behavior. On
> > the contrary
On Fri, Mar 09, 2018 at 09:43:32AM +0100, Ingo Molnar wrote:
>
> * Ram Pai wrote:
>
> > Once an address range is associated with an allocated pkey, it cannot be
> > reverted back to key-0. There is no valid reason for the above behavior. On
> > the contrary applicat
On Fri, Mar 09, 2018 at 09:19:53PM +1100, Michael Ellerman wrote:
> Ram Pai writes:
>
> > Once an address range is associated with an allocated pkey, it cannot be
> > reverted back to key-0. There is no valid reason for the above behavior. On
> > the contrary application
On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote:
> On 03/09/2018 09:12 AM, Ram Pai wrote:
> >Once an address range is associated with an allocated pkey, it cannot be
> >reverted back to key-0. There is no valid reason for the above behavior.
>
> mprotect w
On Fri, Mar 09, 2018 at 07:37:04PM +1100, Balbir Singh wrote:
> On Fri, Mar 9, 2018 at 7:12 PM, Ram Pai wrote:
> > Once an address range is associated with an allocated pkey, it cannot be
> > reverted back to key-0. There is no valid reason for the above behavior. On
&
: Michael Ellermen
cc: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/pkeys.h | 19 ++-
arch/x86/include/asm/pkeys.h | 5 +++--
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index
Dave,
Is there a reason why the default key; key-0, is not allowed to be
explicitly associated with pages using pkey_mprotect()?
I see valid usecases where an application may initially want to
associate an address-range with some key and latter choose to revert to
its initial state, by associatin
On Sun, Feb 25, 2018 at 05:27:11PM +0530, Aneesh Kumar K.V wrote:
>
>
> On 02/24/2018 06:35 AM, Ram Pai wrote:
> >On Fri, Feb 23, 2018 at 03:11:45PM +0800, kbuild test robot wrote:
> >>Hi Ram,
> >>
> >>Thank you for the patch! Yet something to improve
On Fri, Feb 23, 2018 at 03:11:45PM +0800, kbuild test robot wrote:
> Hi Ram,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16-rc2 next-20180222]
> [if your patch is applied to the wrong git t
On Fri, Feb 23, 2018 at 03:33:43PM -0300, Thiago Jung Bauermann wrote:
> This test exercises read and write access to the AMR, IAMR and UAMOR.
>
Tested-by: Ram Pai
Acked-by: Ram Pai
> Signed-off-by: Thiago Jung Bauermann
> ---
> tools/testing/selftests/powerpc/include/r
On Fri, Feb 23, 2018 at 03:33:44PM -0300, Thiago Jung Bauermann wrote:
> This test verifies that the AMR, IAMR and UAMOR are being written to a
> process' core file.
>
Acked-by: Ram Pai
Tested-by: Ram Pai
> Signed-off-by: Thiago Jung Bauermann
> ---
> tools/testing/s
This is in preparation to accomadate a differing size register
across architectures.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/pkey-helpers.h| 27 +-
tools/testing/selftests/vm/protection_keys.c | 69 ++
2
Moved all the generic definition and helper functions to the
header file
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/pkey-helpers.h| 62 ++--
tools/testing/selftests/vm/protection_keys.c | 66
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/Makefile |1 +
tools/testing/selftests/vm/pkey-helpers.h | 223
tools/testing/selftests/vm/protection_keys.c | 1407 +
tools/testing/selftests/x86/Makefile
helper functions to handler shadow pkey register
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/pkey-helpers.h| 27
tools/testing/selftests/vm/protection_keys.c | 34 -
2 files changed, 49
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.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing
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
---
tools/testing/selftests/vm/pkey-helpers.h| 85 +-
tools/testing/selftests/vm/protection_keys.c | 227
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 trigger false-positive asserts.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests
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 | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a
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 trigger false-positive asserts.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests
throughout
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/vm/protection_keys.c
b/tools/testing/selftests/vm/protection_keys.c
index
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
---
tools/testing/selftests/vm/protection_keys.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff
of the pkey register is not restored to its
original state. The test case is responsible for restoring the key
register state to its original value.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c |5 +
1 files changed, 5
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
---
tools/testing/selftests/vm/protection_keys.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions
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
---
tools/testing/selftests/vm/protection_keys.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff
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
---
tools/testing/selftests/vm/protection_keys.c | 30 ++
1 files changed, 30
eimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
tools/testing/selftests/vm/pkey-helpers.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
---
tools/testing/selftests/vm/pkey-helpers.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tools/te
Introduce powerpc implementation for the various
abstractions.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/pkey-helpers.h| 128 ++
tools/testing/selftests/vm/protection_keys.c | 42 +---
2 files changed, 136
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
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| 22 --
tools/testing
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 | 81 ++
1 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/tools/testing/selftests/vm
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
---
tools/testing/selftests/vm/pkey-helpers.h| 11 +++
tools/testing/selftests/vm/protection_keys.c
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
have it defined.
version 11:
(1) fixed a deadlock in the ptrace testcase.
version 10 and prior:
(1) moved the testcase to arch neutral directory
(2) split the changes into incremental patches.
Ram Pai (21):
selftests/x86: Move protecton key selftest to arch neutral
*
to support 32 keys.
- Suggestion by Dave Hansen.
(2) powerpc specific changes to support memory keys.
Ram Pai (3):
mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS
is enabled
mm, powerpc, x86: introduce an additional vma bit for powerpc
Signed-off-by: Ram Pai
Reviewed-by: Ingo Molnar
Reviewed-by: Aneesh Kumar K.V
---
fs/proc/task_mmu.c |4 ++--
include/linux/mm.h |9 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ec6d298..6b996d0 100644
--- a/fs
: Thiago Jung Bauermann
(fixed compilation errors for x86 configs)
Acked-by: Michal Hocko
Reviewed-by: Ingo Molnar
Signed-off-by: Ram Pai
---
arch/powerpc/include/asm/mmu_context.h |5 -
arch/x86/include/asm/mmu_context.h |5 -
arch/x86/include/asm/pkeys.h |1 +
arch
1 - 100 of 641 matches
Mail list logo
