Re: [PATCH] thermal/drivers/netlink: Add the temperature when crossing a trip point

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

Re: [PATCH] powerpc/mm: Limit allocation of SWIOTLB on server machines

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

Re: [PATCH] powerpc/mm: Limit allocation of SWIOTLB on server machines

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

Re: [PATCH 2/4] Documentation/powercap/dtpm: Add documentation for dtpm

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

Re: [RFC PATCH v3 2/2] mm: remove extra ZONE_DEVICE struct page refcount

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, >

Re: [PATCH v2 2/2] KVM: PPC: Book3S HV: rework secure mem slot dropping

. 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

Re: [PATCH v2 1/2] KVM: PPC: Book3S HV: move kvmppc_svm_page_out up

em_lock, 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

Re: [PATCH 4/4] thermal: core: genetlink support for events/cmd/sampling

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

Re: [PATCH v2] KVM: PPC: Book3S HV: relax check on H_SVM_INIT_ABORT

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 &

[RFC 4/6] mmc: core: Add debugfs entries for scaling support

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

[RFC 6/6] dt-bindings: mmc: sdhci-msm: Add clk scaling dt parameters

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

[RFC 5/6] mmc: sdhci-msm: Add capability in platform host

-by: 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

[RFC 3/6] mmc: core: Initialize clk scaling for mmc and SDCard

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

[RFC 0/6] mmc: Add clock scaling support for mmc driver

, 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 mmc

[RFC 2/6] mmc: core: Add core scaling support in driver

-by: 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

[RFC 1/6] mmc: core: Parse clk scaling dt entries

-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

Re: [PATCH] powerpc/prom_init: Undo relocation before entering secure mode

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

RE: [PATCH 2/2] virtio_ring: Use DMA API if memory is encrypted

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 devic

Re: [PATCH] powerpc/pkeys: remove unused pkey_allows_readwrite

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

[RFC PATCH 1/1] powerpc/pseries/svm: Unshare all pages before kexecing a new kernel

, or if there is a 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

Re: Re: [RFC PATCH 02/12] powerpc: Add support for adding an ESM blob to the zImage wrapper

lable 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

Re: [PATCH] drivers: thermal: do not clobber cooling dev state from userspace

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

Re: [PATCH] drivers: thermal: do not clobber cooling dev state from userspace

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

kernel hang

processor. Has anyone come across this issue? What am I doing wrong? Any suggestion is deeply appreciated. Thanks, Ram Gupta

kernel hang

processor. Has anyone come across this issue? What am I doing wrong? Any suggestion is deeply appreciated. Thanks, Ram Gupta

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

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

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

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

Re: [PATCH 9/8] powerpc/pkeys: Drop private VM_PKEY definitions

Agree. Was going to send that the moment the other patches landed upstream. Glad I dont have to do it :-) Reviewed-by: Ram Pai <linux...@us.ibm.com> On Thu, May 10, 2018 at 11:54:22PM +1000, Michael Ellerman wrote: > Now that we've updated the generic headers to support 5

Re: [PATCH 9/8] powerpc/pkeys: Drop private VM_PKEY definitions

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't ne

Re: [PATCH 4/8] mm/pkeys, powerpc, x86: Provide an empty vma_pkey() in linux/pkeys.h

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

Re: [PATCH 4/8] mm/pkeys, powerpc, x86: Provide an empty vma_pkey() in linux/pkeys.h

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

Re: [PATCH 2/8] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

On Wed, May 09, 2018 at 12:59:42AM +1000, Michael Ellerman wrote: > From: Ram Pai <linux...@us.ibm.com> > > 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 allocat

Re: [PATCH 2/8] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

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

Re: [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

ried 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

Re: [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

ried 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

[PATCH v11 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

g.org> cc: Andrew Morton <a...@linux-foundation.org> Reviewed-by: Dave Hansen <dave.han...@intel.com> Signed-off-by: Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> (fixed compilation errors for x86 configs) Acked-by: Michal Hocko <mho...@suse.com> Reviewed-by: Ingo Molnar &

[PATCH v11 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

-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

[PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

that 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

[PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

that 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

[PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

el.crashing.org> cc: Andrew Morton <a...@linux-foundation.org> Reviewed-by: Ingo Molnar <mi...@kernel.org> Acked-by: Balbir Singh <bsinghar...@gmail.com> Signed-off-by: Ram Pai <linux...@us.ibm.com> --- fs/proc/task_mmu.c |1 + include/linux/mm.h |8 +++- 2 f

[PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

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

[PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

idt <b...@kernel.crashing.org> cc: Andrew Morton <a...@linux-foundation.org> Reviewed-by: Dave Hansen <dave.han...@intel.com> Signed-off-by: Ram Pai <linux...@us.ibm.com> Reviewed-by: Ingo Molnar <mi...@kernel.org> Reviewed-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com

[PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

-by: 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

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

o 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

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

o 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

Re: [PATCH 0/9] [v3] x86, pkeys: two protection keys bug fixes

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/

Re: [PATCH 0/9] [v3] x86, pkeys: two protection keys bug fixes

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/

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

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 was. I

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

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 was. I

Re: [PATCH v2] resource: Fix integer overflow at reallocation

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 <ti...@suse.de> wro

Re: [PATCH v2] resource: Fix integer overflow at reallocation

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: > > >

Re: [PATCH v2] resource: Fix integer overflow at reallocation

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: > > > > >

Re: [PATCH v2] resource: Fix integer overflow at reallocation

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

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

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-

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

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-

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

e Hansen <dave.han...@linux.intel.com> > Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys > support") > Cc: sta...@kernel.org > Cc: Ram Pai <linux...@us.ibm.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Dave Hansen

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

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

Re: [PATCH v2] powerpc, pkey: make protection key 0 less special

On Wed, Apr 04, 2018 at 06:41:01PM -0300, Thiago Jung Bauermann wrote: > > Hello Ram, > > Ram Pai <linux...@us.ibm.com> writes: > > > Applications need the ability to associate an address-range with some > > key and latter revert to its initial default key. Pk

Re: [PATCH v2] powerpc, pkey: make protection key 0 less special

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

Re: [PATCH] resource: Fix integer overflow at reallocation

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

Re: [PATCH] resource: Fix integer overflow at reallocation

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

Re: [PATCH] resource: Fix integer overflow at reallocation

nd = alloc.start + size - 1; > - if (resource_contains(, )) { > + if (alloc.start <= alloc.end && > + resource_contains(, )) { > new->start = alloc.start; > new->end = alloc.end; > return 0; > -- > 2.16.2 -- Ram Pai

Re: [PATCH] resource: Fix integer overflow at reallocation

{ > + if (alloc.start <= alloc.end && > + resource_contains(, )) { > new->start = alloc.start; > new->end = alloc.end; > return 0; > -- > 2.16.2 -- Ram Pai

[PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

idt <b...@kernel.crashing.org> cc: Andrew Morton <a...@linux-foundation.org> Reviewed-by: Dave Hansen <dave.han...@intel.com> Signed-off-by: Ram Pai <linux...@us.ibm.com> Reviewed-by: Ingo Molnar <mi...@kernel.org> Reviewed-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com

[PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

-by: 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

[PATCH v13 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

g.org> cc: Andrew Morton <a...@linux-foundation.org> Reviewed-by: Dave Hansen <dave.han...@intel.com> Signed-off-by: Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> (fixed compilation errors for x86 configs) Acked-by: Michal Hocko <mho...@suse.com> Reviewed-by: Ingo Molnar &

[PATCH v13 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

-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

[PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

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

[PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

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

[PATCH v13 2/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

errenschmidt <b...@kernel.crashing.org> cc: Andrew Morton <a...@linux-foundation.org> Reviewed-by: Ingo Molnar <mi...@kernel.org> Acked-by: Balbir Singh <bsinghar...@gmail.com> Signed-off-by: Ram Pai <linux...@us.ibm.com> --- fs/proc/task_mmu.c |1 + include

[PATCH v13 2/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

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

Re: [PATCH 1/9] x86, pkeys: do not special case protection key 0

n_map. Stop special casing it and only > 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 spe

Re: [PATCH 1/9] x86, pkeys: do not special case protection key 0

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

[PATCH v2] powerpc, pkey: make protection key 0 less special

Hansen <dave.han...@intel.com> cc: Michael Ellermen <m...@ellerman.id.au> cc: Ingo Molnar <mi...@kernel.org> cc: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Ram Pai <linux...@us.ibm.com> --- History: v2: mm_pkey_is_allocated() continued to treat pkey-0 s

[PATCH v2] powerpc, pkey: make protection key 0 less special

: 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

Re: [PATCH] powerpc, pkey: make protection key 0 less special

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

Re: [PATCH] powerpc, pkey: make protection key 0 less special

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

[PATCH] powerpc, pkey: make protection key 0 less special

Hansen <dave.han...@intel.com> cc: Michael Ellermen <m...@ellerman.id.au> cc: Ingo Molnar <mi...@kernel.org> cc: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Ram Pai <linux...@us.ibm.com> --- arch/powerpc/include/asm/pkeys.h | 24

[PATCH] powerpc, pkey: make protection key 0 less special

: 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

Re: [PATCH 1/9] x86, pkeys: do not special case protection key 0

n_map. Stop special casing it and only > 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 spe

Re: [PATCH 1/9] x86, pkeys: do not special case protection key 0

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

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

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 <dave.han...@linux.intel.com> > > > > > >

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

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

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

n_map. Stop special casing it and only > 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 spe

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

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

Re: [PATCH v4] mm, pkey: treat pkey-0 special

On Fri, Mar 16, 2018 at 10:02:22PM +1100, Balbir Singh wrote: > On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai <linux...@us.ibm.com> wrote: > > Applications need the ability to associate an address-range with some > > key and latter revert to its initial default key. Pkey-0 comes c

Re: [PATCH v4] mm, pkey: treat pkey-0 special

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 > > pr

[PATCH v4] mm, pkey: treat pkey-0 special

address-range. Tested on powerpc only. Could not test on x86. cc: Thomas Gleixner <t...@linutronix.de> cc: Dave Hansen <dave.han...@intel.com> cc: Michael Ellermen <m...@ellerman.id.au> cc: Ingo Molnar <mi...@kernel.org> cc: Andrew Morton <a...@linux-foundation.org>

[PATCH v4] mm, pkey: treat pkey-0 special

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

Re: [PATCH v3] x86: treat pkey-0 special

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_

Re: [PATCH v3] x86: treat pkey-0 special

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_

Re: [PATCH v3] x86: treat pkey-0 special

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

Re: [PATCH v3] x86: treat pkey-0 special

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

[PATCH v3] powerpc: treat pkey-0 special

Hansen <dave.han...@intel.com> cc: Michael Ellermen <m...@ellerman.id.au> cc: Ingo Molnar <mi...@kernel.org> Signed-off-by: Ram Pai <linux...@us.ibm.com> --- arch/powerpc/include/asm/pkeys.h | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/

[PATCH v3] powerpc: treat pkey-0 special

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

[PATCH v3] x86: treat pkey-0 special

<dave.han...@intel.com> cc: Michael Ellermen <m...@ellerman.id.au> cc: Ingo Molnar <mi...@kernel.org> Signed-off-by: Ram Pai <linux...@us.ibm.com> --- arch/x86/include/asm/pkeys.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/includ

[PATCH v3] x86: treat pkey-0 special

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

Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0

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 freed.

Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0

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 freed.

Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0

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 contr

  1   2   3   4   5   6   7   8   9   10   >