On Fri, Feb 12, 2021 at 2:44 PM Peter Xu <peterx@xxxxxxxxxx> wrote: > > On Fri, Feb 12, 2021 at 10:21:45PM +0000, Matthew Wilcox wrote: > > On Thu, Feb 11, 2021 at 11:28:09AM -0800, Axel Rasmussen wrote: > > > Ah, I had added this just after VM_UFFD_WP, without noticing that this > > > would be sharing a bit with VM_LOCKED. That seems like not such a > > > great idea. > > > > > > I don't see another unused bit, and I don't see some other obvious > > > candidate to share with. So, the solution that comes to mind is > > > > it'd be even better if you didn't use the last unused bit for UFFD_WP. > > not sure how feasible that is, but you can see we're really short on > > bits here. > > UFFD_WP is used now for anonymouse already.. And the support for hugetlbfs and > shmem is in rfc stage on the list. > > Is it possible to use CONFIG_ARCH_USES_HIGH_VMA_FLAGS here? So far uffd-wp is > only working for 64 bit x86 too due to enlarged pte space. Maybe we can also > let minor mode to only support 64 bit hosts. At least for my / Google's purposes, I don't care about 32-bit support for this feature. I do care about both x86_64 and arm64, though. So it's a possibility. Alternatively, the "it's an API feature not a registration mode" approach I sent in my v6 also works for me, although it has some drawbacks. Another option is, would it be terrible to add an extra u16 or u32 for UFFD flags to vm_area_struct (say within vm_userfaultfd_ctx)? Historically we've already added a pointer, so maybe an extra say 16 bits isn't so bad? This would avoid using *any* VM_* flags for UFFD, even VM_UFFD_MISSING could be in this new flag field. > > Thanks, > > -- > Peter Xu >
