[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADVatmPkXQ3mJpdTvaHxN4qmacYBhvzz=nxduQn-y+QUz4Pu2Q@mail.gmail.com>
Date: Fri, 22 Jul 2022 18:19:28 +0100
From: Sudip Mukherjee <sudipm.mukherjee@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nick Piggin <npiggin@...il.com>, Arnd Bergmann <arnd@...db.de>,
linux-arch <linux-arch@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: mainline build failure due to b67fbebd4cf9 ("mmu_gather: Force
tlb-flush VM_PFNMAP vmas")
On Fri, Jul 22, 2022 at 5:28 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Fri, Jul 22, 2022 at 12:53 AM Sudip Mukherjee (Codethink)
> <sudipm.mukherjee@...il.com> wrote:
> >
> > The latest mainline kernel branch fails to build for alpha allmodconfig
> > with the error:
>
> Gaah. It's the odd MMU_GATHER_NO_RANGE architectures - alpha, m68k,
> microblaze, nios2 and openrisc.
>
> We should probably get rid of that oddity, and force everybody to have
> the ranged tlb flush functions, but for now the trivial patch is to
> just remove the left-over dummy tlb_update_vma_flags() from that case,
> I think.
>
> Trivial patch attached. I don't have any cross-compiler for those
> architectures on my machine, but I suspect I'll just commit it as-is
> even without testing, since it can't be worse than what the situation
> is right now with that "redefinition of 'tlb_update_vma_flags'"
That fixes the alpha build failure.
If you commit it today then my nightly builds can test other
combinations of all other arch also.
--
Regards
Sudip
Powered by blists - more mailing lists