From: Dmitry Vyukov <dvyukov@google.com>
To: Qian Cai <cai@lca.pw>
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>
Subject: Re: linux-next boot error: WARNING in kmem_cache_free
Date: Mon, 22 Jun 2020 08:42:13 +0200 [thread overview]
Message-ID: <CACT4Y+ZcbA=9L2XPC_rRG-FdwOoH6XteOoGHg7jfvd+1CH2M+w@mail.gmail.com> (raw)
In-Reply-To: <4A35E92B-9DEF-4833-81DD-0C6FA50EB174@lca.pw>
On Mon, Jun 22, 2020 at 8:29 AM Qian Cai <cai@lca.pw> wrote:
> > On Jun 22, 2020, at 1:37 AM, syzbot <syzbot+95bccd805a4aa06a4b0d@syzkaller.appspotmail.com> wrote:
> >
> > 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?
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.
> You are really asking for trouble to test something that almost nobody is exercising 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’t want to spend too much time on SLAB that suppose to be obsolete eventually.
next prev parent reply other threads:[~2020-06-22 6:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 5:37 linux-next boot error: WARNING in kmem_cache_free syzbot
2020-06-22 6:29 ` Qian Cai
2020-06-22 6:42 ` Dmitry Vyukov [this message]
2020-06-22 7:28 ` Qian Cai
2020-06-27 23:10 ` Eric Biggers
2020-06-28 0:49 ` Qian Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACT4Y+ZcbA=9L2XPC_rRG-FdwOoH6XteOoGHg7jfvd+1CH2M+w@mail.gmail.com' \
--to=dvyukov@google.com \
--cc=cai@lca.pw \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=syzbot+95bccd805a4aa06a4b0d@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).