From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754571AbeD3S1t (ORCPT ); Mon, 30 Apr 2018 14:27:49 -0400 Received: from mail.stoffel.org ([104.236.43.127]:51790 "EHLO mail.stoffel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752980AbeD3S1s (ORCPT ); Mon, 30 Apr 2018 14:27:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23271.24580.695738.853532@quad.stoffel.home> Date: Mon, 30 Apr 2018 14:27:16 -0400 From: "John Stoffel" To: Mikulas Patocka Cc: John Stoffel , Andrew@stoffel.org, eric.dumazet@gmail.com, mst@redhat.com, edumazet@google.com, netdev@vger.kernel.org, jasowang@redhat.com, Randy Dunlap , linux-kernel@vger.kernel.org, Matthew Wilcox , Hocko , James Bottomley , Michal@stoffel.org, dm-devel@redhat.com, David Miller , David Rientjes , Morton , virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Vlastimil Babka Subject: Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options In-Reply-To: References: <20180421144757.GC14610@bombadil.infradead.org> <20180424162906.GM17484@dhcp22.suse.cz> <20180424170349.GQ17484@dhcp22.suse.cz> <20180424173836.GR17484@dhcp22.suse.cz> <1114eda5-9b1f-4db8-2090-556b4a37c532@infradead.org> <1524694663.4100.21.camel@HansenPartnership.com> <1524697697.4100.23.camel@HansenPartnership.com> <23266.8532.619051.784274@quad.stoffel.home> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64-pc-linux-gnu) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>>> "Mikulas" == Mikulas Patocka writes: Mikulas> On Thu, 26 Apr 2018, John Stoffel wrote: >> >>>>> "James" == James Bottomley writes: >> James> I may be an atypical developer but I'd rather have a root canal James> than browse through menuconfig options. The way to get people James> to learn about new debugging options is to blog about it (or James> write an lwn.net article) which google will find the next time James> I ask it how I debug XXX. Google (probably as a service to James> humanity) rarely turns up Kconfig options in response to a James> query. >> >> 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. >> >> John 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? Just turn it on and let it rip. 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.