Comment 37 for bug 1927076

I've made some good progress here.

I found that older version like 4.19 work, so I ran git bisect. I'm still doing the final check, but it looks like the series that causes the issue is the one containing these:

d53d2f78cead bpf: Use vmalloc special flag
1a7b7d922081 modules: Use vmalloc special flag
868b104d7379 mm/vmalloc: Add flag for freeing of special permsissions

In particular:

commit 868b104d7379e28013e9d48bdd2db25e0bdcf751 (HEAD)
Author: Rick Edgecombe <email address hidden>
Date: Thu Apr 25 17:11:36 2019 -0700

    mm/vmalloc: Add flag for freeing of special permsissions

    Add a new flag VM_FLUSH_RESET_PERMS, for enabling vfree operations to
    immediately clear executable TLB entries before freeing pages, and handle
    resetting permissions on the directmap. This flag is useful for any kind
    of memory with elevated permissions, or where there can be related
    permissions changes on the directmap. Today this is RO+X and RO memory.

    Although this enables directly vfreeing non-writeable memory now,
    non-writable memory cannot be freed in an interrupt because the allocation
    itself is used as a node on deferred free list. So when RO memory needs to
    be freed in an interrupt the code doing the vfree needs to have its own
    work queue, as was the case before the deferred vfree list was added to
    vmalloc.

    For architectures with set_direct_map_ implementations this whole operation
    can be done with one TLB flush when centralized like this. For others with
    directmap permissions, currently only arm64, a backup method using
    set_memory functions is used to reset the directmap. When arm64 adds
    set_direct_map_ functions, this backup can be removed.

    When the TLB is flushed to both remove TLB entries for the vmalloc range
    mapping and the direct map permissions, the lazy purge operation could be
    done to try to save a TLB flush later. However today vm_unmap_aliases
    could flush a TLB range that does not include the directmap. So a helper
    is added with extra parameters that can allow both the vmalloc address and
    the direct mapping to be flushed during this operation. The behavior of the
    normal vm_unmap_aliases function is unchanged.

and

commit d53d2f78ceadba081fc7785570798c3c8d50a718
Author: Rick Edgecombe <email address hidden>
Date: Thu Apr 25 17:11:38 2019 -0700

    bpf: Use vmalloc special flag

    Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
    permissioned memory in vmalloc and remove places where memory was set RW
    before freeing which is no longer needed. Don't track if the memory is RO
    anymore because it is now tracked in vmalloc.

This is _extremely_ in "subtly break under the hash MMU" areas.

Hopefully this is enough to get some Power MMU experts to weigh in. I will keep working on it.