> 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.
