On Thu, Jan 05, 2023 at 06:08:28PM -0800, Linus Torvalds wrote: > Side note: making the 32-bit issue go away is likely trivial. We can > make 'vm_flags' be 64-bit, and a patch for that has been floating > around for over a decade: > > https://lore.kernel.org/all/20110412151116.B50D.A69D9226@xxxxxxxxxxxxxx/ > > but there was enough push-back on that patch that I didn't want to > take it, and some of the arguments for it were not that convincing (at > the time). > > But see commit ca16d140af91 ("mm: don't access vm_flags as 'int'"), > which happened as a result, and which I (obviously very naively) > believed would be a way to get the conversion to happen in a more > controlled manner. Sadly, it never actually took off, and we have very > few "vm_flags_t" users in the kernel, and a lot of "unsigned long > flags". We even started out with a "__nocast" annotation to try to > make sparse trigger on people who didn't use vm_flags_t properly. That > was removed due to it just never happening. > > But converting things to vm_flags_t with a coccinelle script > (hand-wave: look for variables of of "unsigned long" that use the > VM_xyz constants), and then just making vm_flags_t be a "u64" instead > sounds like a way forward. I'd be more inclined to do: typedef unsigned int vm_flags_t[2]; and deal with all the fallout. That'll find all the problems (although leave us vulnerable to people forgetting which half of the flags they want to be looking at). Hm. We never actually converted vma->vm_flags to be vm_flags_t. Only vm_region, which aiui is only used on nommu.
