On Fri, Mar 8, 2024 at 2:44 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Mar 8, 2024 at 9:53 AM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Fri, Mar 8, 2024 at 9:24 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> 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().
