[+Cc linux-mm; +Bcc linux-fsdevel] On Mon, Jun 22, 2020 at 03:28:09AM -0400, Qian Cai wrote: > > > > On Jun 22, 2020, at 2:42 AM, Dmitry Vyukov <dvyu...@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. >
This bug also got reported 2 days later by the kernel test robot (https://lore.kernel.org/lkml/20200623090213.GW5535@shao2-debian/). Then it was fixed by commit 437edcaafbe3, so telling syzbot: #syz fix: mm, slab/slub: improve error reporting and overhead of cache_from_obj()-fix If CONFIG_SLAB is no longer useful and supported then it needs to be removed from the kernel. Otherwise, it needs to be tested just like all other options. - Eric
