[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23271.24580.695738.853532@quad.stoffel.home>
Date: Mon, 30 Apr 2018 14:27:16 -0400
From: "John Stoffel" <john@...ffel.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: John Stoffel <john@...ffel.org>, Andrew@...ffel.org,
eric.dumazet@...il.com, mst@...hat.com, edumazet@...gle.com,
netdev@...r.kernel.org, jasowang@...hat.com,
Randy Dunlap <rdunlap@...radead.org>,
linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>,
Hocko <mhocko@...nel.org>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Michal@...ffel.org, dm-devel@...hat.com,
David Miller <davem@...emloft.net>,
David Rientjes <rientjes@...gle.com>,
Morton <akpm@...ux-foundation.org>,
virtualization@...ts.linux-foundation.org, linux-mm@...ck.org,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc
fallback options
>>>>> "Mikulas" == Mikulas Patocka <mpatocka@...hat.com> writes:
Mikulas> On Thu, 26 Apr 2018, John Stoffel wrote:
>> >>>>> "James" == James Bottomley <James.Bottomley@...senPartnership.com> 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.
Powered by blists - more mailing lists