On Sun, Feb 05, 2023 at 10:18:30PM -0500, Peter Xu wrote: > On Mon, Feb 06, 2023 at 02:51:18AM +0000, Matthew Wilcox wrote: > > That wasn't what I meant. I meant putting VM_FAULT_BADMAP and > > VM_FAULT_SIGSEGV in mm_types.h. Not having "Here is a range of reserved > > arch private ones". > > VM_FAULT_SIGSEGV is there already; I assume you meant adding them all > directly into vm_fault_reason. > > Then I don't think it's a good idea.. > > Currently vm_fault_reason is a clear interface for handle_mm_fault() for > not only arch pffault handlers but also soft faults like GUP. > > If handle_mm_fault() doesn't return VM_FAULT_BADMAP at all, I don't think > we should have it as public API at all. When arch1 people reading the > VM_FAULT_ documents, it shouldn't care about some fault reason that only > happens with arch2. Gup shouldn't care about it either. > > Logically a new page fault handler should handle all the retval of > vm_fault_reason afaiu. That shouldn't include e.g. VM_FAULT_BADMAP either. Hmm, right. Looking specifically at how s390 uses VM_FAULT_BADMAP, it just seems to be a badly structured fault.c. Seems to me that do_fault_error() should take an extra si_code argument, and instead of returning VM_FAULT_BADACCESS / VM_FAULT_BADMAP from various functions, those functions should call do_fault_error() directly, passing it VM_FAULT_SIGSEGV and the appropriate si_code. But this is all on the s390 people to fix; I don't want to break their arch by trying it myself.
