lkml.org 
[lkml]   [2019]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] x86: mm: Do not use set_{pud,pmd}_safe when splitting the large page
From
Date
On 4/15/19 7:55 AM, Singh, Brijesh wrote:
> static unsigned long __meminit
> phys_pte_init(pte_t *pte_page, unsigned long paddr, unsigned long paddr_end,
> - pgprot_t prot)
> + pgprot_t prot, bool safe)
> {
> unsigned long pages = 0, paddr_next;
> unsigned long paddr_last = paddr_end;
> @@ -432,7 +463,7 @@ phys_pte_init(pte_t *pte_page, unsigned long paddr, unsigned long paddr_end,
> E820_TYPE_RAM) &&
> !e820__mapped_any(paddr & PAGE_MASK, paddr_next,
> E820_TYPE_RESERVED_KERN))
> - set_pte_safe(pte, __pte(0));
> + __set_pte(pte, __pte(0), safe);
> continue;
> }

The changelog is great, btw.

But, I'm not a big fan of propagating the 'safe' nomenclature. Could
we, at least, call it 'overwrite_safe' or something if we're going to
have a variable name? Or even, 'new_entries_only' or something that
actually conveys meaning?

Because, just reading it, I always wonder "why do we have an unsafe
variant, that's stupid" every time. :)

> +#define DEFINE_ENTRY(type1, type2, safe) \
> +static inline void __set_##type1(type1##_t *arg1, \
> + type2##_t arg2, bool safe) \
> +{ \
> + if (safe) \
> + set_##type1##_safe(arg1, arg2); \
> + else \
> + set_##type1(arg1, arg2); \
> +}

While I appreciate the brevity that these macros allow, I detest their
ability to thwart cscope and grep. I guess it's just one file, but it
does make me grumble a bit.

Also, can we do better than "__"? Aren't these specific to
initialization, and only for the kernel? Maybe we should call them
meminit_set_pte() or kern_set_pte() or something so make it totally
clear to the reader that they're new.


> - kernel_physical_mapping_init(__pa(vaddr & pmask),
> - __pa((vaddr_end & pmask) + psize),
> - split_page_size_mask);
> + kernel_physical_mapping_change(__pa(vaddr & pmask),
> + __pa((vaddr_end & pmask) + psize),
> + split_page_size_mask);

BTW, this hunk is really nice the way that the new naming makes it more
intuitive what's going on. My only nit w9uld be that we now have two
very similarly-named functions with different TLB-flushing requirements.

Could we please include a comment at this site that reminds us that we
owe a TLB flush after this?

\
 
 \ /
  Last update: 2019-04-15 17:59    [W:0.056 / U:4.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site