On Mon, Feb 06, 2023 at 05:09:57AM +0000, Matthew Wilcox wrote: > 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. Yes, will take a look at it. For now I will apply Peter's patch in order to get rid of the collision.
