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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: linux-next boot error: WARNING in kmem_cache_free
Date:   Mon, 22 Jun 2020 02:29:35 -0400
Message-Id: <4A35E92B-9DEF-4833-81DD-0C6FA50EB174@lca.pw>
References: <000000000000617f9d05a8a5a2c4@google.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-next@vger.kernel.org, sfr@canb.auug.org.au,
        syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk
In-Reply-To: <000000000000617f9d05a8a5a2c4@google.com>
To:     syzbot <syzbot+95bccd805a4aa06a4b0d@syzkaller.appspotmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jun 22, 2020, at 1:37 AM, syzbot <syzbot+95bccd805a4aa06a4b0d@syzkaller=
.appspotmail.com> wrote:
>=20
> WARNING: CPU: 0 PID: 0 at mm/slab.h:232 kmem_cache_free+0x0/0x200 mm/slab.=
c:2262

Is there any particular reason to use CONFIG_SLAB rather than CONFIG_SLUB?

You are really asking for trouble to test something that almost nobody is ex=
ercising that code path very well nowadays.

Anyway, there is a patchset in -mm that might well introduce this regression=
 that we could go to confirm it, but I kind of don=E2=80=99t want to spend t=
oo much time on SLAB that suppose to be obsolete eventually.=