Re: Found it - was: Re: [PATCH] sparc64: fix hugetlb for sun4u

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Thu, 2025-08-21 at 14:52 +0200, David Hildenbrand wrote:
> > > 
> > > @Anthony: Can you see any suspicious in the disassembled code that Meelis
> > > (CC'ed) posted?
> > 
> > OK, bisecting has lead me to the following commit:
> 
> CCing Rick.
> 
> Hm, but that's bpf-only code. Are you sure that it's this exact commit 
> or rather ....
> 
> > 
> > d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit
> > commit d53d2f78ceadba081fc7785570798c3c8d50a718 (HEAD)
> > Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > Date:   Thu Apr 25 17:11:38 2019 -0700
> > 
> >       bpf: Use vmalloc special flag

John pinged me on this on another thread:
https://lore.kernel.org/lkml/7e4dfc01e132196d3ff10df18622252a8455d1b8.camel@intel.com/

Quoted:
   So far two issues were found with that patch and they were both rare
   architectures with broken kernel TLB flushes. Kernel TLB flushes can actually
   not be required for a long time, so probably the bug normally looked like
   unexplained crashes after days. The VM_FLUSH_RESET_PERMS just made them show
   up earlier in a bisectable way.
   
And actually one of the architectures that was broken was sparc, which got fixed in
d3c976c14ad8 ("sparc64: Fix regression in non-hypervisor TLB flush xcall"). John
was going to explore whether the fix might have been incomplete.