linux-kernel - Re: [PATCH v2] x86: mm: Do not use set_{pud,pmd}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1aec4241-09c0-5295-7bb7-235e9a494d2c@intel.com>
Date:   Mon, 15 Apr 2019 08:58:52 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Singh, Brijesh" <brijesh.singh@....com>,
        "x86@...nel.org" <x86@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Dan Williams <dan.j.williams@...el.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>
Subject: Re: [PATCH v2] x86: mm: Do not use set_{pud,pmd}_safe when splitting
 the large page

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?