Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 23 Jul 2021 12:29:25 +0800
From:   Jisheng Zhang <jszhang3@mail.ustc.edu.cn>
To:     tongtiangen <tongtiangen@huawei.com>
Cc:     Andreas Schwab <schwab@linux-m68k.org>,
        Atish Patra <atishp@atishpatra.org>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next v2] riscv: add VMAP_STACK overflow detection
Message-ID: <20210723122925.67a14562@xhacker>
In-Reply-To: <52e3626a-2b40-bda6-de0e-68ea12a86dd9@huawei.com>
References: <87bl6yrcmd.fsf@igel.home>
        <mhng-e14c3232-cc4d-4146-8c93-c60ec81ed272@palmerdabbelt-glaptop>
        <CAOnJCU+Ss0cO1mqr=GDVnpxV075uR+KipSnr7dN93099dAH+vQ@mail.gmail.com>
        <20210722213724.1f12a0e7@xhacker>
        <87zguexslf.fsf@igel.home>
        <20210723075432.098634a2@xhacker>
        <52e3626a-2b40-bda6-de0e-68ea12a86dd9@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 23 Jul 2021 09:36:47 +0800
tongtiangen <tongtiangen@huawei.com> wrote:

> On 2021/7/23 7:54, Jisheng Zhang wrote:
> > On Thu, 22 Jul 2021 17:42:52 +0200
> > Andreas Schwab <schwab@linux-m68k.org> wrote:
> > =20
> >> On Jul 22 2021, Jisheng Zhang wrote:
> >> =20
> >>> I think we need to pin the stack before calling get_wchan(), could yo=
u please
> >>> try below patch? =20
> >>
> >> Thanks, this fixes the crash for me.
> >>
> >> Andreas.
> >> =20
> >
> > Thanks for testing. I will send out formal patch later
> >
> > Thanks
> >
> > .
> > =20
>=20
> Hi all:
> I tried to reproduced this crash in openSUSE code repo=EF=BC=88=20
> https://github.com/opensuse/kernel =EF=BC=89, but not reproduced successf=
ully.
>=20
>  From the patch of problem repair, the crash is due to task->stack is=20
> released before calling get_wchan, the task state of maybe TASK_DEAD.
>=20
> VMAP_STACK is used to detect kernel stack overflow, there is no=20
> connection between the two, it makes me a little confused.

I believe the bug exists from the first day of riscv mainlined.

Since THREAD_INFO_IN_TASK=3Dy in riscv, so when task stack can be freed
before being destroyed.

When VMAP_STACK=3Dn, task's stack is allocated from linear mapping. When
task stack is freed, the corresponding mapping still exists, and since
get_wchan() only read, no harm is observed so far.

When VMAP_STACK=3Dy, task's stack is allocated from vmalloc area. When
task stack is freed, the corresponding mapping may not exist, so I expect
MMU fault here, thus the kernel panic.

In summary, the bug isn't related with VMAP_STACK, but VMAP_STACK makes
the bug observable.

Thanks