Re: [PATCH v12 22/22] selftests/vm: Fix deadlock in protection_keys.c

1, args) But both are equivalent I guess, so Acked-by: Balbir Singh <bsinghar...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

On Fri, 15 Sep 2017 18:21:07 -0700 Ram Pai wrote: > Currently the architecture specific code is expected to > display the protection keys in smap for a given vma. > This can lead to redundant code and possibly to divergent > formats in which the key gets displayed. >

Re: [PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

> --- Just curious, how do you see this being used? For debugging or will applications parse these properties and use them? It's hard for an application to partition its address space among keys at runtime, would you agree? Balbir Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC v5 14/38] powerpc: initial plumbing for key management

On Fri, Jul 14, 2017 at 6:37 AM, Ram Pai <linux...@us.ibm.com> wrote: > On Thu, Jul 13, 2017 at 12:45:00AM -0700, Ram Pai wrote: >> On Wed, Jul 12, 2017 at 01:28:25PM +1000, Balbir Singh wrote: >> > On Wed, 5 Jul 2017 14:21:51 -0700 >> > Ram Pai <linux...@us

Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

On Thu, Jul 13, 2017 at 5:55 PM, Ram Pai <linux...@us.ibm.com> wrote: > On Wed, Jul 12, 2017 at 03:26:01PM +1000, Balbir Singh wrote: >> On Wed, 5 Jul 2017 14:21:52 -0700 >> Ram Pai <linux...@us.ibm.com> wrote: >> >> > Implements helper functions to rea

Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

; + WARN(1, "%s called with MEMORY PROTECTION KEYS disabled\n", __func__); > + return -1; > +} Why do we need to have a version here if we are going to WARN(), why not let the compilation fail if called from outside of CONFIG_PPC64_MEMORY_PROTECTION_KEYS? Is that the intention?

Re: [RFC v5 14/38] powerpc: initial plumbing for key management

ok3s64.c > b/arch/powerpc/mm/mmu_context_book3s64.c > index c6dca2a..2da9931 100644 > --- a/arch/powerpc/mm/mmu_context_book3s64.c > +++ b/arch/powerpc/mm/mmu_context_book3s64.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -120,6 +121,10 @@ static int hash__init_new_context(struct mm_struct *mm) > > subpage_prot_init_new_context(mm); > > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > + pkey_mm_init(mm); Can we have two variants of pkey_mm_init() and avoid #ifdefs around the code? > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */ > + > return index; > } > Balbir Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages

On Tue, 11 Jul 2017 08:44:15 -0700 Ram Pai <linux...@us.ibm.com> wrote: > On Tue, Jul 11, 2017 at 03:59:59PM +1000, Balbir Singh wrote: > > On Wed, 5 Jul 2017 14:21:39 -0700 > > Ram Pai <linux...@us.ibm.com> wrote: > > > > > Rearrange 64K P

Re: [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages

'_'__'_'_'_'_' > It's not entirely clear what the secondary pte contains today and how many of the bits are free today? Balbir Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC v5 01/38] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages

HPTE, they continue to be > used if the PTE gets backed by 64k HPTE. The next > patch will decouple that aswell, and truely release the > bits. > Balbir Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to

Re: [RFC v4 02/17] mm: ability to disable execute permission on a key at creation

able execute at key creation > time. x86 does not allow this. Hence the next patch will add > ability in x86 to return error if PKEY_DISABLE_EXECUTE is > specified. > > Signed-off-by: Ram Pai <linux...@us.ibm.com> > --- Acked-by: Balbir Singh <bsingha

Re: [RFC v4 03/17] x86: key creation with PKEY_DISABLE_EXECUTE disallowed

RU_AD_BIT; I am not an x86 expert. IIUC, execute disable is done via allocating an execute_only_pkey and checking vma_key via AD + vma_flags against VM_EXEC. Your patch looks good to me Acked-by: Balbir Singh <bsinghar...@gmail.com> Balbir Singh. -- To unsubscribe from this list: send the line "

Re: [RFC v4 01/17] mm: introduce an additional vma bit for powerpc pkey

[ilog2(VM_PKEY_BIT2)] = "", > [ilog2(VM_PKEY_BIT3)] = "", > +#endif /* CONFIG_ARCH_HAS_PKEYS */ > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > + /* Additional bit in ProtectionKey: */ > + [ilog2(VM_PKEY_BIT4)] = "

Re: [RFC v4 00/17] powerpc: Memory Protection Keys

didn't know about that register". > (5) these changes enable protection keys on 4k-page > kernel aswell. I have not looked at the full series, but it seems cleaner than the original one and the side-effect is that we can support 4k as well. Nice! Balbir Si

Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper

lt; (subpg_index << 2)); > + *hidxp = rpte.hidx | (slot << (subpg_index << 2)); > + /* > + * Avoid race with __real_pte() > + * hidx must be committed to memory before committing > + * the pte. > + */ > + smp_wmb(); Whats the other

Re: [RFC v3 01/23] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages

_hash_ops.hpte_remove(hpte_group); > /* >* FIXME!! Should be try the group from which we > removed ? > diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c > index f2095ce..1b494d0 100644 > --- a/arch/powerpc/mm/hash_

Re: [RFC PATCH] mm, oom: cgroup-aware OOM-killer

On Thu, 2017-05-18 at 20:20 +0100, Roman Gushchin wrote: > On Fri, May 19, 2017 at 04:37:27AM +1000, Balbir Singh wrote: > > On Fri, May 19, 2017 at 3:30 AM, Michal Hocko <mho...@kernel.org> wrote: > > > On Thu 18-05-17 17:28:04, Roman Gushchin wrote: > > >

Re: [RFC PATCH] mm, oom: cgroup-aware OOM-killer

On Fri, May 19, 2017 at 3:30 AM, Michal Hocko wrote: > On Thu 18-05-17 17:28:04, Roman Gushchin wrote: >> Traditionally, the OOM killer is operating on a process level. >> Under oom conditions, it finds a process with the highest oom score >> and kills it. >> >> This behavior

Re: [PATCH] mm: per-cgroup memory reclaim stats

On Sat, May 13, 2017 at 2:42 AM, Johannes Weiner <han...@cmpxchg.org> wrote: > On Fri, May 12, 2017 at 12:25:22PM +1000, Balbir Singh wrote: >> On Thu, 2017-05-11 at 20:16 +0100, Roman Gushchin wrote: >> > The meaning of each value is the same as for global counters, &g

Re: [PATCH] mm: per-cgroup memory reclaim stats

On Thu, 2017-05-11 at 20:16 +0100, Roman Gushchin wrote: > Track the following reclaim counters for every memory cgroup: > PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and > PGLAZYFREED. > > These values are exposed using the memory.stats interface of cgroup v2. The changelog

Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node

> happen. We can immediately go back to top-down allocation. That is the > missing call being added in the patch. > Can we fix cmdline_parse_movable_node() to do the right thing? I suspect that code is heavily x86 only in the sense that no other arch needs it. Balbir Singh. -- To

Re: [PATCH v2 2/3] powerpc/mm: allow memory hotplug into a memoryless node

n light testing. > > [1] > http://lkml.kernel.org/r/cagzkibrmksa1yyhbf5hwgxubcjse5smksmy4tpanerme2ug...@mail.gmail.com > > http://lkml.kernel.org/r/20160511215051.gf22...@arbab-laptop.austin.ibm.com > > Signed-off-by: Reza Arbab <ar...@linux.vnet.ibm.com> > Acked-

Re: [PATCH v2 1/3] drivers/of: recognize status property of dt memory nodes

m.com> Makes sense, so basically a /memory@ with missing status or status = "okay" are added, others are skipped. No memblocks corresponding to those nodes are created either. Balbir Singh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mm: Add the ram_latent_entropy kernel parameter

hash ^= hash + data[index]; Won't the hash be the same across boots? Is this entropy addition for KASLR, since it is so early in boot?q > + add_device_randomness((const void *), sizeof(hash)); > + } > + > page_zone(page)->managed_pages += nr_pages; > set_page_refcounted(page); > __free_pages(page, order); > Balbir Singh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] powerpc/mm: allow memory hotplug into a memoryless node

_nid(unsigned long scn_addr) > { > struct device_node *memory = NULL; > - int nid, found = 0; > + int nid; > Do we want to do this only for ibm,hotplug-aperture compatible ranges? I'm OK either ways Acked-by: Balbir Singh <bsinghar...@gmail.com> -- To unsubscr

Re: [PATCH 2/4] powerpc/mm: create numa nodes for hotplug memory

the associated > address range. > > Signed-off-by: Reza Arbab <ar...@linux.vnet.ibm.com> > --- Looks good to me Acked-by: Balbir Singh <bsinghar...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a messag

Re: [PATCH 1/4] dt-bindings: add doc for ibm,hotplug-aperture

n) > + > +Example: > + > +A 2 GiB aperture at 0x1, to be part of nid 3 when hotplugged: > + > + hotplug-memory@1 { > + compatible = "ibm,hotplug-aperture"; > + reg = <0x0 0x10000 0x0 0x8000>; > +