Re: [PATCH v2] fix mmap return value when vma is merged after call_mmap()

[Matthew Wilcox <willy@infradead.org>]

On Fri, Dec 04, 2020 at 12:04:51PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 04, 2020 at 03:25:35PM +0000, Matthew Wilcox wrote:
> 
> > This commit makes no sense.  I know it's eight years old, so maybe the
> > device driver which did this has long been removed from the tree, but
> > davem's comment was (iirc) related to a device driver for a graphics
> > card that would 256MB-align the user address.  Another possibility is
> > that userspace always asks for a 256MB-aligned address these days.
> 
> Presumably the latter, otherwise people would be complaining about the
> WARN_ON.
> 
> With some grep I could only find this:
> 
> static int mc68x328fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
> {
> #ifndef MMU
>         /* this is uClinux (no MMU) specific code */
> 
>         vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
>         vma->vm_start = videomemory;
> 
>         return 0;
> #else
>         return -EINVAL;
> #endif
> }
> 
> So it does seem gone

I found some buggy, uncompilable code in binder that used to modify it:

-#ifdef CONFIG_CPU_CACHE_VIPT
-       if (cache_is_vipt_aliasing()) {
-               while (CACHE_COLOUR(
-                       pr_info("%s: %d %lx-%lx maps %pK bad alignment\n",
-                               __func__,
-                               alloc->pid, vma->vm_start, vma->vm_end,
-                               alloc->buffer);
-                       vma->vm_start += PAGE_SIZE;
-               }
-       }
-#endif

pretty sure that even if the syntax error were fixed, it would have
done something awful and wrong.

It seems like it used to be quite popular to do it for nommu-fb-mmap,
but it fell out of favour.  If there was a sparc fb driver that did it,
it got deleted before 2.6.12-rc2, so I don't really care.

So yes, let's turn this into a BUG_ON.