From: Qian Cai <cai@lca.pw>
To: Dmitry Vyukov <dvyukov@google.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>
Subject: Re: linux-next boot error: WARNING in kmem_cache_free
Date: Mon, 22 Jun 2020 03:28:09 -0400 [thread overview]
Message-ID: <121C0D57-C9E6-406B-A280-A67E773EA9D0@lca.pw> (raw)
In-Reply-To: <CACT4Y+ZcbA=9L2XPC_rRG-FdwOoH6XteOoGHg7jfvd+1CH2M+w@mail.gmail.com>
> On Jun 22, 2020, at 2:42 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>
> 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’s your use cases with CONFIG_SLAB? The only thing prevents it from being purged early is that it might perform better with a certain type of networking workloads where syzbot should have nothing to gain from it.
I am more of thinking about the testing coverage that we could use for syzbot 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 further with those testing failures. Until you are able to figure out the buggy patch or patchset introduced the regression, I am afraid not many people would be able to spend much time on SLAB. The developers are pretty much already half-hearted on it by only fixing SLAB here and there without runtime testing it.
next prev parent reply other threads:[~2020-06-22 7:28 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
2020-06-22 7:28 ` Qian Cai [this message]
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=121C0D57-C9E6-406B-A280-A67E773EA9D0@lca.pw \
--to=cai@lca.pw \
--cc=dvyukov@google.com \
--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).