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]
Date:   Sun, 19 Mar 2023 20:16:36 +0000
From:   Matthew Wilcox <>
To:     Thomas Bogendoerfer <>
Subject: Re: [PATCH v4 16/36] mips: Implement the new page table range API

On Sun, Mar 19, 2023 at 07:45:36PM +0100, Thomas Bogendoerfer wrote:
> On Fri, Mar 17, 2023 at 04:29:20PM +0100, Thomas Bogendoerfer wrote:
> > hmm, not sure if that would help. R4k style TLB has two PTEs mapped
> > per TLB entry. So by advancing per page __update_tlb() is called more
> > often than needed.
> btw. how big is nr going to be ? There are MIPS SoCs out there, which
> just have 16 TLBs...

Oof.  The biggest we're going to see for now is one less than PTRS_PER_PMD
(that'd be a PMD-sized allocation that's mapped askew with 1 page in
one PMD and n-1 pages in the adjacent PMD).  That'd be 511 on x86 and
I presume something similar on MIPS.  More than 16, for sure.

Now, this isn't a new problem with this patchset.  With fault-around,
we already call set_pte_at() N times.  And we don't say which ones are
speculative entries vs the one actually faulted in.

But let's see if we can fix it.  What if we passed in the vmf?  That would
give you the actual faulting address, so you'd know to only put the PTE
into the Linux page tables and not go as far as putting it into the TLB.
Open to other ideas.

Powered by blists - more mailing lists