>>>>> "Mikulas" == Mikulas Patocka <mpatocka@xxxxxxxxxx> writes: Mikulas> On Mon, 30 Apr 2018, John Stoffel wrote: >> >>>>> "Mikulas" == Mikulas Patocka <mpatocka@xxxxxxxxxx> writes: >> Mikulas> On Thu, 26 Apr 2018, John Stoffel wrote: >> Mikulas> I see your point - and I think the misunderstanding is this. >> >> Thanks. >> Mikulas> This patch is not really helping people to debug existing crashes. It is Mikulas> not like "you get a crash" - "you google for some keywords" - "you get a Mikulas> page that suggests to turn this option on" - "you turn it on and solve the Mikulas> crash". >> Mikulas> What this patch really does is that - it makes the kernel deliberately Mikulas> crash in a situation when the code violates the specification, but it Mikulas> would not crash otherwise or it would crash very rarely. It helps to Mikulas> detect specification violations. >> Mikulas> If the kernel developer (or tester) doesn't use this option, his buggy Mikulas> code won't crash - and if it won't crash, he won't fix the bug or report Mikulas> it. How is the user or developer supposed to learn about this option, if Mikulas> he gets no crash at all? >> >> So why do we make this a KConfig option at all? Mikulas> Because other people see the KConfig option (so, they may enable it) and Mikulas> they don't see the kernel parameter (so, they won't enable it). Mikulas> Close your eyes and say how many kernel parameters do you remember :-) >> Just turn it on and let it rip. Mikulas> I can't test if all the networking drivers use kvmalloc properly, because Mikulas> I don't have the hardware. You can't test it neither. No one has all the Mikulas> hardware that is supported by Linux. Mikulas> Driver issues can only be tested by a mass of users. And if the users Mikulas> don't know about the debugging option, they won't enable it. >> >> I agree with James here. Looking at the SLAB vs SLUB Kconfig entries >> >> tells me *nothing* about why I should pick one or the other, as an >> >> example. Mikulas> BTW. You can enable slub debugging either with CONFIG_SLUB_DEBUG_ON or Mikulas> with the kernel parameter "slub_debug" - and most users who compile their Mikulas> own kernel use CONFIG_SLUB_DEBUG_ON - just because it is visible. 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. >> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
