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 03:28:09 -0400
Message-Id: <121C0D57-C9E6-406B-A280-A67E773EA9D0@lca.pw>
References: <CACT4Y+ZcbA=9L2XPC_rRG-FdwOoH6XteOoGHg7jfvd+1CH2M+w@mail.gmail.com>
Cc:     syzbot <syzbot+95bccd805a4aa06a4b0d@syzkaller.appspotmail.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux-Next Mailing List <linux-next@vger.kernel.org>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Al Viro <viro@zeniv.linux.org.uk>
In-Reply-To: <CACT4Y+ZcbA=9L2XPC_rRG-FdwOoH6XteOoGHg7jfvd+1CH2M+w@mail.gmail.com>
To:     Dmitry Vyukov <dvyukov@google.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jun 22, 2020, at 2:42 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>=20
> There is a reason, it's still important for us.
> But also it's not our strategy to deal with bugs by not testing
> configurations and closing eyes on bugs, right? If it's an official
> config in the kernel, it needs to be tested. If SLAB is in the state
> that we don't care about any bugs in it, then we need to drop it. It
> will automatically remove it from all testing systems out there. Or at
> least make it "depends on BROKEN" to slowly phase it out during
> several releases.

Do you mind sharing what=E2=80=99s your use cases with CONFIG_SLAB? The only=
 thing prevents it from being purged early is that it might perform better w=
ith a certain type of networking workloads where syzbot should have nothing t=
o gain from it.

I am more of thinking about the testing coverage that we could use for syzbo=
t to test SLUB instead of SLAB. Also, I have no objection for syzbot to test=
 SLAB, but then from my experience, you are probably on your own to debug fu=
rther with those testing failures. Until you are able to figure out the bugg=
y patch or patchset introduced the regression, I am afraid not many people w=
ould be able to spend much time on SLAB. The developers are pretty much alre=
ady half-hearted on it by only fixing SLAB here and there without runtime te=
sting it.=