gned-off-by: Dan Williams
> Fixes: 6ae330cad6ef ("virtiofs: serialize truncate/punch_hole and dax fault
> path")
> Cc: Vivek Goyal
>
Looks good
Reviewed-by: Balbir Singh
_idx, end_idx - start_idx + 1, 0);
But I don't think it's a blocker unmap_mapping_pages() should do the right
thing internally
Acked-by: Balbir Singh
Cc: Michael Ellerman
> Cc: Rashmica Gupta
> Cc: Balbir Singh
> Cc: Michael Neuling
> Reviewed-by: Pavel Tatashin
> Reviewed-by: Rashmica Gupta
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/platforms/powernv/memtrace.c | 4 +++-
> 1 file changed, 3 insert
On Wed, Sep 19, 2018 at 09:35:07AM +0200, David Hildenbrand wrote:
> Am 19.09.18 um 03:22 schrieb Balbir Singh:
> > On Tue, Sep 18, 2018 at 01:48:16PM +0200, David Hildenbrand wrote:
> >> Reading through the code and studying how mem_hotplug_lock is to be used,
> >> I
if (level <= DEBUG_LEVEL) \
sigsafe_printf(args); \
- fflush(NULL); \
} while (0)
#define dprintf0(args...) dprintf_level(0, args)
#define dprintf1(args...) dprintf_level(1, args)
But both are equivalent I guess, so
Acked-by: Ba
On Fri, 15 Sep 2017 18:21:05 -0700
Ram Pai wrote:
> 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.
>
> Signed-off-by: Ram Pai
> ---
On Fri, 15 Sep 2017 18:21:07 -0700
Ram Pai wrote:
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> + if (arch_pkeys_enabled())
Sorry, I missed this bit in my previous review
the patch makes sense
> + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> +#endif
> +
Balbir
--
To unsubscribe
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.
>
> This patch chang
l_keys <==
> 1
>
> ==> /sys/kernel/mm/protection_keys/usable_keys <==
> 0
>
> Signed-off-by: Ram Pai
> Signed-off-by: Thiago Jung Bauermann
> ---
Just curious, how do you see this being used? For debugging
or will applications parse these properties and use
On Fri, Jul 14, 2017 at 6:37 AM, Ram Pai 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 wrote:
>> >
>> > > Init
On Thu, Jul 13, 2017 at 5:55 PM, Ram Pai 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 wrote:
>>
>> > Implements helper functions to read and write the key related
>> > registers; A
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?
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
+{
> + return 0;
> +}
> +
> +static inline void pkey_mm_init(struct mm_struct *mm)
> +{
> + mm_pkey_allocation_map(mm) = PKEY_INITIAL_ALLOCAION;
> +}
> +#endif /*_ASM_PPC64_PKEYS_H */
> diff --git a/arch/powerpc/mm/mmu_context_book3s64.c
> b/arch/powerpc/mm/mmu_c
On Tue, 11 Jul 2017 08:44:15 -0700
Ram Pai 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 wrote:
> >
> > > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6
> > > in the
...| | | | | <- secondary pte
> '_'_'_'_'__'__'__'__'_'_'_'_'__'_'_'_'_'
>
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
y 4k 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 messa
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
> ---
Acked-by: Balbir Singh
--
To unsubscribe from this list: send t
ert. 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
Balbir Singh.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message t
[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)] = "",
> #endif
Not sure
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!
Balb
gt; + *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 paired barrier, is it i
.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_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -975,8 +975,9 @@ void __init hash__early_init_devtree(void)
>
> void __init hash__early_init_mmu(void)
> {
> +#ifndef CONFIG_PPC_64K_PAGES
> /*
> - * We have code in __hash_page_64K() and elsewhere, which assumes it can
> + * We have code in __hash_page_4K() and elsewhere, which assumes it can
>* do the following:
>* new_pte |= (slot << H_PAGE_F_GIX_SHIFT) & (H_PAGE_F_SECOND |
> H_PAGE_F_GIX);
>*
> @@ -987,6 +988,7 @@ void __init hash__early_init_mmu(void)
>* with a BUILD_BUG_ON().
>*/
> BUILD_BUG_ON(H_PAGE_F_SECOND != (1ul << (H_PAGE_F_GIX_SHIFT + 3)));
> +#endif /* CONFIG_PPC_64K_PAGES */
>
> htab_init_page_sizes();
>
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
On Thu, 2017-05-18 at 15:22 -0400, Johannes Weiner 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 wrote:
> > > On Thu 18-05-17 17:28:04, Roman Gushchin wrote:
> > > > Traditionally, the OOM ki
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 wrote:
> > > On Thu 18-05-17 17:28:04, Roman Gushchin wrote:
> > > > Traditionally, the OOM ki
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 doesn't suit well the
On Sat, May 13, 2017 at 2:42 AM, Johannes Weiner 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,
>> > available using /
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 c
Update kernel-parameters.txt to add Documentation
for powersave=off.
Signed-off-by: Balbir Singh
---
Applies of top of linux-next 20161201
Documentation/admin-guide/kernel-parameters.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/kernel
g, so that scenario can't
> 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
en found in 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
> Acked-by: Balbir
ically 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
; + size_t index, end = PAGE_SIZE * nr_pages / sizeof(hash);
> + const u64 *data = lowmem_page_address(page);
> +
> + for (index = 0; index < end; index++)
> + hash ^= hash + data[index];
Won't the hash be the same acros
{
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc&qu
the associated
> address range.
>
> Signed-off-by: Reza Arbab
> ---
Looks good to me
Acked-by: 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
:
> +
> +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>;
> + ibm,associativity = <0x4 0x0
35 matches
Mail list logo
