On Fri, 30 Jun 2023 at 15:51, Guenter Roeck linux@roeck-us.net wrote:
There is one more, unfortunately.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... failed
Heh. I didn't even realize that anybody would ever do lock_mm_and_find_vma() code on a nommu platform.
With nommu, handle_mm_fault() will just BUG(), so it's kind of pointless to do any of this at all, and I didn't expect anybody to have this page faulting path that just causes that BUG() for any faults.
But it turns out xtensa has a notion of protection faults even for NOMMU configs:
config PFAULT bool "Handle protection faults" if EXPERT && !MMU default y help Handle protection faults. MMU configurations must enable it. noMMU configurations may disable it if used memory map never generates protection faults or faults are always fatal.
If unsure, say Y.
which is why it violated my expectations so badly.
I'm not sure if that protection fault handling really ever gets quite this far (it certainly should *not* make it to the BUG() in handle_mm_fault()), but I think the attached patch is likely the right thing to do.
Can you check if it fixes that xtensa case? It looks ObviouslyCorrect(tm) to me, but considering that I clearly missed this case existing AT ALL, it might be best to double-check.
Linus