Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

From: Mikulas Patocka
Date: Thu May 03 2018 - 13:40:58 EST




On Wed, 2 May 2018, John Stoffel wrote:

> You miss my point, which is that there's no explanation of what the
> difference is between SLAB and SLUB and which I should choose. The
> same goes here. If the KConfig option doesn't give useful info, it's
> useless.

So what, we could write explamantion of that option.

> >> Now I also think that Linus has the right idea to not just sprinkle
> >> BUG_ONs into the code, just dump and oops and keep going if you can.
> >> If it's a filesystem or a device, turn it read only so that people
> >> notice right away.
>
> Mikulas> This vmalloc fallback is similar to
> Mikulas> CONFIG_DEBUG_KOBJECT_RELEASE. CONFIG_DEBUG_KOBJECT_RELEASE
> Mikulas> changes the behavior of kobject_put in order to cause
> Mikulas> deliberate crashes (that wouldn't happen otherwise) in
> Mikulas> drivers that misuse kobject_put. In the same sense, we want
> Mikulas> to cause deliberate crashes (that wouldn't happen otherwise)
> Mikulas> in drivers that misuse kvmalloc.
>
> Mikulas> The crashes will only happen in debugging kernels, not in
> Mikulas> production kernels.
>
> Says you. What about people or distros that enable it
> unconditionally? They're going to get all kinds of reports and then
> turn it off again. Crashing the system isn't the answer here.

I've made that kvmalloc bug too (in the function
dm_integrity_free_journal_scatterlist). I'd much rather like if the kernel
crashed (because then - I would fix the bug). The kernel didn't crash and
the bug sneaked into the official linux tree, where may be causing random
crashes for other users.

Mikulas