Re: [RFC][PATCHSET] VM_FAULT_RETRY fixes

[Al Viro <viro@zeniv.linux.org.uk>]

On Thu, Feb 02, 2023 at 09:54:35PM +1300, Michael Cree wrote:
> On Thu, Feb 02, 2023 at 06:58:03AM +0000, Al Viro wrote:
> > Other bugs in the same area:
> > 	* we ought to compare address with VMALLOC_START,
> > not TASK_SIZE.
> > 	* we ought to do that *before* checking for
> > kernel threads/pagefault_disable() being in effect.
> > 
> > Wait a minute - pgd_present() on alpha has become constant 1
> > since a73c948952cc "alpha: use pgtable-nopud instead of 4level-fixup"
> > 
> > So that thing had been completely broken for 3 years and nobody
> > had noticed.  
> 
> I have never noticed because I haven't been able to run a 5.9 or
> newer kernel on Alpha reliably so have been running a 5.8 kernel
> for quite some time.

Er...  For one thing, commit in question went into 5.5; for another
you would only have noticed if you had CONFIG_ALPHA_LARGE_VMALLOC
in your .config, so I rather doubt it's the same problem.

Normally alpha has one PGDIR_SIZE worth of vmalloc space, and it's shared
between all processes - that one slot in top-level table is filled before
we spawn any threads so all of them end up sharing the reference to
the same middle-level table, which is where vmalloc stuff gets mapped.

So normally we have 8Gb of vmalloc space and, as usual for 64bit
boxen, no need to play with vmalloc handling on page faults.  The trouble
is with a kludge that tries to give more than 8Gb; it gives just under
2Tb (2Tb-8Gb, actually - 255 slots out 1024 in top-level table).  That
does need assistance from #PF handler, and that assistance (ifdefed
under CONFIG_ALPHA_LARGE_VMALLOC) what I'd been refering to.

To quote Kconfig,
====
# LARGE_VMALLOC is racy, if you *really* need it then fix it first
config ALPHA_LARGE_VMALLOC
        bool
        help
          Process creation and other aspects of virtual memory management can
          be streamlined if we restrict the kernel to one PGD for all vmalloc
          allocations.  This equates to about 8GB.

          Under normal circumstances, this is so far and above what is needed
          as to be laughable.  However, there are certain applications (such
          as benchmark-grade in-kernel web serving) that can make use of as
          much vmalloc space as is available.

          Say N unless you know you need gobs and gobs of vmalloc space.
====
"Racy" probably had been about something along the lines of the scenario
I'd mentioned just upthread, but in 5.5 that "racy" escalated to "does not
work at all" - if you ever hit a vmalloc-related fault, you are going
to get an oops.  You still get 8Gb, but beyond that it's broken.

And it's almost certainly not the problem you are seeing...