On Sun, Feb 05, 2023 at 07:54:35PM -0500, Peter Xu wrote: > On Mon, Feb 06, 2023 at 12:10:53AM +0000, Matthew Wilcox wrote: > > On Sun, Feb 05, 2023 at 06:17:01PM -0500, Peter Xu wrote: > > > I noticed a few collision usage on VM_FAULT_* definition in the page fault > > > path on arm/arm64/s390 where the VM_FAULT_* can overlap with the generic > > > definition of vm_fault_reason. > > > > > > The major overlapped part being VM_FAULT_HINDEX_MASK which is used only by > > > the hugetlb hwpoisoning. > > > > > > I'm not sure whether any of them can have a real impact, but that does not > > > look like to be expected. I didn't copy stable, if anyone thinks it should > > > please shoot. Nor did I test them in any form - I just changed the > > > allocations from top bits and added a comment for each of them. > > > > This seems like a bad way to do it. Why not just put these VM_FAULT_* > > definitions in linux/mm_types.h? Then we'll see them when adding new > > VM_FAULT codes. Sure, they won't be used by every architecture, but > > so what? > > My initial version actually contains a few VM_FAULT_PRIVATE_N there, but I 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".
