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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 27 May 2020 09:06:22 +0800 From: maobibo <maobibo@...ngson.cn> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Jiaxun Yang <jiaxun.yang@...goat.com>, Huacai Chen <chenhc@...ote.com>, Paul Burton <paulburton@...nel.org>, Dmitry Korotin <dkorotin@...ecomp.com>, Philippe Mathieu-Daudé <f4bug@...at.org>, Stafford Horne <shorne@...il.com>, Steven Price <steven.price@....com>, Anshuman Khandual <anshuman.khandual@....com>, linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org, Mike Rapoport <rppt@...ux.ibm.com>, Sergei Shtylyov <sergei.shtylyov@...entembedded.com>, "Maciej W. Rozycki" <macro@....com>, linux-mm@...ck.org, David Hildenbrand <david@...hat.com> Subject: Re: [PATCH v6 1/4] MIPS: Do not flush tlb page when updating PTE entry On 05/26/2020 05:42 AM, Andrew Morton wrote: > On Mon, 25 May 2020 10:52:37 +0800 Bibo Mao <maobibo@...ngson.cn> wrote: > >> It is not necessary to flush tlb page on all CPUs if suitable PTE >> entry exists already during page fault handling, just updating >> TLB is fine. >> >> Here redefine flush_tlb_fix_spurious_fault as empty on MIPS system. >> >> ... >> >> --- a/arch/mips/include/asm/pgtable.h >> +++ b/arch/mips/include/asm/pgtable.h >> @@ -478,6 +478,8 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot) >> return __pgprot(prot); >> } >> >> +#define flush_tlb_fix_spurious_fault(vma, address) do { } while (0) >> + > > static inline C would be preferred, if that works. For a number of reasons: > > - looks nicer > > - more likely to get a code comment (for some reason) > > - adds typechecking. So right now a MIPS developer could do > > struct wibble a; > struct wobble b; > > flush_tlb_fix_spurious_fault(&a, &b); > > and there would be no compiler warning. Then the code gets merged > upstream and in come the embarrassing emails! > > - avoids unused-var warnings > > foo() > { > struct address_space a; > struct vm_area_struct v; > > flush_tlb_fix_spurious_fault(&v, &a); > } > > will generate unused-variable warnings if > flush_tlb_fix_spurious_fault() is a macro. Making > flush_tlb_fix_spurious_fault() inlined C prevents this. > Sure, I will modify this and send another version.
Powered by blists - more mailing lists