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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Apr 2018 14:58:28 -0400
From:   "John Stoffel" <john@...ffel.org>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Mikulas Patocka <mpatocka@...hat.com>, Michal@...ffel.org,
        eric.dumazet@...il.com, mst@...hat.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>, linux-mm@...ck.org,
        dm-devel@...hat.com, Vlastimil Babka <vbabka@...e.cz>,
        Andrew@...ffel.org, David Rientjes <rientjes@...gle.com>,
        Morton <akpm@...ux-foundation.org>,
        virtualization@...ts.linux-foundation.org,
        David Miller <davem@...emloft.net>, edumazet@...gle.com
Subject: Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc
 fallback options

>>>>> "James" == James Bottomley <James.Bottomley@...senPartnership.com> writes:

James> On Wed, 2018-04-25 at 19:00 -0400, Mikulas Patocka wrote:
>> 
>> On Wed, 25 Apr 2018, James Bottomley wrote:
>> 
>> > > > Do we really need the new config option?  This could just be
>> > > > manually  tunable via fault injection IIUC.
>> > > 
>> > > We do, because we want to enable it in RHEL and Fedora debugging
>> > > kernels, so that it will be tested by the users.
>> > > 
>> > > The users won't use some extra magic kernel options or debugfs
>> files.
>> > 
>> > If it can be enabled via a tunable, then the distro can turn it on
>> > without the user having to do anything.  If you want to present the
>> > user with a different boot option, you can (just have the tunable
>> set
>> > on the command line), but being tunable driven means that you don't
>> > have to choose that option, you could automatically enable it under
>> a
>> > range of circumstances.  I think most sane distributions would want
>> > that flexibility.
>> > 
>> > Kconfig proliferation, conversely, is a bit of a nightmare from
>> both
>> > the user and the tester's point of view, so we're trying to avoid
>> it
>> > unless absolutely necessary.
>> > 
>> > James
>> 
>> BTW. even developers who compile their own kernel should have this
>> enabled by a CONFIG option - because if the developer sees the option
>> when browsing through menuconfig, he may enable it. If he doesn't see
>> the option, he won't even know that such an option exists.

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