[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html] On 29.06.23 16:40, Jiri Slaby wrote: > > On 27. 02. 23, 18:36, Suren Baghdasaryan wrote: >> Attempt VMA lock-based page fault handling first, and fall back to the >> existing mmap_lock-based handling if that fails. > [...] >> + fault = handle_mm_fault(vma, address, flags | >> FAULT_FLAG_VMA_LOCK, regs); >> + vma_end_read(vma); >> + >> + if (!(fault & VM_FAULT_RETRY)) { >> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS); >> + goto done; >> + } >> + count_vm_vma_lock_event(VMA_LOCK_RETRY); > > This is apparently not strong enough as it causes go build failures like: > > [ 409s] strconv > [ 409s] releasep: m=0x579e2000 m->p=0x5781c600 p->m=0x0 p->status=2 > [ 409s] fatal error: releasep: invalid p state > [ 409s] > > [ 325s] hash/adler32 > [ 325s] hash/crc32 > [ 325s] cmd/internal/codesign > [ 336s] fatal error: runtime: out of memory > > There are many kinds of similar errors. It happens in 1-3 out of 20 > builds only. > > If I revert the commit on top of 6.4, they all dismiss. Any idea? > > The downstream report: > https://bugzilla.suse.com/show_bug.cgi?id=1212775 > [...] Thanks for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced 0bff0aaea03e2a3ed6bfa3021 https://bugzilla.suse.com/show_bug.cgi?id=1212775 #regzbot title mm: failures when building go in 1-3 out of 20 builds #regzbot ignore-activity Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
