Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20180903165719.499675257@linuxfoundation.org> <64889a4a-c095-3db8-b496-631acbafcf9a@applied-asynchrony.com>
In-Reply-To: <64889a4a-c095-3db8-b496-631acbafcf9a@applied-asynchrony.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 4 Sep 2018 10:12:13 -0700
Message-ID: <CA+55aFyDZR4SGotsxUA7ahCGCDr+PGnn=_13e_0_W2SnoQbM5w@mail.gmail.com>
Subject: Re: [PATCH 4.18 000/123] 4.18.6-stable review
To:     holger@applied-asynchrony.com
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Shuah Khan <shuah@kernel.org>, patches@kernelci.org,
        Ben Hutchings <ben.hutchings@codethink.co.uk>,
        lkft-triage@lists.linaro.org, stable <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffst=C3=A4tte
<holger@applied-asynchrony.com> wrote:
>
> Sep  3 20:19:38 ragnarok kernel:  tlb_flush_mmu_tlbonly+0x76/0xc0
> Sep  3 20:19:38 ragnarok kernel:  tlb_table_flush.part.13+0xe/0x30
> Sep  3 20:19:38 ragnarok kernel:  tlb_flush_mmu_tlbonly+0x54/0xc0
> ..a few hundred times..
> Sep  3 20:19:38 ragnarok kernel:  tlb_table_flush.part.13+0xe/0x30
> Sep  3 20:19:38 ragnarok kernel:  tlb_flush_mmu_tlbonly+0x54/0xc0
> Sep  3 20:19:38 ragnarok kernel:  arch_tlb_finish_mmu+0x3a/0x70
> Sep  3 20:19:38 ragnarok kernel:  tlb_finish_mmu+0x1f/0x30

Yeah, so what seems to have happened is that commit db7ddef30112 ("mm:
move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the
stable tree (because it wasn't an obvious dependency).

And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm:
Support invalidating TLB caches for RCU_TABLE_FREE") ends up with
recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(),
which in turn calls tlb_table_invalidate(), which calls back to
tlb_flush_mmu_tlbonly().

So you have endless recursion - at least until you run out of stack.
Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a
nice clean kernel stack overflow message like you did.

Or if you have KASAN enabled and no VMAP stack, you just end up with
random hangs and huge memory corruption as the recursion stomps all
over your memory.

          Linus