vm_area at addr ffffffffc0800000 is not marked as VM_IOREMAP

[Alexei Starovoitov]

On Fri, Mar 8, 2024 at 2:44 PM Alexei Starovoitov
<alexei.starovoitov at gmail.com> wrote:
>
> On Fri, Mar 8, 2024 at 9:53 AM Alexei Starovoitov
> <alexei.starovoitov at gmail.com> wrote:
> >
> > On Fri, Mar 8, 2024 at 9:24 AM Christoph Hellwig <hch at infradead.org> wrote:
> > >
> > > On Fri, Mar 08, 2024 at 09:20:24AM -0800, Alexei Starovoitov wrote:
> > > > ok. Like the attached patch?
> > >
> > > Looks sensibe, but I think the powerpc callers of ioremap_page_range
> > > will need the same treatment.
> >
> > Good point. Only one of the callers in arch/powerpc needs adjusting.
> > Found few other similar arch users.
> > See attached patch.
> >
> > ioremap_page() in arch/arm/mm/ioremap.c is an interesting case.
> > It is EXPORT_SYMBOL, but there are no in-tree users.
> > I think we shouldn't apply checks to it,
> > since some out-of-tree module may fail.
> > I have no arm boards to test, I suggest we play safe than sorry.
>
> I double checked on my newly setup arm64 VM that the fix works.
> I believe the regression needs to be fixed today, but
> looks like Chritoph is out for today.
> So I can either revert the offending commit or
> apply the proposed fix to bpf-next.
> I'm going to do the latter soon if no one objects.

And now applied the fix to bpf-next
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d131e3b655fd267d14bb1bed49e3f990a1465e

I've looked through all remaining users of ioremap_page_range()
in alpha, arm, loongarch, mips, powerpc, sh, x86 and
all of them do the right thing:
*get_vm_area*(.. VM_IOREMAP, ...)
followed by ioremap_page_range().